Network Working Group J.R. Levine Internet-Draft Taughannock Networks Updates: 3864, 5322 S. Moonesamy Intended status: Standards Track January 2012 Expires: July 14, 2012 Mail Header Trace Fields draft-levine-trace-header-registry-01 Abstract SMTP mail software adds trace fields to messages as they pass through the mail system. This memo provides background information about trace fields in mail standards. It discusses the use of trace fields in mail-related specifications. It updates the definition of trace header fields, and adds trace field information to the relevant registries. 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 & Moonesamy std [Page 1]
Internet-Draft Mail Trace Fields January 2012 [RFC0822] defined Trace fields as fields providing trace information and which are used to provide an audit trail of message handling. Two header fields were defined as Trace fields; the "Received:" header field and the "Return-Path:" header field. [RFC2822] in Section 3.6.6 defined Trace fields as a group of header fields consisting of an optional "Return-Path:" header field, and one or more "Received:" fields. Restrictions on the syntax of Trace fields and the usage were provided in [RFC2821]. [RFC5322] uses the same definition as in the previous paragraph and refers to [RFC5321] for any formal interpretation. Although [RFC5322] defines only two Trace fields, in practice there are many other header fields that act as Trace fields. Section 3.6.7 of [RFC5322] defined Resent Fields, which are also prepended to the message in the same fashion as Trace fields. This document updates the definition of Trace fields in [RFC5322], and adds a new column to the IANA registries of header fields to document which ones are Trace fields. DISCUSSION: [RFC3864] created a permanent message header fields registry and a provisional message header fields registry. The applicable protocol in the IANA registries is either "mail", "mime", "http" or "netnews". A sub-registry for the "mail" protocol could be used instead of the message header fields registries. 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. 1.1. Note This Internet-Draft can be discussed on the apps-discuss@ietf.org mailing list. [RFC-Editor: please remove this paragraph] 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 Levine & Moonesamy std [Page 2]
Internet-Draft Mail Trace Fields January 2012 The definition of Trace Fields in [RFC5322] 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 The desired property of a Trace field is that any header field defined as a Trace field SHOULD NOT be reordered within a message header block or changed. In addition, a new Trace field SHOULD be added to the top of the message header block. This makes it possible to infer the history of the message from the sequence of header fields. There can be zero or more occurences of a Trace field in a message header block. Further restrictions may be defined for Trace fields by the specifications that provide for their use. 3.2. Trace fields in mail-related specifications [RFC4408] defines the "Received-SPF:" header field as a Trace field and specifies that it must appear above all other "Received-SPF:" header fields. [RFC6376] specifies that the "DKIM-Signature:" header field should be treated as a Trace field and that it should not be reordered. It mentions that the header field should be 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 should 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 may contain multiple occurences 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 should 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])." 4. Issues a. The recommendation that trace header fields should 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. Levine & Moonesamy std [Page 3]
Internet-Draft Mail Trace Fields January 2012 b. Messages can be forwarded by users. Adding Trace fields as part of the body of the forwarded message ends up confusing users. Some Trace fields are generally not relevant except for debugging mail delivery issues. 5. IANA Considerations 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 which component typically adds the header to a message. 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. 5.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] | +-------------------------+-------------+-----------+ Levine & Moonesamy std [Page 4]
Internet-Draft Mail Trace Fields January 2012 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. 6. Security Considerations Some people view the disclosure of trace fields such as the "Received:" header field as a security risk as it may contain information about internal mail servers. This lead to misguided attempts to strip "Received:" header fields to hide information. Trace fields are not guaranteed to be in a particular order; they have been known to be reordered occasionally when transported over the Internet. 7. References 7.1. Normative References [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. 7.2. Informative References [RFC0822] Crocker, D.H., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [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. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. Levine & Moonesamy std [Page 5]
Internet-Draft Mail Trace Fields January 2012 [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. Authors' Addresses John Levine Taughannock Networks PO Box 727 Trumansburg, NY 14886 Phone: +1 831 480 2300 Email: standards@taugh.com S. Moonesamy 76, Ylang Ylang Avenue Quatre Bornes, Mauritius Email: sm+ietf@elandsys.com Levine & Moonesamy std [Page 6]