On 07.01.22 13:28, Viktor Dukhovni wrote:
On Fri, Jan 07, 2022 at 11:34:32AM +0100, Charlotte 🦝 Delenk wrote:I was trying to harden my postfix configuration and was looking into making TLS mandatory, as well as verifying the TLS Certificate using DANE wherever possible.TLS mandatory for delivery to the world at large?
To the world at large, which I have already been advised against.
Or is your Postfix only sending email to a specific set of domains known to support TLS?
The vast majority of domains my server communicates with support TLS 1.3, both as SMTP clients and servers. And those that don't are likely running versions of security-critical libraries and programs that have been superseded upstream for at least 3 years at this point.
When I added DANE support to Postfix in 2013, it seemed unlikely that there'd be a set of domains small enough to be sure that they all support STARTTLS and yet too large to explicitly configure some for DANE and others for mandatory TLS. Thus, unfortunately, when you specify "dane", in the absence of TLSA records for the nexthop domain's MX hosts you get "may", rather than "encrypt".
I think I'm going to stick with "encrypt" for now, as the amount of domains that have deployed DANE are still small (and in fact I have not yet completed the DANE deployment for chir.rs myself)
According to the documentation of smtp_tls_security_level, you can either set the value to "encrypt" for mandatory tls or "dane" for optional DANE, but not both.Correct.Is there a way to combine "encrypt" with "dane"?Hypothetically (but not in practice) possible with given a sufficiently programmable resolver, that reports all domains as signed (validating those that really are), and can synthesise TLSA records for MX hosts that lack them, with the synthetic records having an unsupported "usage" or "selector", in which case Postfix will do mandatory TLS. I doubt such a resolver is easily available, and it is almost certainly much easier to patch Postfix to support "encrypt" when "dane" is not an option.
Yeah, that sounds much more plausible. -- Charlotte https://keybase.io/darkkirb • GPG Key 3CEF5DDA915AECB0 • https://darkkirb.de
OpenPGP_0x3CEF5DDA915AECB0.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
