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:
> # [email protected] 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
