SMTP Require TLS Option
Extracted elements (28)
Mediators (mailing lists, Sieve filters, vacation responders) should apply REQUIRETLS requirements from incoming messages to reoriginated messages where feasible. User-side mediators typically lack SMTP-level detail and may be unaware of REQUIRETLS tags; recipients expecting sensitive traffic should avoid user-side mediators.
REQUIRETLS uses two complementary mechanisms: an SMTP service extension (requiring end-to-end REQUIRETLS support across all relay hops) and a message header field (which can transit MTAs that do not support REQUIRETLS). This split allows both strict enforcement and best-effort delivery use cases.
The TLS-Required: No header field exists to allow senders to override recipient-side TLS policies (MTA-STS, DANE) in exceptional cases such as reporting a misconfigured or expired TLS certificate on the recipient's mail server, where strict policy enforcement would block the diagnostic message.
Messages tagged 'TLS-Required: No' may be relayed through MTAs that do not support REQUIRETLS; as a result, the REQUIRETLS SMTP option will not be uniformly observed across all relay hops for such messages.
The REQUIRETLS extension is valid for message relay (RFC 5321), submission (RFC 6409), and the Local Mail Transfer Protocol (LMTP, RFC 2033). Mail delivery agents supporting REQUIRETLS SHOULD observe RFC 8314 guidelines for end-user retrieval protocols (IMAP, POP).
All non-delivery messages resulting from REQUIRETLS messages MUST also specify the REQUIRETLS SMTP option, protecting bounce metadata the same way as the original message, unless the message is redacted.
An MUA or submission agent wishing to require TLS MUST negotiate STARTTLS and REQUIRETLS and include the REQUIRETLS option on MAIL FROM. When TLS is not to be required, the sender MUST include the TLS-Required header field in the message.
Following REQUIRETLS delivery failure, the SMTP client MUST send a non-delivery notification to the reverse-path. Status code 5.7.30 ('REQUIRETLS support required') SHOULD be used when the server lacks REQUIRETLS; 5.7.10 ('Encryption needed') when TLS cannot be established.
Following STARTTLS negotiation, the SMTP server MUST advertise REQUIRETLS support in the subsequent EHLO response before the client may use the REQUIRETLS MAIL FROM option.
If a message is being locally aliased and redistributed to multiple addresses, all instances of the redistributed message MUST be tagged with the same REQUIRETLS handling as the original.
If any REQUIRETLS step fails (TLS negotiation, certificate validation, or REQUIRETLS not advertised), the client MUST issue QUIT and retry with subsequent MX hosts. If no more MX hosts remain, the client MUST NOT transmit the message.
The REQUIRETLS MAIL FROM option MUST only be specified in the context of an SMTP session that: (1) employs TLS transmission, (2) has validated the server's MX hostname via DNSSEC or MTA-STS, and (3) has verified the server's certificate via trust chain or DANE.
Upon receipt of the REQUIRETLS MAIL FROM option, an SMTP server MUST tag that message as needing REQUIRETLS handling. If a REQUIRETLS MAIL FROM parameter is specified, the TLS-Required header field MUST be ignored (but MAY be included in onward relay).
When a REQUIRETLS message is bounced, the server MUST behave as if RET=HDRS were present (per RFC 3461); if both RET=FULL and REQUIRETLS are present, RET=FULL MUST be disregarded to avoid leaking full message content in the bounce.
When sending a 'TLS-Required: No' tagged message, the sending MTA MUST open an SMTP session and attempt STARTTLS if possible, but MUST NOT fail delivery if STARTTLS cannot be negotiated; recipient domain policies (MTA-STS, DANE) MUST be ignored.
When the MX lookup for a REQUIRETLS message is not accompanied by a valid DNSSEC signature, the client MUST also validate the SMTP server name using MTA-STS. The server hostname MUST match the DNS-ID or CN-ID of the certificate presented.
REQUIRETLS is an SMTP service extension that allows a sender to assert that a given message MUST be relayed over a TLS-protected session with verified server identity. It uses the EHLO keyword 'REQUIRETLS' and adds an optional 'REQUIRETLS' parameter to the MAIL FROM command.
TLS-Required is a new message header field used to request that recipient-side TLS policy mechanisms (MTA-STS, DANE) be ignored when relaying a message. Its only defined parameter value is 'No', indicating the sender prioritizes delivery over enforced TLS.
IANA added enhanced status code X.7.30 ('REQUIRETLS support required') to the 'Enumerated Status Codes' subregistry of the 'SMTP Enhanced Status Codes Registry', associated with basic status code 550, indicating a message could not be forwarded because no next-hop SMTP server supports REQUIRETLS.
IANA added 'REQUIRETLS' to the 'SMTP Service Extensions' subregistry of the 'Mail Parameters' registry. The EHLO keyword 'REQUIRETLS' has no parameters, no additional SMTP verbs, adds the REQUIRETLS parameter to MAIL, and increments the command length by 11 characters.
IANA added 'TLS-Required' to the 'Permanent Message Header Field Names' subregistry of the 'Message Headers' registry, applicable to the mail protocol with standard status.
Bounce (non-delivery) messages for REQUIRETLS-tagged messages must themselves be sent with REQUIRETLS; if the return path lacks REQUIRETLS support, bounce messages will be lost. Senders requiring TLS should ensure they can also receive mail using REQUIRETLS to avoid losing bounce notifications.
REQUIRETLS defends against man-in-the-middle attacks by requiring successful certificate validation (via trust chain or DANE) before sending a message; connections that lack verified server identity are rejected. DNS MX record spoofing is countered by requiring DNSSEC validation or MTA-STS policy confirmation of MX hostnames.
REQUIRETLS is a transport-layer security mechanism only; messages are not encrypted end-to-end and are visible in cleartext to intermediate MTAs on the delivery path. Messages containing sensitive content that MTAs should not access MUST use end-to-end content encryption such as OpenPGP or S/MIME.
REQUIRETLS is effective against passive eavesdropping attacks because it refuses to send messages in the clear if TLS negotiation fails. Active attacks that modify the STARTTLS command (e.g., replacing it with an illegal string) are also defeated, as REQUIRETLS detects STARTTLS failure and declines to transmit.
The 'TLS-Required: No' header field may conflict with recipient domain policies expressed via DANE or MTA-STS. It effectively instructs the client MTA to behave as if it does not support those mechanisms; the recipient domain can still enforce TLS by refusing connections without STARTTLS.
The REQUIRETLS MAIL FROM parameter is encoded as the keyword 'REQUIRETLS' with no associated value: `requiretls-param = "REQUIRETLS"`. It adds 11 octets (space + keyword) to the maximum MAIL FROM command line length.
The TLS-Required header field ABNF is: `requiretls-field = "TLS-Required:" [FWS] "No" CRLF`. Only the value 'No' is defined. More than one instance of this header MUST NOT appear in a given message.