Re: [EAI] [Technical Errata Reported] RFC6857 (6573)
John C Klensin <john-ietf@jck.com> Sun, 10 April 2022 03:23 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ima@ietfa.amsl.com
Delivered-To: ima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D103A1277; Sat, 9 Apr 2022 20:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knP8_Vff4Ejj; Sat, 9 Apr 2022 20:23:47 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840A53A1278; Sat, 9 Apr 2022 20:23:45 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ndOAt-00092h-6Z; Sat, 09 Apr 2022 23:23:39 -0400
Date: Sat, 09 Apr 2022 23:23:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, fujiwara@jprs.co.jp
cc: superuser@gmail.com, Francesca Palombini <francesca.palombini@ericsson.com>, barryleiba@computer.org, jyee@afilias.info, me@kasparetter.com, ima@ietf.org
Message-ID: <DEC8A7167F53F779E041EC6F@PSB>
In-Reply-To: <20210505194443.715AAF4078E@rfc-editor.org>
References: <20210505194443.715AAF4078E@rfc-editor.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ima/pFB--rvw0YXE-Nrh44uUNnWMWqE>
Subject: Re: [EAI] [Technical Errata Reported] RFC6857 (6573)
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ima/>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2022 03:23:52 -0000
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, "NON-ASCII-LOCAL@example.com". Its display-name is "DISPLAY-LOCAL". Then, in the example incoming message, it shows the corresponding header field From: DISPLAY-LOCAL <NON-ASCII-LOCAL@example.com> 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 <rfc-editor@rfc-editor.org> 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 <me@kasparetter.com> > > 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: > 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. > > 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
- [EAI] [Technical Errata Reported] RFC6857 (6573) RFC Errata System
- Re: [EAI] [Technical Errata Reported] RFC6857 (65… ned+ima
- Re: [EAI] [Technical Errata Reported] RFC6857 (65… John C Klensin