The following errata report has been rejected for RFC8689, "SMTP Require TLS Option".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8593 -------------------------------------- Status: Rejected Type: Technical Reported by: Liam W <[email protected]> Date Reported: 2025-10-04 Rejected by: Deb Cooley (IESG) 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 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). --VERIFIER NOTES-- It’s important to say what the REQUIRETLS mechanisms do rather than to focus on how they might be used. Misconfigured recipient servers might be one example, but there might be other examples where security is indeed unimportant and the sender would rather that the message be potentially misdelivered than deal with bounce messages. The focus of the standard is on the protocol itself vs how the mechanisms are used. Furthermore, this is only the document abstract it doesn't need to focus on use cases. -------------------------------------- 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]
