I disagree with this erratum. Aside from the general rewording of the
abstract, the core of the submitter’s justification for the change is:
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.
I think it’s important to say what the REQUIRETLS mechanisms do rather
than to focus on how the 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.
We will see how these mechanisms are used, but the focus of the standard
is on the protocol itself. Furthermore, this is only the document
abstract and I don’t think it needs to focus on use cases.
I recommend rejecting this. Other opinions?
-Jim
On 25 Mar 2026, at 5:02, Deb Cooley wrote:
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]
