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

John C Klensin <> Tue, 25 May 2021 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 719723A0BD7 for <>; Mon, 24 May 2021 19:32:11 -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 wiyIAXVgGH4q for <>; Mon, 24 May 2021 19:32:07 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0DB2C3A0AB6 for <>; Mon, 24 May 2021 19:32:06 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1llMrV-000LL9-HF; Mon, 24 May 2021 22:32:05 -0400
Date: Mon, 24 May 2021 22:31:59 -0400
From: John C Klensin <>
To: "John R. Levine" <>
Message-ID: <4ED5FF03CF3B91767AD87B8A@PSB>
In-Reply-To: <>
References: <>
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 02:32:12 -0000

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.   If that were true and
things had gone as quickly as the advocates predicted, then your
argument would not hold because the odds of the downstream
system in the scenario you describe not having support for the
extension would be low. If we are merely being slower than
expected getting there, then advising people to do something
that is sub-optimal for other reasons is a bad idea because it
is likely to just slow things down further.

Now, if, on the other hand, the reality were that no one is
going to fully implement SMTPUTF8 other than mail providers in a
few countries that intend to use it internally, then we should
probably be reconsidering the whole model --not just this
detail-- lest we end up with two mail systems and needing
gateways, possibly even gateways with serious downgrade and/or
encapsulation facilities between them.

   Just my personal opinion, of course.

--On Monday, May 24, 2021 19:05 -0400 "John R. Levine"
<> wrote:

> I've been doing some EAI tests.  RFC 6531 section 3.7.3 says
> that domain names in trace headers SHOULD all be U-labels.  In
> practice, everyone uses A-labels for reasons that are not
> absurd.  The FROM clause has the name from the EHLO command
> which has to be sent as A-labels, and it's quite plausible to
> have a message where the message itself is entirely ASCII,
> sent to a UTF-8 address, which then could be forwarded to an
> ASCII address except that it has those U-labels in the trace
> header which would have to be downgraded.  I've talked to a
> couple of MTA maintainers who have told me forget it, that's
> silly, not doing that.
> In a situation like this, would it make sense in a future
> update to the RFC to adjust the advice to the reality?