The site https://hardenize.com provides relatively decent Email reports, along with other reports. It checks a number of things including certs, MTA-STS, TLS-RPT, DANE, SPF, DMARC, and then also TLS. These are all good checks and recommendations, with the exception of the TLS one, I do not see how its possible to meet their standards, and provide an email server on the internet. However, I could be wrong, so I'm interested to know if I am.
1. TLS versions: They don't like that TLS v1.1 and v1.0 are possible. If you turn this off, then those clients that only support v1.2 will fall back to clear-text, this is not optimal. I don't see a way around this one. 2. Server suite preferences: they break down each preferred cipher selection for each TLS verison, and are unhappy about the cipher suite configuration being suboptimal, specifically that the forward secrecy ciphers (ECDHE or DHE) and authenticated encryption (GCM or CHACHA20) are not 'at the top' of the cipher preferences. I know its possible to set `tls_preempt_cipher_list=yes` and risk Windows 2003 Microsoft Exchange clients having an issue[0]. But, to get the preferences to order the forward secrecy and auth encryption ciphers first, I'd have to specify a custom cipherlist with tls_medium_cipherlist, which would be ugly[0]. It is also unclear how this would work with tls1.2, vs. tls1.1 vs. tls1.0 (for example tls1.2 has TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 and if I set that as the first cipher in tls_medium_cipherlist, what happens with tls1.1 and tls1.0, which does not support that cipher?). I know that 'hardening postfix' threads have been posted here a number of times, I've read them and I understand the recommendations if you want to continue delivering and accepting email from the internet. What I'm trying to find out if there is a way to thread the needle: favor "better" ciphers, while limiting the impact to ancient software. I say 'limit' because I realize that even just turning on `tls_preempt_cipher_list=yes` will already cause problems with Windows 2000 Microsoft Exchange, but I feel that may be an acceptable trade-off at this point. micah 0. http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist 1. not even sure this would be the right format, but this would be the order: tls_medium_cipherlist=TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA256:TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA:TLS_RSA_WITH_SEED_CBC_SHA:TLS_DHE_RSA_WITH_SEED_CBC_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_128_CCM:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_256_CCM:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_128_CCM:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_256_CCM:TLS_RSA_WITH_AES_128_CCM_8:TLS_RSA_WITH_AES_256_CCM_8:TLS_DHE_RSA_WITH_AES_128_CCM_8:TLS_DHE_RSA_WITH_AES_256_CCM_8:TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256:TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256:TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
