Email moves between servers using SMTP, a protocol that predates the modern web and began life with no encryption at all. STARTTLS was bolted on later as a way to upgrade a plaintext SMTP connection to an encrypted one mid-conversation. A server advertises that it supports STARTTLS, the client says it wants to use it, and the two negotiate a TLS session before the actual message is sent.
The design goal was pragmatic. Requiring encryption everywhere would have broken mail delivery to the millions of servers that did not support it, so STARTTLS was made optional and best-effort. If encryption is available, use it. If not, fall back to plaintext so the mail still gets through. That fallback is the whole problem.
How the stripping attack works
An SMTP conversation begins in the clear. The sending server connects, and the receiving server responds with an EHLO greeting that lists its capabilities. One of those advertised capabilities is the line offering STARTTLS. The sender reads that line, decides to upgrade, and issues the STARTTLS command.
An attacker who can modify traffic on the path does not need to break any cryptography. They simply edit the receiving server's greeting before it reaches the sender, deleting the STARTTLS line. The sending server never sees an offer to encrypt, so it does what it was told to do when encryption is unavailable: it delivers the message in plaintext. Both servers behave exactly as designed. The attacker reads everything.
Because STARTTLS negotiation happens in cleartext before the TLS handshake, its advertisement can be tampered with. An active attacker removes the offer to encrypt, and the "fail open" fallback does the rest. No certificate is forged, no cipher is broken, and no warning is raised.
The command injection variant
Stripping is not the only STARTTLS weakness. In 2021, researchers led by Damian Poddebniak, Fabian Ising, Hanno Bock, and Sebastian Schinzel published a broad study of STARTTLS implementation bugs across popular mail clients and servers. Many of them found the same category of flaw: commands an attacker injected into the plaintext phase were buffered and then executed after the TLS session started, as if they had arrived safely inside the encrypted channel.
That confusion between "before TLS" and "after TLS" let an attacker smuggle commands across the security boundary, in some cases stealing credentials or injecting content into a victim's mailbox. The lesson generalizes beyond email: any protocol that switches from plaintext to encrypted mid-stream has to very carefully discard everything buffered before the switch, and many implementations did not.
The defenses: making encryption mandatory
The fix for opportunistic encryption is to remove the option to fall back. Two standards do this for email, and they work best together.
MTA-STS
MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a receiving domain publish a policy, served over HTTPS, declaring that senders must use TLS with a valid certificate and must refuse to deliver if that is not possible. Because the policy is fetched over an authenticated HTTPS channel, an on-path attacker who strips STARTTLS from the SMTP greeting no longer wins: the sender already knows, from the policy, that encryption is required, so a downgrade causes delivery to fail rather than silently continue. This is the same "remember that this destination requires encryption" idea behind HSTS on the web.
DANE
DANE (DNS-Based Authentication of Named Entities, RFC 7672 for SMTP) takes a different route. It publishes a TLSA record in DNS that pins the receiving server's certificate or public key, and it relies on DNSSEC to keep that record from being forged. A sender that supports DANE looks up the TLSA record, and if the presented certificate does not match, it refuses to deliver. Because the record is DNSSEC-signed, the attacker cannot strip or alter it without breaking the signature chain.
MTA-STS and DANE overlap in purpose but differ in their trust anchor. MTA-STS leans on the web certificate authority system and HTTPS; DANE leans on DNSSEC. Large providers have generally favored MTA-STS for its lower operational barrier, while DANE has strong adoption in parts of Europe and among operators who already run DNSSEC.
| Mechanism | Trust anchor | What it stops |
|---|---|---|
| Plain STARTTLS | None | Passive eavesdropping only. An active attacker strips it. |
| MTA-STS | Web PKI over HTTPS | Downgrade to plaintext, once the policy is cached |
| DANE | DNSSEC | Downgrade and certificate substitution, on first contact |
There is also TLS-RPT (RFC 8460), a reporting standard that lets a domain receive daily summaries of TLS failures other servers hit when trying to send to it. It does not prevent anything by itself, but it turns silent downgrade failures into a signal an administrator can actually see.
Why this matters for the average sender
The uncomfortable truth is that transport encryption for email is hop-by-hop, not end-to-end. STARTTLS, MTA-STS, and DANE all protect the connection between two servers. They do nothing about the message sitting decrypted on each server in between, and they do nothing if one of those hops is compromised or compelled. This is a different guarantee from what people usually mean by "encrypted email."
Transport encryption asks: can someone read this message as it crosses the wire? End-to-end encryption asks: can anyone other than the intended recipient read it at all, including the servers carrying it? These are not the same question. The distinction worth internalizing
If your threat model is a passive network snoop, well-configured STARTTLS plus MTA-STS or DANE is a real improvement. If your threat model includes the mail providers themselves, or a government able to compel them, transport encryption is not the tool for the job. For that, the message contents have to be encrypted before they ever leave your device, which is what content encryption with PGP or S/MIME provides.
Where Haven fits
Haven encrypts message contents client-side with PGP before they touch a server, so the protection does not depend on every hop between mail servers negotiating TLS correctly. Transport hardening like MTA-STS still matters for metadata and for interoperating with the wider email world, and we run it. But the security of your message body does not rest on an opportunistic upgrade that an attacker on the wire can quietly delete. That is the difference between hoping the connection was encrypted and knowing the content was.