Individual Submission S. Moonesamy Internet-Draft January 18, 2012 Intended status: Informational Expires: July 21, 2012 Trace Fields in mail-related specifications draft-moonesamy-mail-trace-fields-00 Abstract The memo provides background information about trace fields in mail standards. It discusses about the use of trace fields in mail- related specifications. 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 21, 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. This document may contain material from IETF Documents or IETF Moonesamy Expires July 21, 2012 [Page 1] Internet-Draft Mail Trace Fields January 2012 Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Trace fields in mail-related specifications . . . . . . . . . . 3 3. Trace field property . . . . . . . . . . . . . . . . . . . . . 4 4. Trace information . . . . . . . . . . . . . . . . . . . . . . . 4 5. Trace field implementation . . . . . . . . . . . . . . . . . . 4 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 9. Informative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Moonesamy Expires July 21, 2012 [Page 2] Internet-Draft Mail Trace Fields January 2012 1. Background RFC 822 [RFC822] 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. RFC 2822 [RFC2822] 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 RFC 2821 [RFC2821]. RFC 2821 [RFC2821] defined trace information in terms of the information that must be supplied. It also specifies that SMTP servers must prepend "Received" header fields and that the order of exiting "Received" header fields must not be changed. The "Return- Path" header field is specified as being inserted at the top of header fields at the time of final delivery. RFC 5322 [RFC5322] uses the same definition as in the previous paragraph and refers to RFC 5321 [RFC5322] for any formal interpretation. 1.1. Note This Internet-Draft can be discussed on the apps-discuss@ietf.org mailing list. [RFC-Editor: please remove this paragraph] 2. Trace fields in mail-related specifications RFC 4408 [RFC4408] defines the "Received-SPF" header field as a trace field and specifies that it must appear above all other "Received- SPF" header fields. RFC 4871 [RFC4871] 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) [RFC4871] relies on maintaining the ordering of header fields as a change of any "DKIM signed" header field can invalidate the DKIM signature. RFC 5451 [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. RFC 5518 [RFC5518] defines a "VBR-Info" header field and mentions that a message may contain multiple occurences of these header Moonesamy Expires July 21, 2012 [Page 3] Internet-Draft Mail Trace Fields January 2012 fields. The document relies on the terminology in RFC 5322 [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. 3. Trace field property 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, for example, which header field was added last. There can be zero or more occurences of a Trace field in a message header block. 4. Trace information "Received" header fields are a useful aid in detecting problems such as slow relays. They can also be used to determine the path a message took from mail submission to final delivery. "Received" header fields are sometimes referred to as "time stamp lines" as they contain a date and time. The "Return-Path" header field is a special case; it is used to preserve the reverse-path address as the message leaves the SMTP environment. 5. Trace field implementation Over the years, the practice has been to add header fields which do not provide trace information to the bottom of the message header block. The implementation of RFC 4871, RFC 5451 and RFC 5518 was possible without changes to SMTP implementations as there was an API to interface with some implementations. 6. Issues a. The recommendation that trace header fields should be kept in blocks is not always followed. Implementations add any new header field at the top of the message block without determining whether it is a trace header field. Moonesamy Expires July 21, 2012 [Page 4] Internet-Draft Mail Trace Fields January 2012 b. Messages can be forwarded by users. Adding trace information as part of the body of the forwarded message ends up confusing users. The trace information is generally not relevant except for debugging mail delivery issues. c. Should Trace fields be identified in the Permanent Message Header Field Names Registry? Currently, there are 111 entries for the mail protocol. 7. Security Considerations Some people view the disclosure of trace information as a security risk as it may contain information about internal mail servers. There are misguided attempts to strip "Received" header fields to hide information. 8. IANA Considerations This document does not require any action by IANA. 9. Informative References [RFC0822] Crocker, D., "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. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [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 Moonesamy Expires July 21, 2012 [Page 5] Internet-Draft Mail Trace Fields January 2012 Reference", RFC 5518, April 2009. Author's Address S. Moonesamy 76, Ylang Ylang Avenue Quatre Bornes Mauritius Email: sm+ietf@elandsys.com Moonesamy Expires July 21, 2012 [Page 6]