Hello all, after experimenting with dane, verify, and other policies of http://www.postfix.org/TLS_README.html#client_tls, I am wondering whether the options available are really what should be available.
Right now a sender can configure that policy as a system default or per target domain. Obviously per target domain is quite some effort, even if one uses some automation by monitoring the queue and adding policies on the fly. Actually my postfix has default verify but a queue monitoring utility I wrote, generates dane-only, encrypt or may policies on the fly depending on DNS lookup. A single system default is also not appealing, as there are still mail servers out, that refuse to do encryption, that use inadequate certs, or other issues. Therefore dane-only doesn´t really work. The alternative dane implies may for all the rest, which limits my choices or compliance level. Now I was considering whether we should have something like use dane if available or encrypt otherwise, or dane if available or verify otherwise, etc., I guess you get the idea. Then I came to the conclusion that there is no need to have combinations: if postfix uses DNSSEC and the target domain uses DANE (publishes TSLA records), then this should override any policy set on the client, because it is a commitment of the recipient domain it does handle DANE. If DANE is not configured for the target domain, then whatever policy is set in postfix should apply. In other words, everyone can stick to may, encrypt, verify, depending of the expected compliance level, but get the benefits of DANE wherever applicable. Does this make sense to you? Thanks & Best Regards, Joachim
