Re: [ietf-smtp] How wrong is this EAI implementation

John C Klensin <> Tue, 23 June 2020 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79F1D3A0C07 for <>; Tue, 23 Jun 2020 16:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8gWMSch7xLv7 for <>; Tue, 23 Jun 2020 16:17:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 824343A0C2D for <>; Tue, 23 Jun 2020 16:17:04 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jns9y-000GCV-R3; Tue, 23 Jun 2020 19:16:58 -0400
Date: Tue, 23 Jun 2020 19:16:52 -0400
From: John C Klensin <>
To: Arnt Gulbrandsen <>, John Levine <>
Message-ID: <4B400734391D5DC6CD7FBBB2@PSB>
In-Reply-To: <>
References: <alpine.OSX.2.22.407.2006201429080.28792@ary.qy> <2B0EB3A9E99431F86620038A@[]> <alpine.OSX.2.22.407.2006201823060.29484@ary.qy> <DC26ED76E7E316714AB2B820@[]> <> <alpine.OSX.2.22.407.2006201429080.28792@ary.qy> <2B0EB3A9E99431F86620038A@[]> <alpine.OSX.2.22.407.2006201823060.29484@ary.qy> <DC26ED76E7E316714AB2B820@[]> <> <kzlyExy/> <20200621145342.7364B1B4460D@ary.qy> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [ietf-smtp] How wrong is this EAI implementation
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2020 23:17:06 -0000

--On Tuesday, June 23, 2020 15:09 +0200 Arnt Gulbrandsen
<> wrote:

> On Sunday 21 June 2020 16:53:42 CEST, John Levine wrote:
>> I don't think that 5321 requires that and
>> bob@EXAMPLE.COM be treated the same, either.
>> Beyond some point, you can't force people to be reasonable.
> Agree entirely. And this is why I think the EAI specs are too
> subtle on this point.
> I do have an opinion about what that point is, and what the
> documents ought to say. But my real issue is that it's
> possible to review source code against every MUST and SHOULD
> in 653x and miss that there's something to consider.

In my capacity as the former co-chair of the former WG a few
observations while speaking only for myself:

* Like so many other i18n efforts in the IETF in recent years,
the WG had mostly run out of energy by the time it got those
documents out.  I don't know if there would be energy and the
needed focus to start (and ultimately finish) clarifying
documents but other events of the last year or two leave me very

* There were several important contributors to EAI WG-produced
specs who remain on the list (although even some of
them have move on to other work professionally) but who are not
on this one.   Absent a move by the relevant ADs (presumably
after discussion on both lists) to consolidate them, if one
wants to have a serious discussion about SMTPUTF8 ("EAI")
issues, those issues should probably be addressed there (instead
or in addition).

* Just as I think that the "core" RFC 5321/5322 specs and
possibly some closely-related work are overdue for an
applicability statement that discusses what is common,
reasonable, and/or likely to work well in practice independent
of what is formally permitted, a similar document would almost
certainly be useful about assorted i18n extensions to email.
I'd think that, not only should 6530-6533 and 6855-6858 be
addressed (including whatever experience we have had that would
suggest that one or both of 6857 and 6858 should be revised or
deprecated), but that such an effort would want to make clear
statements about the relevance of PRECIS to email address
local-parts and to discuss and make recommendations about when
to use non-ASCII addresses and relevant headers and when to
stick to RFC 2231-style encoded words.  If anyone thinks it is
the right time to do the work and produce that document, and
that the IETF would have the energy and will to process it in a
timely way, I look forward to an I-D with great anticipation.

And, fwiw, I certainly agree that one could do a code review
against normative statements and miss that there are issues to