Summary

  • STARTTLS upgraded an existing SMTP connection, but the upgrade did not inherit the first cleartext conversation: after TLS, both peers discarded pre-handshake knowledge and the client greeted the server again.
  • That reset protected the new security context from old, modifiable claims. It did not itself make encryption mandatory or authenticate every mail hop; DANE and MTA-STS later supplied policy evidence that could forbid silent cleartext fallback.

One connection contained two beginnings

In ordinary SMTP, the server opened with 220, the client identified itself with EHLO, and the server answered with extensions it was prepared to use. In 1999, STARTTLS fitted a security transition into that familiar sequence. The server added one parameterless word to its EHLO response. The client could answer with STARTTLS; a 220 reply ended the cleartext phase and began the TLS handshake.

The economy was attractive. Operators did not need a second public mail-routing system or a new MX vocabulary. Old clients could continue speaking old SMTP. New peers could discover encryption on the connection they had already opened.

But discovery occurred before protection. An on-path adversary could edit the client's first identity, alter extensions or delete the STARTTLS line. The bytes before the handshake were useful for reaching the security boundary, not trustworthy input for decisions made after it.

Encryption required amnesia

The standard therefore imposed an unusual discipline. Once TLS completed, SMTP returned to the state immediately after the server's original service-ready greeting. The server discarded information learned from the client before TLS, including the first EHLO argument. The client discarded the first extension list. It then sent EHLO again.

This was not ceremonial repetition. The second greeting belonged to a different evidentiary context. A server might advertise an authentication mechanism only after receiving a suitable client certificate. A client might accept a capability only after validating the server under its chosen policy. Pre-TLS claims could not leak across the boundary as if the handshake had vouched for them.

STARTTLS also became a hard framing point. After the server replied 220, the client had to start TLS before sending another SMTP command; when PIPELINING grouped commands, STARTTLS was last in its group. Otherwise a cleartext command could be confused with handshake bytes, or a command chosen under the old capability set could arrive in the new state.

A protected channel still needed a verdict

TLS could provide confidentiality, integrity and peer authentication, but the protocol did not decree that every negotiated result was good enough. Certificate identity, trust anchors, algorithms and client credentials belonged to local policy. Either side could decide to stop when the achieved privacy or authentication was insufficient.

That distinction prevented a successful handshake from becoming an all-purpose seal. Encryption against a passive observer was not necessarily authenticated delivery to the intended MX. A verified relay was not proof of the human author. One protected SMTP hop said nothing certain about the submission hop before it or the next relay after it.

The 454 response made the trade-off explicit. When TLS was temporarily unavailable, a sender could transmit in cleartext, queue and retry, or fail. The extension supplied a mechanism; the sender still owned the consequence of fallback.

Interoperability limited the first mandate

Public Internet mail had a demanding failure rule: a recipient's MX needed to receive messages from senders that had not upgraded. RFC 3207 therefore prohibited a publicly referenced port-25 server from requiring STARTTLS merely for local delivery. Private servers and relay services could demand it, and authentication established in TLS could govern relaying, but the open receiving edge remained compatible.

That choice accelerated incremental deployment and preserved reachability. It also meant that STARTTLS advertisement alone could not express a durable confidentiality promise. If an attacker removed the offer, an opportunistic sender might see an ordinary cleartext server and deliver anyway.

The weakness was not that TLS encryption failed. It was that the policy requiring TLS travelled inside the unprotected conversation it was supposed to constrain.

Later standards moved policy outside the conversation

DANE for SMTP coupled the destination's TLS commitment and authentication material to DNSSEC-validated TLSA records. When a secure applicable record existed, the sender could no longer treat a missing STARTTLS advertisement as permission to continue. Failure to negotiate the required channel delayed delivery instead of revealing the message.

MTA-STS chose another trust path. A recipient published a discoverable policy and served its contents over HTTPS. A sender cached acceptable MX patterns, PKIX expectations and an enforcement lifetime. During that lifetime, a stripped STARTTLS line or invalid certificate produced queueing rather than silent downgrade. Initial policy discovery retained a different exposure because ordinary DNS could still be interfered with, while caching narrowed later opportunities.

Both designs changed where authority lived. STARTTLS remained the in-band transition. External policy answered the separate question: was the sender permitted to proceed without it?

The repeated greeting was the durable invention

It is tempting to remember STARTTLS as a switch from plaintext to ciphertext. Its more general contribution was a clean state boundary inside a long-lived protocol. Claims learned before protection were not upgraded retroactively. They expired. Capabilities were rediscovered, identity was evaluated under explicit policy, and failure remained distinguishable from permission to fall back.

That pattern matters wherever security is added to an established conversation. A new cryptographic layer cannot cleanse decisions already made from attacker-controlled input. The system must name which state survives, which state is erased, and who may authorize weaker operation.

Sources and limits

The original transition and downgrade warning appear in RFC 2487; the revised SMTP rules, reset and interoperability boundary are in RFC 3207. RFC 7672 defines opportunistic DANE TLS for SMTP, and RFC 8461 defines MTA-STS. These specifications do not measure present deployment, global downgrade attacks or provider defaults.