Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?

John C Klensin <> Tue, 25 May 2021 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F11AC3A1AA5 for <>; Tue, 25 May 2021 12:34:25 -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 AE34ehU3AxqI for <>; Tue, 25 May 2021 12:34:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 399603A1AA0 for <>; Tue, 25 May 2021 12:34:21 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1llcol-00011o-Pm; Tue, 25 May 2021 15:34:19 -0400
Date: Tue, 25 May 2021 15:34:13 -0400
From: John C Klensin <>
To: John Levine <>,
Message-ID: <EFDA46E00EFF0E48802D046A@PSB>
In-Reply-To: <20210525182946.079748B872C@ary.qy>
References: <20210525182946.079748B872C@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] Should we update an RFC if people refuse to implement parts of it ?
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, 25 May 2021 19:34:26 -0000

--On Tuesday, May 25, 2021 14:29 -0400 John Levine
<> wrote:

> It appears that John C Klensin  <> said:
>> It would certainly be appropriate to either revise the spec
>> or, better from my point of view, create a short applicability
>> statement that explains the reasoning behind the SHOULD and
>> the circumstances under which it would be sensible to ignore
>> it. ...
>> The thing that sometimes gets lost in "let's make the spec
>> conform to what implementations are doing" discussions in this
>> area is that there is an assumption behind the whole
>> collection of SMTPUTF8 specs, namely that the world really
>> wanted non-ASCII addressing and header field values. ...
> This may seem like splitting hairs but there is a difference
> between header fields that users see and fields that they
> don't.  Message-IDs are still generally ASCII in EAI messages,
> and I don't see any benefit from making the domain names in
> trace headers U-labels rather than A-labels.
> I'm not getting any pushback on Return-Path which really does
> need to be UTF-8 is it's an EAI address.  I think the few MTAs
> that put a FOR clause in the Received header put EAI addresses
> there, too.

I recognize the distinction while also realizing that, as you
know, things often leak.  My recollection (if Jiankang is
following this, his memory is probably better than mine) is that
the WG explicitly discussed the issue and concluded that
U-labels were a better idea than A-labels.  

One way or the other, let me split a different hair.  As I read
RFC 6531, all the penultimate paragraph of Section 3.7.3 says is
that the "server SHOULD use the U-label form".   It does not
discuss circumstances under which it is reasonable for an
implementation to do otherwise.  If the implementations you are
talking about have rational reasons for doing otherwise, then
they are still conforming, even if not exhibiting preferred
behavior.   Does that mean the spec should be revised?  I don't
think so unless (1) we feel a need to be explicit about when it
is ok to do something different than the SHOULD specifies, (2)
we gave decided it is not the preferred behavior after all, or
(3) we have concluded that the assumption that substantially all
MTAs will migrate to SMTPUTF8 support is incorrect.  

So, barring the third option above and given that U-labels and
A-labels are reversibly convertible without information loss, I
just do not see a big deal 
here, certainly not one that would justify reopening the