Please let me know whether this errata should be validated, rejected, or 'hold for document update'
TY, Deb your new Sec AD On Mon, Oct 6, 2025 at 4:53 PM Madison Church <[email protected]> wrote: > 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]
