Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state?

John C Klensin <> Sun, 15 January 2012 15:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD29A21F84A2 for <>; Sun, 15 Jan 2012 07:51:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.575
X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jT9wMnF+uwIg for <>; Sun, 15 Jan 2012 07:51:49 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B77AA21F845C for <>; Sun, 15 Jan 2012 07:51:48 -0800 (PST)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1RmSMy-000E0p-Dj; Sun, 15 Jan 2012 10:51:44 -0500
Date: Sun, 15 Jan 2012 10:51:43 -0500
From: John C Klensin <>
To: "John R. Levine" <>
Message-ID: <54978B203C73F673C5287DE3@PST.JCK.COM>
In-Reply-To: <alpine.BSF.2.00.1201142235000.1943@joyce.lan>
References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM> <alpine.BSF.2.00.1201142235000.1943@joyce.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Subject: Re: [apps-discuss] Trace headers, was Adoption of draft-kucherawy-received-state?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Jan 2012 15:51:49 -0000

--On Saturday, January 14, 2012 22:55 -0500 "John R. Levine"
<> wrote:

>>>, but as far
>>> as I can tell, there's no registry of trace headers.
>> There is no registry of trace headers because there are, and
>> have been since RFC 821, only two of them: "Received:" and
>> "Return-path:".
> If you believe what the RFCs say, there are many more trace
> headers than those two.  RFC 5322 makes a special case of
> Resent-foo: fields, but they act an awful lot like trace
> headers.  RFC 5451 says that Authentication-Results "should be
> treated as a Trace Field."  RFC 5436 says "The
> 'Auto-Submitted' header field is considered a 'trace field'".
> RFC 4408 says that "The Received-SPF header field is a trace
> field."  RFC 5518 says "VBR-Info is a 'trace header field'".
> That horse left the barn a long time ago. RFC 5537 also lists
> a bunch of trace fields for usenet, which isn't mail, but it
> might be a good idea to reserve them to avoid collisions.

This is the sort of disconnect between the specifications about
SMTP MTAs and the specifications of header fields and their
names that I mentioned in an earlier note and to which Dave
Crocker took significant exception.  While I don't want to go on
a quest for specific language, I believe that, from the MTA
point of view, part of the definition of "trace field" is that
they are inserted by MTAs, in transit.  From that point of view,
while fields like the Resent-* set are used to trace the
handling of a message (but so are Sender and maybe Message-ID),
they are MUA functions and hence not trace fields in the MTA

Some of the things you list above are probably consistent with
the MTA definition; others are probably not.

I think that distinction is worth preserving and, despite some
excessively casual language, don't think we have breached it
yet.  Then again, I think the multi-level distinction between
envelope and content information in X.400 is one of the few
important desirable distinctions between their model and ours
(in which transport tracing information is put into message
headers because we don't have a better place).  YMMD, of course.

>>  I'm suggesting that the time may have come to
>> add one or more rather than continuing to overload
>> "Received:".
> It's certainly time for a trace field registry.  And I suppose
> that if we
> have one, adding new trace fields isn't that big a deal.

I don't have any problem with such a registry.  It seems to me
that you've done most of the work of identifying what should be
in it.  Personally, I'd rather see either separate subregistries
for MTA and MUA trace info or a field that distinguishes the
former from the latter.  Do you want to generate the I-D?  I'm
happy to review and/or help as needed.