On Tue 01/Jun/2021 02:54:32 +0200 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.
Nowadays, Received: fields are often intermixed with Authentication-Results:,
especially near the top of the header. The latter provides U-Labels, AFAICS.
That way, both kinds of labels are available. Here's a couple of examples:
By Courier-MTA:
Return-Path: <postmaster(_at_)xn--fo-kia(_dot_)it>
Authentication-Results: wmail.tana.it;
spf=pass smtp.mailfrom=foà.it;
dkim=pass (whitelisted) header.d=foà.it
Received: from xn--fo-kia.it (wmail.tana.it [62.94.243.226])
by wmail.tana.it with ESMTP
id 00000000005DC026.0000000060B66AC3.00007C42; Tue, 01 Jun 2021 19:13:02 +0200
By Google:
Authentication-Results: mx.google.com;
dkim=pass header.i=@foà.it header.s=gamma header.b=BHORghd0;
spf=pass (google.com: domain of postmaster@foà.it designates 62.94.243.226 as
permitted sender) smtp.mailfrom=postmaster@foà.it;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=xn--fo-kia.it
Still, Section 3.7.3 of RFC 6531 doesn't seem to say that A-R's are trace
fields...
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.
If not specified, it looks like Section 3.6 of RFC 6532 supplies a default:
encoded-words SHOULD NOT be used when generating header fields for
messages employing this extension. Agents MAY, when incorporating
material from another message, convert encoded-word use to direct use
of UTF-8.
Best
Ale
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp