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

Dave CROCKER <> Sun, 15 January 2012 03:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8922B21F84AF for <>; Sat, 14 Jan 2012 19:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ORnFaGL77iPW for <>; Sat, 14 Jan 2012 19:03:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C89F921F84B2 for <>; Sat, 14 Jan 2012 19:03:40 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q0F33WDP001928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2012 19:03:37 -0800
Message-ID: <>
Date: Sat, 14 Jan 2012 19:03:17 -0800
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: John C Klensin <>
References: <20120114235207.20340.qmail@joyce.lan> <61D306C70A44794D8930CCB6@PST.JCK.COM>
In-Reply-To: <61D306C70A44794D8930CCB6@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sat, 14 Jan 2012 19:03:37 -0800 (PST)
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 03:03:41 -0000

On 1/14/2012 5:57 PM, John C Klensin wrote:
>  I'm suggesting that the time may have come to
> add one or more rather than continuing to overload "Received:".

"continuing to"?  please explain the history of overloading that has taken 
place; I'm not aware of it.

Please then explain how the current proposal exceeds a reasonable enhancement of 
the Received field.  "received" refers to transitions.  The enhancement merely 
documents more transitions.

Please also note that creating a separate kind of header field, such as for 
transitions /within/ a host, will then require correlating the /within/ fields 
and the /between/ (Received:) fields.  If you think there is anything about the 
current situation that is a kluge, you ain't seen nothing' yet.

> 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.

What is it that will cause us to go down that rathole?  There's nothing in the 
current proposal that creates the potential for loss of synchrony between 5321 
and 5322.  So how is your concern relevant here?



   Dave Crocker
   Brandenburg InternetWorking