Am 21.06.2014 13:11, schrieb Stefan Foerster: > our current situation is as follows: > > 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may" > 2. Senders aren't known beforehand, i.e. no previous business relationship. > 3. Senders' IT usually doesn't support DANE. > 4. Incoming mail is considered highly(!) valuable to business. > > During a security audit, it was determined that the MX supported what > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0, > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we > disable all those - not considering the fact that our Postifx _did_ > assing a higher priority to "more secure" ciphers. > > Not surprisingly, a lot of sending systems failed back to plain text > after we pushed the change to production. > > Could someone share experience with or point me to some kind of "best > practices" regarding opportunistic TLS, or explain the reasoning for > banning "weak" ciphers/protocols on a public MX? (again, not talking > about a MSA, or a third party that we have ties with, which would allow > us to nail down protocols/ciphers with TLS policy maps)
fire the clueless auditor not in the position to demand anything while lacking basics himself and not able to make a difference between HTTP and SMTP - what such people not understand is that HTTPS don't fall back to plaintext - SMTP does
