Hi Liam, We have updated the errata report to use the correct version of the Corrected Text (see https://www.rfc-editor.org/errata_search.php?eid=8593).
Thank you! Madison Church RFC Production Center > On Oct 4, 2025, at 10:14 AM, Liam Waddicor <[email protected]> wrote: > > My apologies, I see I pasted the incorrect corrected text from my editor, the > last line is changed slightly in this one, the correct version is: > > Corrected Text > -------------- > 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. > > On Sat, 4 Oct 2025 at 16:51, RFC Errata System <[email protected]> > wrote: > The following errata report has been submitted for RFC8689, > "SMTP Require TLS Option". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8593 > > -------------------------------------- > Type: Technical > Reported by: Liam W <[email protected]> > > Section: Abstract > > Original Text > ------------- > 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. > > Corrected Text > -------------- > 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 or when 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). > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8689 (draft-ietf-uta-smtp-require-tls-09) > -------------------------------------- > Title : SMTP Require TLS Option > Publication Date : November 2019 > Author(s) : J. Fenton > Category : PROPOSED STANDARD > Source : Using TLS in Applications > Stream : IETF > Verifying Party : IESG _______________________________________________ Uta mailing list -- [email protected] To unsubscribe send an email to [email protected]
