Full disclosure: I was the original finder of the STARTTLS plaintext injection problem, which affected Postfix and several other SMTP server implementations. See the text and links to other info in
https://www.postfix.org/CVE-2011-0411.html This is an easy to make mistake, and it is also easy to re-introduce unless there are pre-relase checks in place that catch this. DANE and MTA-STS are ways to discover that a domain or MX host supports SMTP over TLS. Neither protects against vulnerabilities like CVE-2011-0411. DANE requires DNSSEC, and can protect against "downgrade to plaintext" attacks, MTA-STS does not. I am all in favor of skipping STARTTLS. The Postfix SMTP client already TS wrappermode, and all that is needed is a few lines of code to automatically turn on TS wrappermode dependng on the service name. This can work equaly well for MX lookups or SRV lookups. (I'd probably add a new SMTP client configuration parameter that says "these service names use implicit TLS". So it is more like ~2 lines of code to convert a parameter value into a matchlist object, and another ~2 lines plus error handling to ask this list whether a service uses implicit TLS). I just don't think that it is a good idea to return a NullPort response to an SRV query for SMTPS, to announce that a property for a different service (SMTP property STARTTLS) is available. I would expect that a NullPort response means that the SMPS service is NOT AVAILABLE, similar to a Null MX response. Without DNSSEC, your idea cannot protect against "downgrade to plaintext" attacks. It is less useful than other available mechansisms to discover whether a domain supports SMTP over TLS. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
