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

S Moonesamy <> Mon, 23 January 2012 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AE3B21F86C7 for <>; Mon, 23 Jan 2012 13:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.615
X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vY+aH14hsOVQ for <>; Mon, 23 Jan 2012 13:15:22 -0800 (PST)
Received: from ( [IPv6:2001:470:f329:1::1]) by (Postfix) with ESMTP id 4E53321F86BE for <>; Mon, 23 Jan 2012 13:15:22 -0800 (PST)
Received: from ([]) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id q0NLEo5a014747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 13:15:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail2010; t=1327353319;; bh=lMAR3+dVe3sMwG99F5F4Joa5ER4jKLp6ibd98RAgroI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=o6yx4tz7LGDeNqH0ODFnl6P+KePtpVEmqLcOwoOoBVFdk0EkuQuCBXVQemnMBHvM1 taIN1EhlKdy5xVjMBSRYjyE8jNYau17/5+D0OJY6+G9zEzgTkM88DbLrI35FmJtV3l IpRD/SCcYoLLmNDnif07dxWJx6VENUToKdJdkkcM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=mail; t=1327353319;; bh=lMAR3+dVe3sMwG99F5F4Joa5ER4jKLp6ibd98RAgroI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=RUjKqg/8f+v48hCQn/z2Urz/HmQL5eaMenzw1qmv95hOQlr7IU49TWAR40/Vk5CaP VybGUocx7bTceX6XcsQbzg30lUPIBAdufHojbnG9JjcY4vIuvtzZRB1rDCV5N2nR05 SWMWYbQzTAoCxbOdWVv6ymcHY5uS1+hdVDuLdAZU=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 23 Jan 2012 13:06:57 -0800
To: John Leslie <>
From: S Moonesamy <>
In-Reply-To: <20120123202634.GC36092@verdi>
References: <20120122220229.87477.qmail@joyce.lan> <20120123131953.GA36092@verdi> <> <20120123202634.GC36092@verdi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [apps-discuss] I-D Action: draft-levine-trace-header-registry-01.txt
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: Mon, 23 Jan 2012 21:15:24 -0000

Hi John,
At 12:26 23-01-2012, John Leslie wrote:
>    Making the "should" lower-case doesn't fix that problem.

See below.

>    I don't think that's necessary, though it wouldn't bother me, I think
>it helps to have the body introduce these "new" trace headers.
>    We could remove these "shoulds" just like I proposed for Section 4...


>    I don't like that text, especially the part claiming to quote, but
>    Many folks believe that a lower-case "should" is still a RFC2119
>keyword -- it's better not to open that argument.

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

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

BTW, see the discussion paragraph in Section 1.  If anyone has an 
opinion about that, please send comments.

S. Moonesamy