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
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
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
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.
ietf-smtp mailing list