Hi Viktor, On Wed, May 21, 2014 at 15:31:20 +0000, Viktor Dukhovni wrote: > Yes, you benefit from "herd immunity". When one sending site defers > mail to a destination, it is that sending site's problem. When > everyone defers mail to a destination, it is the destination site's > problem. Breaking your TLSA records is akin to getting listed at > SpamHaus, you have to fix it.
Ah, yes. That's a very valid point. > > And if you wouldn't use "smtp_tls_security_level = dane", what is the > > added security of DANE? > > You can use "dane" or "dane-only" per-destination if you like to > simplify the configuration management, no matching rules to define. > However, I would encourage senders en-masse to enable DANE, and > expect receiving systems that publish TLSA records to get it right > or fix it promptly. At least unlike the case with an RBL listing, > they can do it themselves. Still, our customers will likely react much more sensitively to their mails being queued (independently of the reason), compared to refusing incoming mails from a third party, because of mis-configuration. Especially, if they notice only one day later that their mails were being queued. > By shifting the responsibility to the receiving systems, it lowers > the frequency with which the sender will have to deal with the > problem. I hope so. > Of course with critical business partners, you may still want to > have a phone number handy. You might also consider: > > main.cf: > indexed = ${default_database_type}:${config_directory}/ > transport_maps = ${indexed}transport > > transport: > # Uncomment in case of emergency: > # postmas...@partner.example.com non-dane > > master.cf: > non-dane unix - - n - - smtp > -o smtp_tls_security_level=may > > That way, you would be able to reach out the emergency contacts by > email without disabling DANE for the entire domain. Nice and useful, thanks! Thanks again for all your answers! I really appreciate it. (We are working on adding DANE support to our product, btw.) Cheers David