RFC Errata
Found 4 records.
Status: Verified (1)
RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013
Source of RFC: eai (app)
Errata ID: 3955
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2014-04-10
Verifier Name: Barry Leiba
Date Verified: 2014-04-16
Section A says:
Received: from ... by ... Received: from ... by ... From: =?UTF-8?Q?DISPLAY-LOCAL?= =?UTF-8?Q?NON-ASCII-LOCAL@example.com?= :; To: =?UTF-8?Q?DISPLAY-REMOTE1?= =?UTF-8?Q?NON-ASCII-REMOTE1@example.net?= :;, =?UTF-8?Q?DISPLAY-REMOTE2?= =?UTF-8?Q?NON-ASCII-REMOTE2@example.com?= :;, Cc: =?UTF-8?Q?DISPLAY-REMOTE3?= =?UTF-8?Q?NON-ASCII-REMOTE3@example.org?= :;
It should say:
Received: from ... by ... Received: from ... by ... From: =?UTF-8?Q?DISPLAY-LOCAL?= =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :; To: =?UTF-8?Q?DISPLAY-REMOTE1?= =?UTF-8?Q?NON-ASCII-REMOTE1=40example=2Enet?= :;, =?UTF-8?Q?DISPLAY-REMOTE2?= =?UTF-8?Q?NON-ASCII-REMOTE2=40example=2Ecom?= :;, Cc: =?UTF-8?Q?DISPLAY-REMOTE3?= =?UTF-8?Q?NON-ASCII-REMOTE3=40example=2Eorg?= :;
Notes:
The characters '@' and '.' cannot appear in an encoded-word occurring
in a phrase (see rule 3 of section 5 of RFC 2047), so they must be escaped
with '=40' and '=2E', respectively, in the Q encoding.
Status: Reported (2)
RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013
Source of RFC: eai (app)
Errata ID: 6573
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Kaspar Etter
Date Reported: 2021-05-05
Section A says:
From: =?UTF-8?Q?DISPLAY-LOCAL?= =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;
It should say:
From: =?UTF-8?Q?DISPLAY-LOCAL_?= =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;
Notes:
Taking the original text from Errata 3955 (https://www.rfc-editor.org/errata/eid3955), the two encoded-words decode to: DISPLAY-LOCALNON-ASCII-LOCAL@example.com :; (According to section 6.2 of RFC 2047, linear whitespace between adjacent encoded-words is ignored.) This is clearly not desirable and thus a space should be encoded at the end of all display names in appendix A.
Errata ID: 6930
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Klensin
Date Reported: 2022-04-10
Section 3.1.8 says:
The <addr-spec> element that contains non-ASCII strings may appear in two forms as: "<" addr-spec ">" or addr-spec Rewrite both as: ENCODED-WORD " :;"
It should say:
The <addr-spec> element that contains non-ASCII strings may appear in two forms as: "<" local-part "@" domain ">" or local-part "@" domain If the <local-part> contains non-ASCII characters, rewrite both to: ENCODED-WORD "@" domain If the <domain> contains non-ASCII characters in any of its labels, they MUST appear in A-label form as described in Section 3.1.6. If the <addr-spec> is part of a <mailbox> specification that contains a <display-name>, the display name should be handled as per the discussion in Section 3.1.5 and the <mailbox> and <addr-spec> containing non-ASCII characters MUST appear as DISPLAY-NAME "<" ENCODED-WORD "@" domain ">" for consistency with RFC 5322.
Notes:
Recommend "Hold for document update" and see the extensive comments on Erratum 6573.
The text above, while correct, is fairly horrible and might make the confusion between the requirements of Sections 3.1.5 and 3.1.8 even worse. A complete rewrite of this section and possibly 3.1.5 would be a better fix. Note the prohibition on Encoded Words in <addr-spec> in RFC 2047, which requires updating. Also note that the " :;" construction, which is correct in Section 3.1.7, does not belong in the above.
It also not clear to me why, under some principle of minimal change, the brackets should not be just left alone if they appear in the original with no adjacent display-name.
Status: Held for Document Update (1)
RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013
Source of RFC: eai (app)
Errata ID: 5419
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Peter Occil
Date Reported: 2018-07-13
Held for Document Update by: Alexey Melnikov
Date Held: 2018-07-26
Section 3.2.1 says:
From: Sender: To: Cc: Bcc: Reply-To: Resent-From: Resent-Sender: Resent-To: Resent-Cc: Resent-Bcc: Resent-Reply-To: Return-Path: ^^^^^^^^^^^ Disposition-Notification-To:
It should say:
From: Sender: To: Cc: Bcc: Reply-To: Resent-From: Resent-Sender: Resent-To: Resent-Cc: Resent-Bcc: Resent-Reply-To: Disposition-Notification-To:
Notes:
Under RFC 5322 sec. 3.6.7, the Return-Path header field contains no production named "address", but at most a production named "angle-addr", which does not accept display names, for one. An update to this RFC could discuss this header field in its own section.
I agree with John Levine's comment on this:
This erratum is correct. I would suggest hold for update, since it is not
my impression that this flavor of downgrade is used very much if at all.