Found 3 records.

Status: Verified (1)

RFC 6857, "Post-Delivery Message Downgrading for Internationalized Email Messages", March 2013

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

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.

Report New Errata