Re: [EAI] Rather serious bug in RFC 6531

John C Klensin <> Mon, 04 January 2021 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A35B53A0EF6 for <>; Mon, 4 Jan 2021 10:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[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 wUzh-REIH5jo for <>; Mon, 4 Jan 2021 10:26:25 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFA7B3A0EF2 for <>; Mon, 4 Jan 2021 10:26:25 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1kwUYi-000IXI-Ec; Mon, 04 Jan 2021 13:26:24 -0500
Date: Mon, 04 Jan 2021 13:26:18 -0500
From: John C Klensin <>
To: John Levine <>,
Message-ID: <F9872BDC3C6A75715CCDC997@PSB>
In-Reply-To: <20210104173248.51F3154CD6FA@ary.qy>
References: <20210104173248.51F3154CD6FA@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: [EAI] Rather serious bug in RFC 6531
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Jan 2021 18:26:28 -0000

--On Monday, January 4, 2021 12:32 -0500 John Levine
<> wrote:

> In article <>
> you write:
>> My personal opinion is that the likelyhood of older versions
>> being  implemented is low and my desire to minimize number of
>> different WITH  keywords is high, so I think the decision in
>> RFC 6531 not to change  keywords is the right one.
> Having just done some EAI compliance tests for the UASG, I can
> report that all the systems that have any EAI support at all
> do what the RFC says. The SMTP keyword is SMTPUTF8, and the
> WITH clause is UTF8SMTP. (Well, except for Microsoft whose
> WITH clauses are wrong with or without EAI.)

This is good to know, but since it would be really strange for
an implementation to ignore the spec, make its own guesses as to
what the keywords should be, and then use them, it would be
surprising if it were otherwise.  The only case we might see
would be one using the old SMTP extension keyword of UTF8SMTP,
which would indicate the experimental protocol.   Good news that
we are not seeing that and we can only hope that all
implementations sending out SMTPUTF8 are actually conforming to
the Proposed Standard protocol in area where they are different.
Our of curiosity, are/were your tests sensitive enough to tell
the difference?

As you hint, Microsoft has significant history of qualifying for
"really strange", going back at least to the implementations of
Exchange Server in the early 1990s whose version of SMTP used an
X.400 design and terminology.

> At this point I am not aware of any live implmentations of the
> experimental version other than in IMAP at Coremail, and that
> one is sufficiently broken  that I doubt anyone is using it.
> I agree we should leave it alone.

I think it is important that we discuss this and make an
explicit decision.  The big argument for making a change is that
people (notably yourself included) get confused as refer to the
SMTP extension and associated changes as "UTF8SMTP".  That is
much better than referring to them as "EAI", but having three
terminology options where we should have one is unhealthy and
confusing to those who are not insiders and even some of us.  On
the other hand, if the specified WITH keywords are widely
deployed (as they seem to be) and we don't expect to see a
significant number of new implementation in the near or mid-term
future (I haven't noticed a significant rate of growth recently,
but maybe others have), inflicting a change on everyone as the
result of a mistake we didn't catch a decade ago does not seem
wise or appropriate.