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

Ned Freed <> Tue, 01 June 2021 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 555ED3A1CDD for <>; Tue, 1 Jun 2021 08:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jnGe0T4ezpjj for <>; Tue, 1 Jun 2021 08:51:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BD293A1CDA for <>; Tue, 1 Jun 2021 08:51:16 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Tue, 1 Jun 2021 08:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=201712; t=1622562371; bh=lGCOAm/BY1YD7RFhHPO64tda6DY3A+Xn0Tfwt5xoo/k=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=bHuOutCIPGBYewZ9zJbVHjhFI+9ufFFGsANQV/vXFoIF9D8Y4kcHT0ZuMLJMzWqMG 0sl8nAiEbSXi4eYeMKVYDHAYfb0Y5JQdizz6kZl0p+YYm/3dnjD3JswJrFlwm06AFF FFscSga+90xWuqMTdvPChKp5g/Aw+gxYenRReuOY=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <>; Tue, 1 Jun 2021 08:46:08 -0700 (PDT)
Cc: Ned Freed <>, Viktor Dukhovni <>,
Message-id: <>
Date: Mon, 31 May 2021 17:54:32 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Sun, 30 May 2021 21:19:09 -0400" <E23639ADA7487360C9B5A93C@PSB>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <> <> <> <E23639ADA7487360C9B5A93C@PSB>
To: John C Klensin <>
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 15:51:21 -0000

> >> But, and this is crucial, the human reading the trace
> >> information is rarely either the sender or the ultimate
> >> recipient of the message, who are generally presented with a
> >> subset of the headers fields ("To", "Cc", "Date", "Subject"
> >> ...).  Examination of trace headers is far more likely to a
> >> task for a mail system administrator.  They're used in abuse
> >> reports and the like, and a uniform representation is more
> >> important than familiarity to the community of readers of
> >> some given language.
> >
> > And what the admin usually wants to do is either a comparison
> > or check the domain with the DNS in some way. So an A-label
> > can be more convenient.
> >
> > And in the unlikely event an admin needs to translate the
> > A-label to a U-label, there are an abundance of tools that I
> > can use to do it.

> I may live in a different world, or at least with different
> users, than the two of you, but I quite often see users pointed
> to trace fields in order to make estimates of the validity of a
> message.

If we're talking about end users... Between the lack of user interest in
security, lack of expertise, and client authors making it increasingly difficult
to even access trace fields, it's been a very long time since I've done this.

Even if we're talking about our customers, there's really no interest in
performing these sorts of estimates any more.

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.

> 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.

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

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.

> A different piece of the same story is that, if I had much more
> confidence that authors of MUAs and other mail access tools
> would think carefully about these subtle issues and get them
> right, I'd say that, given the dual relationship between
> A-labels and U-labels, it makes no difference which of the two
> are used on the wire -- it is all a presentation issue.  On the
> other hand, my experience of the last decade or so has given me
> no such confidence.

AFAIK MUAs haven't gotten into the business of trace field analysis. In fact
even the automated tools for this I've seen do little more than prettprint
header content. So I don't think this is particularly relevant.

> ...

> 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