Summary

  • STARTTLS could encrypt one SMTP connection, while the store-and-forward system still normally preferred delivery when encryption was unavailable. RFC 8689 gave an individual message a portable instruction: authenticate each next hop, carry the requirement onward and do not fall back to cleartext.
  • A relay unable to find a compliant MX must return a protected non-delivery notice instead of transmitting the message insecurely. REQUIRETLS did not create end-to-end encryption; it made failure an explicit security decision within a chain of trusted mail relays.

Place two envelopes in one outbound queue. They have the same recipient domain, the same available MX servers and the same temporary certificate problem. The first envelope carries ordinary mail. The relay may try TLS and, depending on its policy, still prioritize delivery if encryption cannot be established. The second envelope carries a small internal mark. For that message, the same fallback is forbidden.

The difference is not a stronger cipher. It is authority attached to one stored message.

SMTP was built to move mail across discontinuous custody. A client hands a message to a server; that server may queue it, choose a next hop, retry later or transfer it to another relay. The connection ends while the message remains. A rule that exists only in a TLS session therefore expires too early. It cannot govern the next connection unless the receiving system turns the rule into durable message state.

RFC 8689's REQUIRETLS extension did exactly that. It made a security preference survive the gap between SMTP sessions and made non-delivery preferable to an unprotected hop.

STARTTLS secured a connection, not a message itinerary

The 1999 RFC 2487 introduced STARTTLS for SMTP. Its compatibility problem was severe: public mail exchange could not simply stop whenever the remote side lacked TLS. Mail had long treated eventual delivery as the central obligation, so the extension left room to continue when security was unavailable.

RFC 3207 revised the mechanism in 2002. A server advertises STARTTLS, the client requests it, and both parties begin TLS after a 220 response. When the handshake finishes, knowledge learned in cleartext is discarded and the client sends EHLO again. That rule prevents an attacker-modifiable first greeting from silently governing the protected phase.

But a clean transition still answers a connection question: what may these two SMTP peers do now? It does not attach an instruction to the queued message after one peer accepts it. Nor does it ensure that a later relay will decline cleartext instead of choosing interoperability.

Recipient domains later acquired external policy. RFC 7672 uses DNSSEC-authenticated TLSA records for SMTP DANE. RFC 8461 lets a domain publish an MTA-STS policy naming acceptable MX hosts and requiring TLS with certificate validation. Those mechanisms say what the receiving domain expects. They do not, by themselves, give the originator a distinct answer for one unusually sensitive message among ordinary mail.

The instruction entered through the envelope

Published in 2019, RFC 8689 registered an EHLO capability named REQUIRETLS. It added no SMTP verb. Instead, it added a valueless parameter to the existing envelope command:

MAIL FROM:<sender@example> REQUIRETLS

The location matters. A message header is content delivered with the message; an SMTP envelope controls the current transfer. The sending relay may use the parameter only after it has established TLS, validated the destination and seen REQUIRETLS advertised in the second EHLO inside the protected channel. A cleartext claim that the server supports the extension is not sufficient.

The receiving server must tag the accepted message for REQUIRETLS handling. The standard deliberately does not prescribe a database column, queue-file bit or metadata format. It specifies the obligation. If local aliasing turns the message into several recipient instances, every instance must retain the same tag.

This is the bridge between sessions. The wire parameter becomes stored policy. When that server later acts as a client toward the next relay, it must reconstruct the security conditions and repeat REQUIRETLS on the next MAIL FROM.

Four proofs precede the next transmission

For an ordinary non-bounce message, a conforming sender cannot treat “TLS was used” as enough. Before it passes a REQUIRETLS message onward, it must establish a chain of evidence.

First, it resolves the recipient's SMTP destination using the routing rules in RFC 5321. If the destination came from MX records that were not authenticated by DNSSEC, MTA-STS must validate the permitted server name. Second, the connection itself must be protected by TLS. Third, the presented certificate must validate through an accepted trust chain or DANE. Fourth, the server must advertise REQUIRETLS after STARTTLS, in the new protected EHLO response.

These checks answer different questions. TLS provides channel cryptography. Certificate or DANE validation connects the channel to the intended next hop. DNSSEC or MTA-STS constrains which MX identity counts as intended. The post-TLS capability proves that the next relay promises to preserve the message-level rule.

Collapsing them into one log field such as “encrypted=yes” erases the decision. An encrypted connection to a substituted MX is not the required result. Neither is a valid certificate if the next relay will accept the message but forget the tag.

Failure became the enforcement action

Suppose the preferred MX lacks REQUIRETLS after TLS. The sender quits that attempt and tries the next MX. The same server may still receive ordinary messages from the queue; the restriction belongs to the marked message, not to the destination as a permanent classification.

If no MX meets the requirements, transmission stops. RFC 8689 recommends enhanced status 5.7.30 when the server lacks REQUIRETLS support and 5.7.10 when an encrypted session cannot be established. The sender generates a non-delivery notification to the original reverse path.

That is the protocol's sharpest historical change. Under opportunistic delivery, failure to negotiate security could authorize a less protected attempt. Under REQUIRETLS, the same failure removes authority to send. Reliability is no longer measured only by whether bytes arrive. Returning evidence that the constraint could not be satisfied is the more faithful outcome.

The choice is costly. A transient certificate error, policy discovery failure or missing capability can delay or defeat a message that might otherwise arrive. REQUIRETLS does not hide the trade. It assigns the decision to the sender and makes the resulting failure observable.

Even the bounce inherited the secret

A non-delivery notice often contains the failed message's headers. It may reveal sender, recipients, subject lines or routing clues. Sending the original only through protected hops and then returning its diagnostic in cleartext would defeat part of the decision.

RFC 8689 therefore requires bounces caused by REQUIRETLS messages to carry REQUIRETLS too, even when the original failure was unrelated to TLS. It also narrows the quoted material: the bounce behaves as though DSN RET=HDRS had been requested, and a conflicting request for RET=FULL is ignored.

The return path creates a recursion problem. SMTP bounces use an empty reverse path so that a failed bounce does not generate another bounce forever. The secure path back may also differ from the forward path. The standard consequently warns that a protected diagnostic may be lost, and it makes an exception for the empty-return-path message when the next hop lacks REQUIRETLS.

Silence is therefore ambiguous. The sender may know that the original was not transmitted to the destination, yet never receive the protected explanation. An absent bounce is not evidence of delivery.

The surprising header said “No”

RFC 8689 also defined TLS-Required: No. The name looks like the inverse of the envelope parameter because it is. Its purpose is to let a sender request that recipient-side DANE or MTA-STS policy not prevent delivery—perhaps to tell an administrator that the destination's certificate is broken.

The relay should still attempt STARTTLS. The header does not order cleartext; it changes what happens if TLS or policy validation fails. If the receiving server itself refuses unencrypted SMTP, its decision still wins. Sender policy cannot force a peer to accept a connection.

If both the protected envelope parameter and the header are present, the envelope instruction governs and the header is ignored for handling. A message may contain only one such header. This precedence prevents untrusted content inside a REQUIRETLS transfer from weakening the obligation negotiated on the envelope.

Relaying was easier than reoriginating

A normal relay can carry the tag from one envelope to the next. A mailing list, forwarding service, Sieve program or vacation responder may instead create a new message. The original SMTP transaction has ended; headers may be rewritten, recipients multiplied and ownership transferred.

RFC 8689 asks these mediators to apply the incoming choice to newly originated messages as far as feasible. It cannot make the boundary disappear. A list expanded to hundreds of recipients may find that some paths support REQUIRETLS and others do not. A user-side filter may never see the SMTP envelope tag at all.

This is where a portable instruction meets institutional reality. The protocol can define how conforming relays preserve a mandate. It cannot prove that every intermediary is a relay rather than a new author, or that every trusted MTA will behave honestly.

Transport protection still trusted the transporters

REQUIRETLS is not end-to-end encryption. Each participating MTA terminates TLS and can read the message before starting another protected connection. A malicious relay can advertise support, accept the marked message and then strip its tag. RFC 8689 places such a relay outside the threat model because it already possesses the plaintext.

The extension is useful against passive observation, STARTTLS stripping, substituted MX routes and accidental fallback among conforming systems. It does not authenticate the human author, encrypt stored queues, conceal content from relays or prove the final outcome after the next handoff.

The IANA SMTP registry records the REQUIRETLS token and its reference. That row proves a standardized assignment. It does not measure deployment, message volume or operational compliance.

The durable idea is smaller and more precise. A store-and-forward network needs a way for a decision to outlive its connection. REQUIRETLS turned “please use encryption” into “if you cannot preserve this condition, fail visibly and do not send.” The message did not merely request a safer road. It defined which destination outcomes were still legitimate.