On 10/26/19 8:47 PM, John R Levine wrote:
Maybe it's not necessary, but I don't know how widely mta-sts is
being required. What are the barriers to server operators turning
on MTA-STS everywhere?
I expect the main barrier is that large scale operators see failures
on legit traffic that would be invisible to us little guys, but enough
of them that they're not ready to accept that level of breakage.
Yeah, that's what I was getting at. I've often suspected that there
were more distinct implementations of SMTP than nearly any other
protocol, even more than HTTP. That's a lot of implementations that
need to be upgraded (at least, all of those used for mail relaying and
not merely submission), and I'd expect the long tail to take a long time.
If I were an email service operator I'd be reluctant to reject
legitimate mail. But of course spam filters are already doing this to
an astonishingly high degree and that has become accepted practice
(sigh). So maybe a general requirement to use TLS for mail relaying
between administrative domains wouldn't look like a huge change. Maybe
it would even be justified as a spam deterrent.
My only thought regarding 4xx was that sometimes a soft incentive works
better than a hard one. If relaying mail by cleartext still "worked",
only more slowly because clients had to retry X% of the time, that seems
to me to provide a more workable feedback path to the operators not
using TLS, than a sudden hard refusal to accept cleartext SMTP.
I believe it's the same reason that Google doesn't sign their domains
with DNSSEC. They certainly could if they wanted to.
Nor sure I get the analogy. AFAIK if Google signed their domains, the
only things that would break would be broken DNS clients/resolvers doing
verification, which would hopefully be few in number.
Keith
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp