Re: [apps-discuss] possibleTrace fields registry

Dave CROCKER <> Tue, 17 January 2012 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AA7B11E8079 for <>; Tue, 17 Jan 2012 08:48:48 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dx+UcrCWWvqr for <>; Tue, 17 Jan 2012 08:48:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B43E811E8076 for <>; Tue, 17 Jan 2012 08:48:47 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q0HGmf5r022693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Tue, 17 Jan 2012 08:48:46 -0800
Message-ID: <>
Date: Tue, 17 Jan 2012 08:48:39 -0800
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
References: <20120115201817.34086.qmail@joyce.lan>
In-Reply-To: <20120115201817.34086.qmail@joyce.lan>
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 ( []); Tue, 17 Jan 2012 08:48:47 -0800 (PST)
Subject: Re: [apps-discuss] possibleTrace fields registry
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: Tue, 17 Jan 2012 16:48:48 -0000

On 1/15/2012 12:18 PM, John Levine wrote:
>>       1.  What coordination purpose will be served by the new registry?
> Unlike other headers, trace headers can occur multiple times in a
> message, and their order means something.  This should be of use to
> code that parses headers.


      Your note and Ned's suggest to me a reasonable basis for adding a column 
to the existing message header fields registry.

      (Picky detail:  Return-path isn't supposed to appear more than one.  So 
the "multiple times" is currently limited to Received:.


This has been an interesting exercise. I had not previously noticed that RFC5321 
and RFC5322 have conflicting definitions of 'trace'.  RFC5321 equates it only to 
Received.  RFC5322 uses it to describe a class of fields.

If we are going to start doing more formal things about "trace" stuff, we are 
going to need to resolve this disparity.  In addition, I suspect some folk are 
looking to increase the number of fields counted as <trace> and we're going to 
need to consider each field carefully, since the class gets special treatment.



    More importantly, the trace header fields and resent
    header fields MUST NOT be reordered, and SHOULD be kept in blocks
    prepended to the message.  See sections 3.6.6 and 3.6.7 for more
    | Field          | Min    | Max number | Notes                      |
    | trace          | 0      | unlimited  | Block prepended - see      |
    |                |        |            | 3.6.7                      |


    trace           =   [return]

    return          =   "Return-Path:" path CRLF

    received        =   "Received:" *received-token ";" date-time CRLF


    When the SMTP server accepts a message either for relaying or for
    final delivery, it inserts a trace record (also referred to
    interchangeably as a "time stamp line" or "Received" line) at the top
    of the mail data.

    4.4.  Trace Information

    When an SMTP server receives a message for delivery or further
    processing, it MUST insert trace ("time stamp" or "Received")
    information at the beginning of the message content, as discussed in


   Dave Crocker
   Brandenburg InternetWorking