On 3-9-18 14:25, Bjørn Mork wrote:
For those publishing TLSA records for inbound DANE, please make *sure* that you're offering STARTTLS *unconditionally*, to all SMTP clients with no restrictions by client IP address or reputation. Configurations that restrict STARTTLS to a set of "good" IPs are not compatible with DANE.This is indeed an important point to consider. Never thought of the possibility that the same client would first fail TLS and then start using DANE at some later point in time.
In our case, it wasn't that we failed TLS, but a previous software version had a limitation that annoyed some receivers: the outgoing connection would be kept open for as long as the "max command timeout" value, which was set at 5 minutes. So after every mail delivery, the connection would stay open for another 5 minutes (the idea being: existing connections are cheap, making a TLS connection isnt, so if another mail arrives this connection can be reused). But not everyone agrees that connections are cheap, especially if your software forks for every incoming SMTP connection. So, most operators would, when looking at their systems at some point in time, just see a few of our hosts keeping open a connection to their system, usually doing nothing. This got combined with flaky NAT-alike loadbalancers that would expire idle TCP connections, and you'd get stuck with half-open TCP/SSL connections that took a while to get rid of (sometimes hours). I know at least in one case that this happened. For some reason, disabling TLS made these symptoms less painful, so that approach was taken (this was a few years ago, DANE wasn't on anyone's radar). Our current software no longer has that limitation, and we now close the connection 30 seconds after delivery (unless new mail arrives that can reuse the connection).
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.
I never had a need for STARTTLS exceptions. Just make sure your software has appropriate timeouts and connection limits, and closes idle connections. And make sure that any loadbalancer you have in front of your systems, keeps track of TCP connections at least as long as the maximum timeout on your mail platform (and preferably a lot longer). If any software misbehaves (eg doesn't respect timeouts), complain to the vendor. When you really do get abusive clients, just block them completely instead of only blocking TLS. That draws their attention a lot sooner and puts much less of a load on your system. If this "client" is too big to be blocked completely, then either they likely have a well functioning abuse department and can resolve the issue, or you are doing something wrong in the first place, see timeouts and connection limits above. -- Jan-Pieter Cornet <[email protected]> Systeembeheer XS4ALL Internet bv www.xs4all.nl
signature.asc
Description: OpenPGP digital signature
