Required TLS is a request on the message

Answer Required TLS is a request on a particular message, not a hop that happened to be encrypted. RFC 8689 defines REQUIRETLS. The sender can say this message must be relayed over TLS. If the next server cannot do that, the message is supposed to stop, not fall back to cleartext. That is not inbox placement, and it is not the same fact as a single successful upgrade.

The note that started this: RFC 8689, SMTP Require TLS Option, RFC 8689.

Sellers say the mail is secure and point at a padlock on a slide. The padlock is often the session between their laptop and their platform. The message then crosses other networks. REQUIRETLS is the tool for saying the rest of the trip has to stay encrypted too, or the message should not finish the trip. If you buy solo ads, ask which of those two stories you are being told.

The specification gives the sender two related mechanisms. One is an SMTP parameter on the mail transaction. The other is a header, TLS-Required. Used in the requiring direction, they ask every onward relay to use TLS and to keep the requirement attached. There is also a way to say TLS is not required, for the odd case where a sender must get a message through even when a recipient's policy is in the way. You will almost never want that second direction on a solo ad. Know that it exists so a screenshot of the header is not automatically a promise.

What is REQUIRETLS?

RFC 8689 defines an SMTP option and a header so a sender can require that a message be relayed over TLS. If a later hop cannot do that, the message is not supposed to go on in the clear.

The failure has a name. When a message that required TLS cannot be forwarded because the next server does not support the requirement, the status text associated with this document is that REQUIRETLS support is required. The basic code is a permanent failure. Permanent here means do not sneak the message through unprotected. It does not mean the address is dead, and it does not mean the copy was bad. A seller who has never seen the status has probably never turned the requirement on. That is allowed. It is not the same as claiming the requirement.

Adoption is not a census this note will invent. The specification is the request. Whether a given platform offers the switch is a question for that platform. Ask. If the answer is a shrug, they are not using this document, whatever the slide says about encryption.

• The quote says whether this message requires TLS onward.
• A single upgraded hop is described as a single hop.
• A failure to meet the requirement is not called a bad address.
• Inbox placement is not listed as a benefit of the flag.

Is REQUIRETLS the same as a hop that used STARTTLS?

No. A hop can upgrade because both sides felt like it. REQUIRETLS is a request attached to the message that onward relay must use TLS. One lucky handshake is not that request.

STARTTLS is an offer on a connection. The offer can succeed today and fail tomorrow, and the message has no memory of the demand. REQUIRETLS is the message asking to be treated as mandatory. A policy published by the recipient domain, the kind that tells senders what TLS they expect, is a third object. Three mechanisms, three sentences. A seller who uses one word for all three has not looked.

You do not need them to implement every mechanism before you pay. You need them to stop upgrading the vocabulary. If they mean the submission session is encrypted, they should say submission. If they mean this creative must not travel in the clear, they should say so, and they should be able to point at the flag or admit they cannot set it.

Does required TLS put a solo ad in the inbox?

No. It is about encryption on the relay. It does not decide placement, and it does not make an unwanted list wanted. Ask the seller not to sell it as delivery.

Encryption stops a listener on the path from reading the message in transit. The recipient's provider can still file it as spam. The recipient can still complain. The list can still be a list that never asked. A buyer who pays a premium for required TLS has paid for a property of the path. The path is worth protecting. It is not the product. The product is a click from people who had a reason to see the offer.

RFC 8689 lets a sender be strict about the pipe. Be strict about the pipe if you can. Then go back to the list. A locked pipe can carry unwanted mail just as faithfully as an open one.