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


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


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


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


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


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


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


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


.  IANA Considerations

   This document does not require any action by IANA.


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