Network Working Group J.R. Levine Internet-Draft Taughannock Networks Updates: 5322, 3864 January 2012 Intended status: Standards Track Expires: July 14, 2012 A Registry for Mail Trace Fields draft-levine-trace-header-registry-00 Abstract SMTP mail software adds trace header fields to messages as they pass through the mail system. This document updates the definition of trace header fields, and adds trace field information to the registries for Permanent Message Header Fields and Provisional Message Header Fields. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 14, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Levine std [Page 1] Internet-Draft Trace Field Registry January 2012 Sections 3.6.6 and 3.6.7 of [RFC5322] define Resent Fields and Trace Fields, respectively. These are header fields that are prepended to the message as it moves through the SMTP mail infrastructure. Although [RFC5322] defines only two fields, Return-Path: and Received: as Trace Fields, in practice there are many other header fields that act as trace fields. This document updates the definition of trace fields, and adds a new column to the IANA registries of header fields to document which ones are trace fields. In some documents, Trace Fields are referred to as Trace Header Fields. The two terms are synonyms. This document uses the shorter term Trace Fields. 2. Definitions This section defines various terms used throughout this document. 2.1. General The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Email Specific [RFC5598] introduces several terms and concepts that are used in this memo, and thus readers are advised to become familiar with it as well. Specifically, this document uses the terms Mail Transfer Agent (MTA), Mail User Agent (MUA), Mail Delivery Agent (MDA), and Mail Submission Agent (MSA). 3. Trace Fields The definition of Trace Fields in RFC 5322 is updated to include all of the header fields identified as Trace Fields in the IANA Permanent Message Header Fields and Provisional Message Header Fields registries. The initial set of Trace Fields for those registries is listed in [ianainit]. 3.1. Usage of Trace Fields Whenever a component adds a Trace Field to a message, it MUST add the field at the top of the message. Components MAY delete existing Trace Fields, but they MUST NOT reorder them. Unlike most other header fields, it is usually not an error to have multiple occurrences of the same Trace Field. Of the fields described in this document, all but Return-Path: can occur multiple times. Trace Fields are intended to document the progress of a message through the e-mail system. The sequence of Trace Fields at the top of the message describes that progress in reverse chronological order. 4. IANA Considerations Levine std [Page 2] Internet-Draft Trace Field Registry January 2012 IANA is requested to update the Permanent Message Header Fields and Provisional Message Header Fields registries, defined in [RFC3864] to include a new column called Trace Field. For each Header Field, this column may be blank, in which case the header field is not a Trace Field, or any of the tokens MTA, MUA, MSA, or MDA, to indicate that the header field is a Trace Field, and what component typically adds the header to a message. Note that the distinction among non-blank tokens is not normative, and a trace field MAY be added by any component that handles a message. The registration templates described in sections 4.2.1 and 4.2.2 of [RFC3864] are each updated to add a new section: Trace Field: Specify: blank, "MTA", "MUA", "MSA", or "MDA". If this field is not an e-mail Trace Field, this section is left blank. If it is a Trace Field, the component that typically adds the field. 4.1. Initial set of Trace Fields In the table below, the first column describes an existing Header Field, and the second column is the value to put in its Trace Field. The third column is for documentation, and is intended to match the existing contents of the Reference column in the registries. For all headers not in this list, the initial value of the Trace Field is blank. +-------------------------+-------------+-----------+ | Header Field Name | Trace Field | Reference | +-------------------------+-------------+-----------+ | Authentication-Results: | MTA | [RFC5451] | | Auto-Submitted: | MSA | [RFC5436] | | DKIM-Signature: | MSA | [RFC6376] | | Received: | MTA | [RFC5322] | | Received-SPF: | MTA | [RFC4408] | | Resent-Date: | MUA | [RFC5322] | | Resent-From: | MUA | [RFC5322] | | Resent-Sender: | MUA | [RFC5322] | | Resent-To: | MUA | [RFC5322] | | Resent-Cc: | MUA | [RFC5322] | | Resent-Bcc: | MUA | [RFC5322] | | Resent-Message-ID: | MUA | [RFC5322] | | Return-Path: | MDA | [RFC5322] | | VBR-Info: | MSA | [RFC5518] | +-------------------------+-------------+-----------+ Note: The Permanent Message Header Field Names registry currently lists [RFC3834] as the reference for the Auto-Submitted: field, but there is a later and more detailed description of it in [RFC5436] that describes it as a trace field. 5. References 5.1. Normative References Levine std [Page 3] Internet-Draft Trace Field Registry January 2012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3864] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. 5.2. Informative References [RFC3834] Moore, K., "Recommendations for Automatic Responses to Electronic Mail", RFC 3834, August 2004. [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RFC5436] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: mailto", RFC 5436, January 2009. [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [RFC5518] Hoffman, P., Levine, J. and A. Hathcock, "Vouch By Reference", RFC 5518, April 2009. [RFC6376] Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. Author's Address John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 Phone: +1 831 480 2300 Email: standards@taugh.com Levine std [Page 4]