RFC 8689, "SMTP Require TLS Option", November 2019

Errata ID: 8593
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Liam W
Date Reported: 2025-10-04

Section Abstract says:

If the REQUIRETLS option or TLS-Required message header field is used 
when sending a message, it asserts a request on the part of the message 
sender to override the default negotiation of TLS, either by requiring 
that TLS be negotiated when the message is relayed or by requesting 
that recipient-side policy mechanisms such as MTA-STS and DNS-Based 
Authentication of Named Entities (DANE) be ignored when relaying a 
message for which security is unimportant.

It should say:

If the REQUIRETLS option or TLS-Required message header field is used
when sending a message, it indicates the sender's preference for
transport-level encryption: REQUIRETLS mandates that the message be
relayed over a TLS-protected session, whereas the TLS-Required header
field allows the sender to request that recipient-side policy
mechanisms, such as MTA-STS and DNS-based Authentication of Named
Entities (DANE), be temporarily ignored – for example, so as to overcome
configuration errors when delivery takes precedence and the
security of the message is unimportant.

Notes:

This wording is slightly misleading as the 'TLS-Required: No' header field is intended to ignore recipient-side policies, prioritizing delivery. However, it is not meant for messages "for which security is unimportant", but rather for cases like misconfigured recipient servers. The wording could be misinterpreted as allowing insecure delivery for convenience.

The corrected text clarifies the distinction between REQUIRETLS and TLS-Required.Emphasizes that TLS-Required is for exceptional cases (not general insecurity).

Report New Errata