Subject: Re: [EAI] [Technical Errata Reported] RFC6857 (6573)

From: John C Klensin <[email-masked]>
Date: Sat, 09 Apr 2022 23:23:33 -0400

Somehow, it took me just short of a year to notice this and
notice that there were deeper problems.  Note that a previous
verified erratum on this subject is incorrect, so there may be a
bit of untangling to do.

Executive Summary although I hope people will read what follows
(and I think it is worth having as part of the record): If there
are implementations and deployments of this downgrade model,
they would have needed to be by people who knew what it was
supposed to save and implemented that because there are errors
in the spec itself that would cause every IMAP and POP client I
know of (and probably most servers) to develop serious
indigestion.   The observation that we have gone eleven years
with only some difficulties in the examples being noticed (and
none of those reports catching the most important problems) is
definitely not a sign of implementations based on the spec
itself.  I think we need to either find those who still care and
get an update produced that fixes the substantive errors
(including updating another spec that this one violates) and
deprecates or replaces the appendix or we should start the
process to declare 6858 the winner and obsolete 6857 (and maybe
6856).

     ---------------

I think the submitter is correct that there is an error here,
but it is more complex, it uncovers a few more, and the proposed
fix is not particularly helpful.

Going to the Appendix or RFC6857, we first see

   o  The sender address is a non-ASCII address,
      "[email-masked]".  Its display-name is
      "DISPLAY-LOCAL".

Then, in the example incoming message, it shows the
corresponding header field

   From: DISPLAY-LOCAL <[email-masked]>

Nothing there puts non-ASCII characters in DISPLAY-LOCAL and
Section 3.1.5, says, in part...

   ...and they have <display-name> elements that contain 
   non-ASCII strings, encode the <display-name> elements 
   as encoded-words.

So, DISPLAY-LOCAL should not be encoded at all.   Moreover, if
there is a <display-name>, then the <mailbox> MUST be in pointed
brackets or an RFC 5322 parser won't work.  While I thought the
intent was clear, that probably means there is an error in
Section 3.1.8 because it 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 " :;"

   where the <ENCODED-WORD> is the original <addr-spec> encoded
as
   encoded-words.

That is fine when <addr-spec> appears alone because it just
discards the unnecessary pointed brackets.  However, if a
<display-name> is present in the address, the brackets MUST be
present and MUST be outside the encoding because RFC 5322 (and
the current version of 5322bis) does not know anything about
encoded words or encoding generally.  I also can't tell where
the ":;" comes from in this non-group syntax and suspect it is
another error (see Erratum 6930).   So the correct form of the
example text might almost be:

   From: DISPLAY-LOCAL
         <=?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?=>

(following the suggestion in Erratum 3955).   But that does not
work either.  First, RFC 2047 explicitly prohibits encoded words
"in any portion of an 'addr-spec'" [RFC2047 Section 5(3)].  RFC
6587 does not update 2047 and I can't find anything else that
changes that prohibition either.  Second, Sections 3.1.6. and
3.1.8 prohibit putting the <domain> part of an address into
encoded words; ones containing non-ASCII labels MUST be encoded
as A-labels.   And, finally, as suggested above, a downgrade
mechanism is fairly useless if it produces output that a
traditional IMF/RFC 5322, header fields in ASCII only, system
will reject.  So I think the correct example, modulo the need to
update RFC 2047, would be

   From: DISPLAY-LOCAL
         <=?UTF-8?Q?NON-ASCII-LOCAL?=@example.com>

   ------------

Suggestion about Errata Report:
   "Hold for document update", with the understanding that the
Appendix is going to need a rather thorough reworking.
   Also, Erratum 3955 should be retroactively changed to "Hold
for document update" as well.  Like this report, it correctly
identifies a problem, but does not supply a correct fix.

--On Wednesday, May 5, 2021 12:44 -0700 RFC Errata System
<[email-masked]> wrote:

> The following errata report has been submitted for RFC6857,
> "Post-Delivery Message Downgrading for Internationalized Email
> Messages".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6573
> 
> --------------------------------------
> Type: Technical
> Reported by: Kaspar Etter <[email-masked]>
> 
> Section: A
> 
> Original Text
> -------------
>    From: =?UTF-8?Q?DISPLAY-LOCAL?=
>          =?UTF-8?Q?NON-ASCII-LOCAL=40example=2Ecom?= :;
> 
> Corrected Text
> --------------
>    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:
> [email-masked] :; (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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary,
> please use "Reply All" to discuss whether it should be
> verified or rejected. When a decision is reached, the
> verifying party   can log in to change the status and edit the
> report, if necessary. 
> 
> --------------------------------------
> RFC6857 (draft-ietf-eai-popimap-downgrade-08)
> --------------------------------------
> Title               : Post-Delivery Message Downgrading for
> Internationalized Email Messages Publication Date    : March
> 2013
> Author(s)           : K. Fujiwara
> Category            : PROPOSED STANDARD
> Source              : Email Address Internationalization
> Area                : Applications
> Stream              : IETF
> Verifying Party     : IESG