>From my understanding of the way postfix currently operates, there is no smtpd/stmp TLS setting that can be set that would provide a configuration that would result in a more 'hardened' configuration, without causing interoperability problems. If I am wrong, I'm very interested in knowing where.
A more hardened configuration would be something like promoting non-broken ciphers/protocols, refusing with meaningful rejections connections and not reverting to cleartext from MTAs that are either running software that is so out-of-date as to be guaranteed-compromised, or they are subject to a downgrade attack by an MITM. I think the only things that can reasonably be done right now are to set: smtp_tls_fingerprint_digest = sha1 smtpd_tls_eecdh_grade = ultra neither of those are particularly great improvements. What are some ways that we could improve the situation? One obvious one to me is that Postfix should allow for DH parameters that are larger than 1024bit, 512bit is a joke, and 1024bit is not strong enough. At the moment, these are the only two options. In my opinion, the flexibility here is too constrained, merely adding a 2048bit setting means that eventually you need to add a higher setting. Perhaps it is not possible to have a flexible and configurable bit length here? What other changes could we come up with that could improve the state of things? * SMTP servers should provide a mechanism for rejecting a cleartext or poor ciphersuite connections from clients without compromising delivery. * SMTP clients need a clear and unambiguous signal that they can note that tells them not to try fallback behaviors when connecting to [certain hosts|MXes for certain domains] - using a hand-maintained tls_policy table isn't going to cut it. * think bigger: out-of-band signalling, global lookup tables, internal TOFU-style caches of best-transport-status-achieved-per-peer, etc. figuring out the parameters of what would need to be stored/retained, how it would be bound to peers (e.g. by IP address, by EHLO name, by MX name, by delivery zone, etc), how it would be shared/propagated between servers (if at all), and how it would distinguish intentional key rollover/expiry from MITM. These would take a lot of work, and a lot of buy-in, but could really step up the game and pave the way for tougher blacklist-style hardening in the future
