xs4all enabled DANE outgoing verification

Viktor Dukhovni ietf-dane at dukhovni.org
Mon Sep 3 14:52:23 CEST 2018

> On Sep 3, 2018, at 8:25 AM, Bjørn Mork <bjorn at mork.no> wrote:
>> If STARTTLS was disabled with some client IPs for interoperability reasons,
>> resolve those first.
> In a perfect world, yes.  But in practice: How do you do that?
> I don't think it is realistic to offer STARTTLS without some local
> exception list.  There are just too many buggy clients and ignorant
> sysadmins.

AFAIK, things aren't as dire as you describe.  I'd expect MTA-to-MTA
opportunistic TLS to be working reliably with the vast majority of
senders, with the need for exceptions very rare.  Yes, some Yahoo
systems (still!) insist on shooting themselves in the foot and dropping
to cleartext when WebPKI certificate verification fails, but they do
then succeed in the clear:


with no exceptions needed in their case.

If a sender has buggy client-side STARTTLS, they'll typically send
in the clear when STARTTLS fails, in which case you still don't
need to make exceptions, let them retry.

If you do find the need to make an exception, I'd recommend applying
any STARTTLS exceptions on just a subset of your primary MX hosts.
This has two benefits:

   1. They can still get through if/when they fix their software
      turn on DANE.

   2. Their logs and your logs continue to record intermittent
      failures while they are still broken, with the mail getting
      through via the MX hosts with the exception list.  That way,
      you can prune your lists when failures cease, and they may
      take action sooner if they see ongoing issues.


More information about the dane-users mailing list