Found 2 records.

Status: Reported (2)

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

Errata ID: 7705
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Mechiel Lukkien
Date Reported: 2023-11-20

Section 4.2.1 says:

   4.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate as specified in
       [RFC6125] or [RFC7672], as applicable.  The hostname from the MX
       record lookup (or the domain name in the absence of an MX record
       where an A record is used directly) MUST match the DNS-ID or CN-
       ID of the certificate presented by the server.

It should say:

   4.  Establish a TLS-protected SMTP session with its peer SMTP server
       and authenticate the server's certificate as specified in
       [RFC6125] or [RFC7672], as applicable.

Notes:

The second sentence tries to explain/summarize the policies found in the RFCs referenced in the first sentence, about PKIX and DANE. But the explanation seems to accidentally sets new requirements that contradict behaviour specified by DANE: With DANE-EE TLSA records, no specific hostname validation must be done, instead verification is done based on (hash of) SPKI/entire certificate. (DANE-TA hostname verification is also a bit more nuanced). Since the requirements are accurately explained in the RFCs referenced in the first sentence, it seems better to completely remove the second sentence.

I would also like to point out that implementers may want to take care not to treat the situation where all TLSA records are "unusable" (as explained in DANE RFCs) as "authenticated with DANE", in line with "[...] or it MUST be verified successfully using DANE [...]" on line 197.

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