RFC 3207 — STARTTLS

RFC 3207 defines STARTTLS, the extension that upgrades an SMTP connection to TLS. Almost all mail between servers is encrypted this way.

It is on this list because understanding its one weakness explains why MTA-STS, DANE and TLS-RPT all exist.

How it works

A sending server connects in the clear, sees STARTTLS in the server’s capability list, issues the command, and negotiates TLS. Everything after that is encrypted.

The critical detail is that the capability announcement itself travels in the clear, before any encryption exists.

The downgrade problem

An attacker positioned between the two servers can simply remove STARTTLS from the capability list. The sender sees a server that does not support encryption, and — because mail delivery is best-effort and refusing to deliver is worse than delivering — sends the message unencrypted.

Nothing looks wrong to either party. The message arrives. There is no error.

This is called opportunistic encryption: it protects against passive observation but not against anyone able to modify traffic. For most of the internet’s history that was accepted as good enough.

What fixed it

Both answers work by publishing, out of band, the fact that TLS is expected:

• MTA-STS publishes a policy over HTTPS, authenticated by the web PKI.
• DANE publishes certificate constraints in DNS, authenticated by DNSSEC.

A sender that knows TLS is required will refuse to deliver rather than fall back, which is exactly the behaviour STARTTLS alone cannot provide. Add TLS-RPT and you find out when it happens.

Is my mail encrypted?

Almost certainly, most of the time. STARTTLS adoption between major providers is effectively universal, and both Google and Microsoft report well over 90% of mail in transit as encrypted.

What you cannot tell from that is whether your mail was downgraded on a particular route, because a stripped connection looks identical to a server that never supported TLS. That is precisely the gap TLS-RPT fills: it reports the sessions that failed and why, which is the only way to see a downgrade after the fact.

Read it: rfc-editor.org/rfc/rfc3207