On Sun, Jan 09, 2022 at 10:22:36PM +0100, Joachim Lindenberg <postfix-us...@lindenberg.one> wrote:
> Hello, > > I configured my Email server (actually a mailcow-dockerized > which in turn uses postfix) to enforce TLS for outbound mail. > Obviously that will fail occasionally, but I also have a daemon > watching the postfix queue and alerting me. Kind of works for me. > Ok, while subscribing to this mailing list I had to add two more > exceptions, because this mailing list uses an untrusted certificate > (https://www.checktls.com/TestReceiver?LEVEL=DETAIL&EMAIL=majord...@postfix.org). > Aren´t letsencrypt certs cheap enough in order to get rid of untrusted > certificates? Maybe in terms of money, but that's not the only consideration. If a mail server cannot (for any of a number of reasons) fire up a web server for LetsEncrypt domain ownership verification, then it gets more complicated. The cost becomes the effort to make use of LetsEncrypt. And since the general assumption is that most(?) SMTP server certificates are self-signed anyway, and SMTP clients rarely verify the certificates of SMTP servers, there's not much incentive to expend that effort. Even if it's not a huge effort, it's still some effort for no gain. That's why checktls.com displays this "failure" in yellow, not red. Even when mail server certificates are LetsEncrypt-certified, most will never be verified. > When reading the documentation > page http://www.postfix.org/TLS_README.html#client_tls however I > am wondering what the difference between options “verify” and “secure” is. > I read it several times and got the message, I should not use either, > but what exactly is the difference remained unclear to me. I haven't used either, so I might be wrong, but from the documentation, it seems that the difference is that with "verify", the domain name to check the certificate against comes from the MX record, but with "secure", the domain name(s) to check against comes via the smtp_tls_secure_cert_match parameter. In other words, with "verify" you are bravely trusting an external source of information completely (the MX record), but with "secure" you only trust the MX record enough to get the IP address, because that's unavoidable, but you don't trust it enough to use its domain name as well for the purpose of certificate verification, so you use internal Postfix configuration information to determine which name to check. > Is “DNS forgery resistant server certificate verification“ defined in > some RFC or other document I am not aware of? I used to think that that means that all of the relevant MX records are in DNSSEC-signed zones. That's the only DNS forgery resistance that I'm aware of. :-) However, I now think that it is referring to the fact that the "secure" level avoids trusting the name in the MX record because it can be forged (unless DNSSEC-signed but that's not the norm). Instead, it uses internal configuration information, which is not subject to DNS forgery. It's defined here: http://www.postfix.org/postconf.5.html#smtp_tls_security_level ("secure" section) and here: http://www.postfix.org/postconf.5.html#smtp_tls_secure_cert_match http://www.postfix.org/postconf.5.html#smtp_tls_verify_cert_match > Thanks, Joachim Thanks for asking this question. I was confused about the difference between "verify" and "secure", but I think I understand it better now. cheers, raf
