Re: [apps-discuss] Adoption of draft-kucherawy-received-state?

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E4ED21F84B3 for <>; Sat, 14 Jan 2012 17:57:55 -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 Ibg86WOJlfXY for <>; Sat, 14 Jan 2012 17:57:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AE5D821F845A for <>; Sat, 14 Jan 2012 17:57:54 -0800 (PST)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1RmFM1-0004Vv-82; Sat, 14 Jan 2012 20:57:53 -0500
Date: Sat, 14 Jan 2012 20:57:52 -0500
From: John C Klensin <>
To: John Levine <>,
Message-ID: <61D306C70A44794D8930CCB6@PST.JCK.COM>
In-Reply-To: <20120114235207.20340.qmail@joyce.lan>
References: <20120114235207.20340.qmail@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] 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 01:57:55 -0000

--On Saturday, January 14, 2012 23:52 +0000 John Levine
<> wrote:

>> Let's not turn "Received:" further into a kludge just because
>> it is there.
> I see your point, but I'm trying to weigh the relative
> uglitude of adding more clauses in Received: lines against
> adding yet more trace headers.  IANA already has a registry for
> Additional-registered-clauses at
>, 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:".   I'm suggesting that the time may have come to
add one or more rather than continuing to overload "Received:".
If we were to start adding additional ones, a registry would
certainly be in order.  Unless we do, a registry would just be
work for its own sake, at least IMO.

> On the third hand, there probably should be a registry of
> trace headers, since there's nothing I can find now beyond the
> extremely incomplete list in section 3.6.7 of RFC 5322.

See above.

And here we go down that rathole:  I hope that 5321 and 5322 are
consistent, but, if there were any respect in which they were
not, we get back to the old question of which one is
authoritative: 5321 because creating the things and putting them
in is the responsibility of the MTA or 5322 because they are,
after all, header field names.