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

John C Klensin <> Fri, 13 January 2012 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B09D21F8530 for <>; Fri, 13 Jan 2012 10:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jcDQz92oRypu for <>; Fri, 13 Jan 2012 10:53:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4A92F21F850D for <>; Fri, 13 Jan 2012 10:53:41 -0800 (PST)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1RlmFw-0007oK-Cc; Fri, 13 Jan 2012 13:53:40 -0500
Date: Fri, 13 Jan 2012 13:53:39 -0500
From: John C Klensin <>
To: "Murray S. Kucherawy" <>,
Message-ID: <AD693E95D4252DC3E8F3832F@PST.JCK.COM>
In-Reply-To: <>
References: <> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar>
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: Fri, 13 Jan 2012 18:53:44 -0000

Murray and others,

You can consider this an objection to AppsAWG handling the
document in this form or one of the first comments in the
dicussion of it.

SMTP rather carefully defines "trace information" or "trace
headers" and then limits that category to two types of
information, the Received header fields and the Return-path one.
I think I know why Jon Postel did it that way, but it is pure
reconstruction: if I actually knew at the time, I've long since

In any event, we have discovered repeatedly (and sometimes
painfully) that the the Received header field is not well
designed for extensibility.   It depends on an ordered,
context-dependent, reserved keyword model (something I don't
think anyone would do today) and then switches to an Atom-String
pair model for additional clauses.  

While I have no problem at all with the type of facility the
draft proposes, I think that, if we are going to entertain this
sort of thing, we should have a serious discussion about how far
we want to go in extending "Received:" and when it is time to
add one or more additional Trace header fields, possibly with a
typology of functions that each serves (beyond "inserted by a
transit MTA or something else") and with a syntax that is
clearly name-value based, rather than even partially dependent
on parser recognition of specific keywords.

Let's not turn "Received:" further into a kludge just because it
is there.


--On Thursday, January 12, 2012 12:46 -0800 "Murray S.
Kucherawy" <> wrote:

> For evidence that there's interest in this work, or at least a
> lot of input to it, visit
> From:
> [] On Behalf Of Murray S.
> Kucherawy Sent: Wednesday, January 11, 2012 1:07 PM
> To:
> Subject: [apps-discuss] Adoption of
> draft-kucherawy-received-state?
> Can I get a show of support (or objection) to processing this
> through APPSAWG?
> Mykyta already gave a +1 to this before it was asked, but
> others have not said so explicitly.
> I'm game, of course.