Opportunistic DANE / TLS per host

[Michael Grimm]

> On 07.02.2015, at 23:58, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> 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.

Sorry for my broken English, fallback is wrong, now I know. What I actually meant is: explicitly allow delivery for "broken" hosts on purpose, no automatic fallback. Sorry.

>> /usr/local/etc/postfix/transport_maps
>> 	/^example\.com/     opportunistic-tls
> 
> Why use regexps for this (badly at that)?  Use a non-regexp table,

Ok, thanks for that hint.

> or learn how to write 100% correct regular expressions (your's is
> only 2/3 of the way there).

Yeah, I see, but honestly, normally I do add a trailing '$' :-)

>> 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).

Well, I see. I will stick with a pure opportunistic SANE for the time being.

Thank you very much and with kine regards,
Michael