idnits 2.17.1 draft-levine-trace-header-registry-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3864, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5322, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3864, updated by this document, for RFC5378 checks: 2001-09-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2012) is 4483 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5598 -- 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 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.R. Levine 3 Internet-Draft Taughannock Networks 4 Updates: 3864, 5322 S. Moonesamy 5 Intended status: Standards Track January 2012 6 Expires: July 14, 2012 8 Mail Header Trace Fields 9 draft-levine-trace-header-registry-01 11 Abstract 13 SMTP mail software adds trace fields to messages as they pass through 14 the mail system. This memo provides background information about 15 trace fields in mail standards. It discusses the use of trace fields 16 in mail-related specifications. It updates the definition of trace 17 header fields, and adds trace field information to the relevant 18 registries. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 14, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 1. Introduction 53 [RFC0822] defined Trace fields as fields providing trace information 54 and which are used to provide an audit trail of message handling. 55 Two header fields were defined as Trace fields; the "Received:" 56 header field and the "Return-Path:" header field. [RFC2822] in 57 Section 3.6.6 defined Trace fields as a group of header fields 58 consisting of an optional "Return-Path:" header field, and one or 59 more "Received:" fields. Restrictions on the syntax of Trace fields 60 and the usage were provided in [RFC2821]. 62 [RFC5322] uses the same definition as in the previous paragraph and 63 refers to [RFC5321] for any formal interpretation. Although 64 [RFC5322] defines only two Trace fields, in practice there are many 65 other header fields that act as Trace fields. Section 3.6.7 of 66 [RFC5322] defined Resent Fields, which are also prepended to the 67 message in the same fashion as Trace fields. 69 This document updates the definition of Trace fields in [RFC5322], 70 and adds a new column to the IANA registries of header fields to 71 document which ones are Trace fields. 73 DISCUSSION: [RFC3864] created a permanent message header fields 74 registry and a provisional message header fields registry. The 75 applicable protocol in the IANA registries is either "mail", "mime", 76 "http" or "netnews". A sub-registry for the "mail" protocol could be 77 used instead of the message header fields registries. 79 In some documents, Trace Fields are referred to as Trace Header 80 Fields. The two terms are synonyms. This document uses the shorter 81 term Trace Fields. 83 1.1. Note 85 This Internet-Draft can be discussed on the apps-discuss@ietf.org 86 mailing list. [RFC-Editor: please remove this paragraph] 88 2. Definitions 90 This section defines various terms used throughout this document. 92 2.1. General 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2.2. Email Specific 100 [RFC5598] introduces several terms and concepts that are used in this 101 memo, and thus readers are advised to become familiar with it as 102 well. Specifically, this document uses the terms Mail Transfer Agent 103 (MTA), Mail User Agent (MUA), Mail Delivery Agent (MDA), and Mail 104 Submission Agent (MSA). 106 3. Trace Fields 107 The definition of Trace Fields in [RFC5322] is updated to include all 108 of the header fields identified as Trace Fields in the IANA Permanent 109 Message Header Fields and Provisional Message Header Fields 110 registries. The initial set of Trace Fields for those registries is 111 listed in [ianainit]. 113 3.1. Usage of Trace Fields 115 The desired property of a Trace field is that any header field 116 defined as a Trace field SHOULD NOT be reordered within a message 117 header block or changed. In addition, a new Trace field SHOULD be 118 added to the top of the message header block. This makes it possible 119 to infer the history of the message from the sequence of header 120 fields. 122 There can be zero or more occurences of a Trace field in a message 123 header block. Further restrictions may be defined for Trace fields 124 by the specifications that provide for their use. 126 3.2. Trace fields in mail-related specifications 128 [RFC4408] defines the "Received-SPF:" header field as a Trace field 129 and specifies that it must appear above all other "Received-SPF:" 130 header fields. 132 [RFC6376] specifies that the "DKIM-Signature:" header field should be 133 treated as a Trace field and that it should not be reordered. It 134 mentions that the header field should be prepended to the message. 135 DomainKeys Identified Mail (DKIM) relies on maintaining the ordering 136 of header fields as a change of any "DKIM signed" header field can 137 invalidate the DKIM signature. 139 [RFC5451] defines an "Authentication-Results:" header field. It 140 mentions that the field should be treated as a Trace field to get an 141 idea of how far away authentication checks, such as DKIM and Sender 142 Policy Framework [RFC4408] were done. 144 [RFC5518] defines a "VBR-Info:" header field and mentions that a 145 message may contain multiple occurences of these header fields. The 146 document relies on the terminology in [RFC5322] to say that the "VBR- 147 Info:" header field is a "trace header field". It also specifies 148 that the header fields should be added at the top of the header 149 fields. 151 [RFC5436] defines an "Auto-Submitted:" header to be added to 152 notification messages generated by Sieve filtering rules. Section 153 2.7.1 says "The "Auto-Submitted:" header field is considered a Trace 154 field, similar to "Received:" header fields (see [RFC5321])." 156 4. Issues 158 a. The recommendation that trace header fields should be kept in 159 blocks is not always followed. Some implementations add any new 160 header field at the top of the message block without determining 161 whether it is a Trace field. 163 b. Messages can be forwarded by users. Adding Trace fields as part 164 of the body of the forwarded message ends up confusing users. 165 Some Trace fields are generally not relevant except for debugging 166 mail delivery issues. 168 5. IANA Considerations 170 IANA is requested to update the Permanent Message Header Fields and 171 Provisional Message Header Fields registries, defined in [RFC3864] to 172 include a new column called Trace Field. For each Header Field, this 173 column may be blank, in which case the header field is not a Trace 174 Field, or any of the tokens MTA, MUA, MSA, or MDA, to indicate that 175 the header field is a Trace Field, and which component typically adds 176 the header to a message. The distinction among non-blank tokens is 177 not normative, and a trace field MAY be added by any component that 178 handles a message. 180 The registration templates described in sections 4.2.1 and 4.2.2 of 181 [RFC3864] are each updated to add a new section: 183 Trace Field: Specify: blank, "MTA", "MUA", "MSA", or "MDA". If this 184 field is not an e-mail Trace Field, this section is left blank. 185 If it is a Trace Field, the component that typically adds the 186 field. 188 5.1. Initial set of Trace Fields 190 In the table below, the first column describes an existing Header 191 Field, and the second column is the value to put in its Trace Field. 192 The third column is for documentation, and is intended to match the 193 existing contents of the Reference column in the registries. For all 194 headers not in this list, the initial value of the Trace Field is 195 blank. 197 +-------------------------+-------------+-----------+ 198 | Header Field Name | Trace Field | Reference | 199 +-------------------------+-------------+-----------+ 200 | Authentication-Results: | MTA | [RFC5451] | 201 | Auto-Submitted: | MSA | [RFC5436] | 202 | DKIM-Signature: | MSA | [RFC6376] | 203 | Received: | MTA | [RFC5322] | 204 | Received-SPF: | MTA | [RFC4408] | 205 | Resent-Date: | MUA | [RFC5322] | 206 | Resent-From: | MUA | [RFC5322] | 207 | Resent-Sender: | MUA | [RFC5322] | 208 | Resent-To: | MUA | [RFC5322] | 209 | Resent-Cc: | MUA | [RFC5322] | 210 | Resent-Bcc: | MUA | [RFC5322] | 211 | Resent-Message-ID: | MUA | [RFC5322] | 212 | Return-Path: | MDA | [RFC5322] | 213 | VBR-Info: | MSA | [RFC5518] | 214 +-------------------------+-------------+-----------+ 216 Note: The Permanent Message Header Field Names registry currently 217 lists [RFC3834] as the reference for the Auto-Submitted: field, but 218 there is a later and more detailed description of it in [RFC5436] 219 that describes it as a trace field. 221 6. Security Considerations 223 Some people view the disclosure of trace fields such as the 224 "Received:" header field as a security risk as it may contain 225 information about internal mail servers. This lead to misguided 226 attempts to strip "Received:" header fields to hide information. 228 Trace fields are not guaranteed to be in a particular order; they 229 have been known to be reordered occasionally when transported over 230 the Internet. 232 7. References 234 7.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC3864] Klyne, G., Nottingham, M. and J. Mogul, "Registration 240 Procedures for Message Header Fields", BCP 90, RFC 3864, 241 September 2004. 243 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 244 October 2008. 246 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 247 2009. 249 7.2. Informative References 251 [RFC0822] Crocker, D.H., "Standard for the format of ARPA Internet 252 text messages", STD 11, RFC 822, August 1982. 254 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 255 April 2001. 257 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 258 2001. 260 [RFC3834] Moore, K., "Recommendations for Automatic Responses to 261 Electronic Mail", RFC 3834, August 2004. 263 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 264 for Authorizing Use of Domains in E-Mail, Version 1", RFC 265 4408, April 2006. 267 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 268 October 2008. 270 [RFC5436] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 271 mailto", RFC 5436, January 2009. 273 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 274 Message Authentication Status", RFC 5451, April 2009. 276 [RFC5518] Hoffman, P., Levine, J. and A. Hathcock, "Vouch By 277 Reference", RFC 5518, April 2009. 279 [RFC6376] Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys 280 Identified Mail (DKIM) Signatures", RFC 6376, September 281 2011. 283 Authors' Addresses 285 John Levine 286 Taughannock Networks 287 PO Box 727 288 Trumansburg, NY 14886 290 Phone: +1 831 480 2300 291 Email: standards@taugh.com 293 S. Moonesamy 294 76, Ylang Ylang Avenue 295 Quatre Bornes, 296 Mauritius 298 Email: sm+ietf@elandsys.com