idnits 2.17.1 draft-moonesamy-mail-trace-fields-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 18, 2012) is 4454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC822' is mentioned on line 76, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'RFC4408' is mentioned on line 117, but not defined ** Obsolete undefined reference: RFC 4408 (Obsoleted by RFC 7208) == Unused Reference: 'RFC0822' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'RFC5321' is defined on line 199, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission S. Moonesamy 3 Internet-Draft January 18, 2012 4 Intended status: Informational 5 Expires: July 21, 2012 7 Trace Fields in mail-related specifications 8 draft-moonesamy-mail-trace-fields-00 10 Abstract 12 The memo provides background information about trace fields in mail 13 standards. It discusses about the use of trace fields in mail- 14 related specifications. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 21, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Note . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Trace fields in mail-related specifications . . . . . . . . . . 3 65 3. Trace field property . . . . . . . . . . . . . . . . . . . . . 4 66 4. Trace information . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Trace field implementation . . . . . . . . . . . . . . . . . . 4 68 6. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 9. Informative References . . . . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Background 76 RFC 822 [RFC822] defined Trace fields as fields providing trace 77 information and which are used to provide an audit trail of message 78 handling. Two header fields were defined as trace fields; the 79 "Received" header field and the "Return-Path" header field. RFC 2822 80 [RFC2822] defined trace fields as a group of header fields consisting 81 of an optional "Return-Path" header field, and one or more 82 "Received:" fields. Restrictions on the syntax of trace fields and 83 the usage were provided in RFC 2821 [RFC2821]. 85 RFC 2821 [RFC2821] defined trace information in terms of the 86 information that must be supplied. It also specifies that SMTP 87 servers must prepend "Received" header fields and that the order of 88 exiting "Received" header fields must not be changed. The "Return- 89 Path" header field is specified as being inserted at the top of 90 header fields at the time of final delivery. 92 RFC 5322 [RFC5322] uses the same definition as in the previous 93 paragraph and refers to RFC 5321 [RFC5322] for any formal 94 interpretation. 96 1.1. Note 98 This Internet-Draft can be discussed on the apps-discuss@ietf.org 99 mailing list. [RFC-Editor: please remove this paragraph] 101 2. Trace fields in mail-related specifications 103 RFC 4408 [RFC4408] defines the "Received-SPF" header field as a trace 104 field and specifies that it must appear above all other "Received- 105 SPF" header fields. 107 RFC 4871 [RFC4871] specifies that the "DKIM-Signature" header field 108 should be treated as a trace field and that it should not be 109 reordered. It mentions that the header field should be prepended to 110 the message. DomainKeys Identified Mail (DKIM) [RFC4871] relies on 111 maintaining the ordering of header fields as a change of any "DKIM 112 signed" header field can invalidate the DKIM signature. 114 RFC 5451 [RFC5451] defines an "Authentication-Results" header field. 115 It mentions that the field should be treated as a Trace field to get 116 an idea of how far away authentication checks, such as DKIM and 117 Sender Policy Framework [RFC4408] were done. 119 RFC 5518 [RFC5518] defines a "VBR-Info" header field and mentions 120 that a message may contain multiple occurences of these header 121 fields. The document relies on the terminology in RFC 5322 [RFC5322] 122 to say that the "VBR-Info" header field is a "trace header field". 123 It also specifies that the header fields should be added at the top 124 of the header fields. 126 3. Trace field property 128 The desired property of a Trace field is that any header field 129 defined as a Trace field should not be reordered within a message 130 header block or changed. In addition, a new Trace field should be 131 added to the top of the message header block. This makes it possible 132 to infer, for example, which header field was added last. 134 There can be zero or more occurences of a Trace field in a message 135 header block. 137 4. Trace information 139 "Received" header fields are a useful aid in detecting problems such 140 as slow relays. They can also be used to determine the path a 141 message took from mail submission to final delivery. "Received" 142 header fields are sometimes referred to as "time stamp lines" as they 143 contain a date and time. 145 The "Return-Path" header field is a special case; it is used to 146 preserve the reverse-path address as the message leaves the SMTP 147 environment. 149 5. Trace field implementation 151 Over the years, the practice has been to add header fields which do 152 not provide trace information to the bottom of the message header 153 block. The implementation of RFC 4871, RFC 5451 and RFC 5518 was 154 possible without changes to SMTP implementations as there was an API 155 to interface with some implementations. 157 6. Issues 159 a. The recommendation that trace header fields should be kept in 160 blocks is not always followed. Implementations add any new 161 header field at the top of the message block without determining 162 whether it is a trace header field. 164 b. Messages can be forwarded by users. Adding trace information as 165 part of the body of the forwarded message ends up confusing 166 users. The trace information is generally not relevant except 167 for debugging mail delivery issues. 169 c. Should Trace fields be identified in the Permanent Message Header 170 Field Names Registry? Currently, there are 111 entries for the 171 mail protocol. 173 7. Security Considerations 175 Some people view the disclosure of trace information as a security 176 risk as it may contain information about internal mail servers. 177 There are misguided attempts to strip "Received" header fields to 178 hide information. 180 8. IANA Considerations 182 This document does not require any action by IANA. 184 9. Informative References 186 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 187 text messages", STD 11, RFC 822, August 1982. 189 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 190 April 2001. 192 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 193 April 2001. 195 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 196 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 197 Signatures", RFC 4871, May 2007. 199 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 200 October 2008. 202 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 203 October 2008. 205 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 206 Message Authentication Status", RFC 5451, April 2009. 208 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 209 Reference", RFC 5518, April 2009. 211 Author's Address 213 S. Moonesamy 214 76, Ylang Ylang Avenue 215 Quatre Bornes 216 Mauritius 218 Email: sm+ietf@elandsys.com