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
attractive.
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
all.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp