Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt

John Leslie <john@jlc.net> Fri, 27 January 2012 15:10 UTC

Return-Path: <john@jlc.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07DD21F85EE for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 07:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.277
X-Spam-Level:
X-Spam-Status: No, score=-106.277 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQI2hE2pMa4G for <apps-discuss@ietfa.amsl.com>; Fri, 27 Jan 2012 07:10:44 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2121F85ED for <apps-discuss@ietf.org>; Fri, 27 Jan 2012 07:10:42 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 5974833C28; Fri, 27 Jan 2012 10:10:27 -0500 (EST)
Date: Fri, 27 Jan 2012 10:10:27 -0500
From: John Leslie <john@jlc.net>
To: S Moonesamy <sm+ietf@elandsys.com>
Message-ID: <20120127151027.GA86451@verdi>
References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> <6.2.5.6.2.20120123061715.09faec70@resistor.net> <20120123202634.GC36092@verdi> <6.2.5.6.2.20120123123554.0a88aca8@elandnews.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20120123123554.0a88aca8@elandnews.com>
User-Agent: Mutt/1.4.1i
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 15:10:49 -0000

S Moonesamy <sm+ietf@elandsys.com> wrote:
> 
> Suggested text for Section 3.2:
> 
>   This informative section is to delineate the history of thinking about
>   Trace fields in mail-related specifications.
> 
>   [RFC4408] defines the "Received-SPF:" header field as a Trace field
>   and specifies that it is added above all other "Received-SPF:"
>   header fields.
> 
>   [RFC6376] specifies that the "DKIM-Signature:" header field is
>   treated as a Trace field and that it is not be reordered.  It
>   mentions that the header field is prepended to the message.
>   DomainKeys Identified Mail (DKIM) relies on maintaining the ordering
>   of header fields as a change of any "DKIM signed" header field can
>   invalidate the DKIM signature.
> 
>   [RFC5451] defines an "Authentication-Results:" header field.  It
>   mentions that the field is to be treated as a Trace field to get an
>   idea of how far away authentication checks, such as DKIM and Sender
>   Policy Framework [RFC4408] were done.
> 
>   [RFC5518] defines a "VBR-Info:" header field and mentions that a
>   message can contain multiple occurrences of these header fields.  The
>   document relies on the terminology in [RFC5322] to say that the "VBR-
>   Info:" header field is a "trace header field".  It also specifies
>   that the header fields is be added at the top of the header
>   fields.
> 
>   [RFC5436] defines an "Auto-Submitted:" header to be added to
>   notification messages generated by Sieve filtering rules.  Section
>   2.7.1 says "The "Auto-Submitted:" header field is considered a Trace
>   field, similar to "Received:" header fields (see [RFC5321])."
> 
> For Section 4:
> 
>   The recommendation that trace header fields is to be kept in
>   blocks is not always followed.  Some implementations add any new
>   header field at the top of the message block without determining
>   whether it is a Trace field.

   Works for me.

--
John Leslie <john@jlc.net>