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

John C Klensin <> Tue, 01 June 2021 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E10D3A23B5 for <>; Tue, 1 Jun 2021 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 uiIdzcp_W9Eb for <>; Tue, 1 Jun 2021 11:59:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52AF83A23B6 for <>; Tue, 1 Jun 2021 11:59:26 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1lo9bm-000DOl-A6; Tue, 01 Jun 2021 14:59:22 -0400
Date: Tue, 01 Jun 2021 14:59:16 -0400
From: John C Klensin <>
To: Ned Freed <>
cc: Viktor Dukhovni <>,
Message-ID: <8D581A6D5684C1A7EA71CA3A@PSB>
In-Reply-To: <>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <> <> <> <E23639ADA7487360C9B5A93C@PSB> <>
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, 01 Jun 2021 18:59:33 -0000


I think we are mostly in agreement, especially about the current
crop of MUA clients not being very helpful in these areas and
the users not caring about security, having a very low level of
knowledge, and not seeing either as a problem.  A few comments
below (text on which I have nothing to add elided)

--On Monday, May 31, 2021 17:54 -0700 Ned Freed
<> wrote:

> To the extent Received: fields are relevant to our customers,
> it's to track down the cause of some sort of problem, usually
> but not always some kind of delivery delay. I find A-label
> better suited to this usage than U-labels.

In case I've given any other impression, so do I.  But, like
you, I know what an A-label is, how to convert it back if
necessary, and so on.  The WG made the assumption that users
without that knowledge would be looking at that stuff.  If
today's reality, as we all seem to believe and have experienced,
is that the knowledge level and inclination to dig into these
issues of the typical user has, if anything, gone down
significantly since that assumption was made, then using
U-labels is optimizing for the very few users (percentage-wise)
who are inclined and able to dig into headers _and_ who don't
find dealing with A-labels convenient and don't know what to do
with them.

So, while I am profoundly sympathetic to a position I heard Doug
Englebart describe by an analogy to letting people drive cars
without any sort of training, it seems clear that war is over
and we lost... and, as one of many consequences, that the EAI
Wg's optimization decisions were probably wrong.

>> And that brings me close to the reasoning I think the
>> WG used more generally: that it was better to stick to "native
>> character" forms (in this case, U-labels), especially when
>> there was a possibility of a full mailbox name with a UTF-8
>> local part and a domain part containing IDN labels.   That is
>> obviously not the case for clauses of "Received:" fields
>> other than "for", but, if the WG extrapolated from that
>> principle to this particular case (and I don't remember how
>> much detailed attention the particular case got.  The other
>> argument for U-labels is that, precisely as Ned points out,
>> if an admin needs to translate an A-label, there are many
>> tools and admins are likely to know where to find them.  By
>> contrast, if a user is presented with an A-label, the
>> reaction is at least as likely to be "WT<rude word>" as "I
>> have a tool handy that does that".
> But in the bigger picture, every time you use a U-label or a
> UTF-8 local-part, you make it more difficult to deal with the
> case when you hit a point where the SMTPUTF8 extension isn't
> available.

And that turns back into a comment I made earlier -- that the WG
made a number of decisions that ultimately assumed that SMTPUTF8
would deploy rapidly, perhaps even as rapidly as 8BITMIME did.
Obviously, at least to me, had the in-transit downgrading that
the EAI WG first tried to define been workable, we'd be having
fewer, or at least different, problems at this stage.  We might
have even been able to avoid the SMTP extension and done a
Punycode-like extension for messages in transit and hence their
MTA-supplied header fields.  But we concluded that we couldn't,
and so, as far as the protocol is concerned, hitting a point in
transit where the SMTPUTF8 extension is not available means
rejecting the message with all of the problems that implies.

> We have two downgrading options defined, but neither of them
> is terribly attractive.

And both are post-delivery options, more concerned with MUAs or
POP or IMAP servers accessing the message store.

> What this argues for is to eliminate as much use of the
> extension as you possibly can. And if that means using
> A-labels, or even dropping the use of "for" clauses - which
> are optional anyhow - so be it.

In the context of the comments above, no disagreement.  That
gets us back to the original question of whether it is worth
opening the SMTPUTF8 spec family of documents to review and
change those specifications and, if so, whether there is energy
to do so.  If the answer is "no" --and that is not only my
preference but what I think I am hearing -- then I'm not sure
how useful continuing this thread actually is.

>> On the other hand, and here comes the question: There are
>> proposals floating around that would define new header fields
>> that would reflect, include, or depend on, different sorts of
>> forward-pointing and reverse-pointing addresses.  Should we be
>> taking the position that none of those should move forward
>> unless they explicitly address what should be done when those
>> fields are not traditional ASCII ones?
> Very good point. EAI is a standards-track format/protocol. An
> unavoidable consequence of this is that proposal that involves
> a new header field needs to say how it interacts with EAI,
> even if it's only to say it doesn't interact at all.

Agreed.  I hope those of us who write and review documents, the
IESG, and the ISE are paying attention.