On Sat, Feb 07, 2015 at 10:18:17PM +0100, Michael Grimm wrote:
http://www.postfix.org/TLS_README.html#client_tls_dane shows me an opt-in approach for opportunistic DANE (if I am not completely misunderstanding).
What I want to implement is an opportunistic DANE approach with fallback to opportunistic TLS for "DANE broken" hosts,
I'm holding off on implementing any automated fallback with DANE, because I want broken sites to fix their breakage, rather than make all senders accommodate broken sites. If we automatically fall back to unauthenticated TLS (with log warnings, ...), broken sites become entrenched, and we never get DANE implemented with authentication enforced.
smtp_dns_support_level = dnssec smtp_tls_security_level = dane smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
plus "broken" hosts: transport_maps = pcre:/usr/local/etc/postfix/transport_maps
/usr/local/etc/postfix/transport_maps /^example.com/ opportunistic-tls
Why use regexps for this (badly at that)? Use a non-regexp table, or learn how to write 100% correct regular expressions (your's is only 2/3 of the way there).
master.cf: opportunistic-tls unix - - n - - smtp -o syslog_name=postfix/otls -o smtp_dns_support_level=enabled -o smtp_tls_security_level=may
This is working on my test server, but before implementing that scheme on my productive server[1], I'd like to ask you experts out there:
This won't help you if the sites DNS is returning "bogus" MX and A/AAAA replies, because the local validating nameserver returns SERVFAIL no matter what "smtp_dns_support_level" you choose.
Postfix (through limitations in libresolv) cannot set the the "CD" bit in DNS requests, and so never sees DNS results that fail validation.
This only helps you when the problem is with TLSA records that don't match the server's chain. Such configurations are for emergencies only.
Do I miss something that might break my approach? Or, is there a more elegant way to implement a fallback oTLS?
To bypass DNSSEC problems you need to forward mail to another machine whose local DNS resolver is non-validating. That machine can deliver mail to sites with known broken DNSSEC (which you somehow decide is not an MiTM attack).