Internet DRAFT - draft-moonesamy-mail-trace-fields
draft-moonesamy-mail-trace-fields
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]