8 ms·

Verification was not required as a matter of protocol until a new standard for MTA-STS was published in 2018. Without this new standard configured, as is going

Verification was not required as a matter of protocol until a new standard for MTA-STS was published in 2018. Without this new standard configured, as is going to be the case for most organizations out there not on the bleeding edge, TLS over smtp has been opportunistic and not verified the certificates or strictly enforced verification. https://www.digitalocean.com/community/tutorials/how-to-configure-mta-sts-and-tls-reporting-for-your-domain-using-apache-on-ubuntu-18-04 https://www.digitalocean.com/community/tutorials/how-to-conf... The additional daemon that it looks like postfix requires to support this new standard, postfix-mta-sts-resolver, had its 1.0.0 tagged version release in Jun 13, 2020. This does not and would not represent the vast majority of extant deployed smtp over TLS configurations out there. This right here is still in the README for postfix, one of the most popular MTAs in use: >Despite the potential for eliminating "man-in-the-middle" and other attacks, mandatory certificate trust chain and subject name verification is not viable as a default Internet mail delivery policy. Some MX hosts do not support TLS at all, and a significant portion of TLS-enabled MTAs use self-signed certificates, or certificates that are signed by a private Certification Authority. On a machine that delivers mail to the Internet, you should not configure mandatory server certificate verification as a default policy. That's a very load bearing "properly" in your sentence and I wonder just what you're referencing. Edit: and another good writeup. https://lwn.net/Articles/866481/ https://lwn.net/Articles/866481/

Beltalowda 4y ago
You've been able to configure Postfix to verify TLS for ages; you don't need some new daemon for that. I've written plenty of email systems over the years and have always verified certificates (unless explicitly told not to by the user) and that works just fine. You're confusing a lot of things that are related but actually quite distinct. That DigitalOcean article talks about STARTTLS, but that's something different than SMTP over TLS. I haven't worked that much with email in the last few years so haven't looked at MTA-STS in detail, but it just seems similar to setting a "always require a TLS connection"; that new Postfix service just looks up the DNS records and such; it's not required for TLS functionality.
- Avamander 4y ago
  Okay, you configure Postfix to verify TLS. Validation fails, what will happen? What does the documentation say about that configuration option? That aside, an active attacker can also trivially force a downgrade. Only with the introduction of MTA-STS, connections between MTA-MTA are secure. That's supported by, like, few major players - I guess by volume a fine percentage, but by total count, abysmal.

Beltalowda 4y ago

You've been able to configure Postfix to verify TLS for ages; you don't need some new daemon for that. I've written plenty of email systems over the years and have always verified certificates (unless explicitly told not to by the user) and that works just fine. You're confusing a lot of things that are related but actually quite distinct. That DigitalOcean article talks about STARTTLS, but that's something different than SMTP over TLS. I haven't worked that much with email in the last few years so haven't looked at MTA-STS in detail, but it just seems similar to setting a "always require a TLS connection"; that new Postfix service just looks up the DNS records and such; it's not required for TLS functionality.

Avamander 4y ago
Okay, you configure Postfix to verify TLS. Validation fails, what will happen? What does the documentation say about that configuration option? That aside, an active attacker can also trivially force a downgrade. Only with the introduction of MTA-STS, connections between MTA-MTA are secure. That's supported by, like, few major players - I guess by volume a fine percentage, but by total count, abysmal.