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

SM <> Thu, 19 January 2012 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FD7311E80D7 for <>; Wed, 18 Jan 2012 16:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.632
X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fkmVfKPHDE-T for <>; Wed, 18 Jan 2012 16:27:32 -0800 (PST)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id 78BAF21F8582 for <>; Wed, 18 Jan 2012 16:27:32 -0800 (PST)
Received: from (IDENT:sm@localhost []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q0J0RNkA021416 for <>; Wed, 18 Jan 2012 16:27:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1326932851;; bh=FqeohgF/Cyg5aFNFK16vi1xZKPlGmE4ijiih7X93OQ8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=sDylpu1GVroIvQWfYKtzrryeL4a/7WJM7tutvxW5A8001Ivrjje0P0kf1/+UeK6lI sGK+gOe5GaBxu8uVUTABiOJRAMxSdCzzie8BWDoHC/tb9bo/Zkf2EUMdygKhAeFu6M V9vqrQx3g6azxooLaN+Buulwq/F69nyhs3IV4T5I=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1326932851;; bh=FqeohgF/Cyg5aFNFK16vi1xZKPlGmE4ijiih7X93OQ8=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=wcSgdYZwOhT2Q8wX4oOjNfsHC1Um07Pq+zddlVqLblhbh3HUyn86fn2VjYVp7jXka QYCeybsUTHh9y2WRxToogoCRJJaHSeyUL3qoNCqhbM56VdKlVZYuu4Taf3S0Qf1osE Dd40R0tc9/Vd43JjFkPWYf1KOEuK+e+hXP3QZI5E=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 18 Jan 2012 16:19:58 -0800
From: SM <>
In-Reply-To: <>
References: <> <20120115200833.33736.qmail@joyce.lan> <> <3EBF175E9FCAA85080916A79@[]> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
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: Thu, 19 Jan 2012 00:27:33 -0000

Hi Murray,
At 15:20 18-01-2012, Murray S. Kucherawy wrote:
>And an interesting observation: When I wrote RFC5451, my goal was to 
>call Authentication-Results a trace field specifically because 
>preserving the order of addition of Received fields with this mixed 
>in is an important hint to figuring out where, and perhaps why, 
>message authentication work ran into problems.  So I only wanted to 
>piggyback on the "don't reorder or change this" rule that had 
>already been laid out rather than re-stating

Several other specifications have followed the piggyback path.  In my 
opinion, the question is worth discussing as it is not clear whether 
it is an acceptable practice.

>  it.  However, it also has an end-user purpose, which you correctly 
> called post-delivery MUA information.  That part isn't exactly 
> trace information per se, or maybe it is but it's actually 
> MUA-actionable.  So that header field is actually a mix of both 
> types of header field, I suppose: Agents should all follow trace 
> header field handling rules, but it actually contains actionable 
> stuff.  I'm hoping it doesn't thus deserve its own hybrid category...

It's easier to pretend not to see this part instead of trying to come 
up with a hybrid category. :-)

>I think perhaps the amalgamated draft we seem to see forming between 
>John's and SM's proposals might do well to talk about situations 
>where each approach (Additional-Registered-Clause vs. new header 
>field) is more appropriate.

I haven't discussed the approach to take with John Levine.  I don't 
have a preference at the moment.