Internet DRAFT - draft-levine-trace-header-registry
draft-levine-trace-header-registry
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]
