[Top] [All Lists]

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

2021-06-01 12:32:48
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>
  spf=pass smtp.mailfrom=foà.it;
  dkim=pass (whitelisted) header.d=foà.it
Received: from ( [])
  by with ESMTP
  id 00000000005DC026.0000000060B66AC3.00007C42; Tue, 01 Jun 2021 19:13:02 +0200

By Google:

       dkim=pass header.i=@foà.it header.s=gamma header.b=BHORghd0;
       spf=pass ( domain of postmaster@foà.it designates as 
permitted sender) smtp.mailfrom=postmaster@foà.it;
       dmarc=pass (p=NONE sp=NONE dis=NONE)

Still, Section 3.7.3 of RFC 6531 doesn't seem to say that A-R's are trace 

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

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.


ietf-smtp mailing list