On Thu, Nov 13, 2014 at 03:57:05PM -1000, Chris Newman wrote:
> > I am far more curious about what happened to Google's outbound
> > TLS mail stats around Oct 14th:
> >
> > https://www.google.com/transparencyreport/saferemail/
> >
> > but this seems likely to remain a mystery. Perhaps some large peer
> > botched their TLS settings?
>
> My speculation:
>
> There's no specification for SMTP relay fallback from STARTTLS to cleartext.
Correct, Sendmail defers the mail, while Postfix falls back to
cleartext (eventually).
> So if a provider turns on fully RFC 3207 client-side STARTTLS for relay
Google is the sender in this case. The drop in TLS traffic started
on Oct 7th, fell sharply on the 11th and ended on Oct 15th. Outbound
TLS support at Google is far from new.
> and that
> software doesn't also implement the unspecified fallback, it will stop the
> flow
> of mail to peers that advertise STARTTLS but implement it incorrectly.
So I think you're saying that Google may have disabled its previous
STARTTLS to cleartext fallback, and after a few days found that a
lot of mail got deferred. And that point either selectively or
globally re-enabled fallback?
I'd have hoped they would notice a lot sooner, the drop is from
75% to 50% of mail using TLS. If the missing TLS mail is queued,
that would rapidly lead to enourmous mail backlogs. It seems far
more likely that some remote peer broke their TLS, or Google tried
some fancy TLS settings, and ran into interoperability issues. In
either case Google likely then delivered in cleartext.
> Once the queue buildup is noticed, the client-side site has to:
>
> 1. turn off client-side STARTTLS
Note what happened at Google, since the TLS rate did not go to zero.
> 2. upgrade to a software version implementing the unspecified protocol, if
> available.
> 3. manually configure no-STARTTLS for each endpoint that has a broken STARTTLS
> implementation.
> 4. bounce mail to legitimate recipients with a bogus STARTTLS implementation.
They probably had cleartext fallback all along, and I think deferred
mail at that volume would have been noticed rather quickly.
> Incidentally, I suspect 1 is a common service provider response to this
> situation.
That is rather plausible.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
