On Sep 3, 2018, at 8:25 AM, Bjørn Mork bjorn@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:
http://postfix.1071664.n5.nabble.com/Another-yahoo-problem-td89756.html#a897...
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.