idnits 2.17.1 draft-kucherawy-rfc3462bis-02.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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 30, 2011) is 4647 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) == Missing Reference: 'REQUIRED' is mentioned on line 137, but not defined == Missing Reference: 'OPTIONAL' is mentioned on line 145, but not defined ** Obsolete normative reference: RFC 4288 (ref. 'MIME-REG') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3462 (ref. 'OLD-REPORT') (Obsoleted by RFC 6522) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission M. Kucherawy 3 Internet-Draft Cloudmark 4 Obsoletes: 3462 (if approved) July 30, 2011 5 Intended status: Standards Track 6 Expires: January 31, 2012 8 The Multipart/Report Media Type for the Reporting of Mail System 9 Administrative Messages 10 draft-kucherawy-rfc3462bis-02 12 Abstract 14 The multipart/report Multipurpose Internet Mail Extensions (MIME) 15 media type is a general "family" or "container" type for electronic 16 mail reports of any kind. Although this memo defines only the use of 17 the multipart/report media type with respect to delivery status 18 reports, mail processing programs will benefit if a single media type 19 is used for all kinds of reports. 21 This memo obsoletes RFC3462. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 31, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 59 3. The multipart/report Media Type . . . . . . . . . . . . . . . 5 60 4. The text/rfc822-headers Media Type . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 67 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 [OLD-REPORT] and its antecedent declared the multipart/report media 73 type for use within the [MIME] construct to create a container for 74 mail system administrative reports of various kinds. 76 Practical experience has shown that the general requirement of having 77 that media type constrained to be used only as the outermost MIME 78 type of a message, while well-intentioned, has provided little 79 operational benefit and actually limits such things as the 80 transmission of multiple administrative reports within a single 81 overall message container. In particular, it prevents one from 82 forwarding a report as part of another mulipart MIME message. 84 This memo removes that constraint. No other changes apart from some 85 editorial ones are made. Other memos might update other documents to 86 establish or clarify the constraint where it is more appropriate. 88 2. Document Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in BCP 14, [KEYWORDS]. 94 3. The multipart/report Media Type 96 The multipart/report MIME media type is a general "family" or 97 "container" type for electronic mail reports of any kind. Although 98 this memo defines only the use of the multipart/report media type 99 with respect to delivery status reports, mail processing programs 100 will benefit if a single media type is used for all kinds of reports. 102 Per [MIME-REG], the multipart/report media type is defined as 103 follows: 105 MIME type name: multipart 107 MIME subtype name: report 109 Required parameters: boundary, report-type 111 Optional parameters: none 113 Encoding considerations: 7bit should always be adequate 115 Security considerations: see Section 6 of this memo 117 The syntax of multipart/report is identical to the multipart/mixed 118 content type defined in [MIME]. The report-type parameter identifies 119 the type of report. The parameter is the MIME sub-type of the second 120 body part of the multipart/report. 122 The multipart/report media type contains either two or three sub- 123 parts, in the following order: 125 1. [REQUIRED] The first body part contains a human readable message. 126 The purpose of this message is to provide an easily understood 127 description of the condition(s) that caused the report to be 128 generated, for a human reader who may not have a user agent 129 capable of interpreting the second section of the multipart/ 130 report. The text in the first section may be in any MIME 131 standards-track media type, charset, or language. Where a 132 description of the error is desired in several languages or 133 several media, a multipart/alternative construct MAY be used. 134 This body part MAY also be used to send detailed information that 135 cannot be easily formatted into the second body part. 137 2. [REQUIRED] A machine parsable body part containing an account of 138 the reported message handling event. The purpose of this body 139 part is to provide a machine-readable description of the 140 condition(s) that caused the report to be generated, along with 141 details not present in the first body part that may be useful to 142 human experts. An initial body part, message/delivery-status is 143 defined in [DSN-FORMAT]. 145 3. [OPTIONAL] A body part containing the returned message or a 146 portion thereof. This information could be useful to aid human 147 experts in diagnosing problems. (Although it might also be 148 useful to allow the sender to identify the message about which 149 the report was issued, it is hoped that the envelope-id and 150 original-recipient-address returned in the message/report body 151 part will replace the traditional use of the returned content for 152 this purpose.) 154 Return of content may be wasteful of network bandwidth and a variety 155 of implementation strategies can be used. Generally the sender 156 should choose the appropriate strategy and inform the recipient of 157 the required level of returned content required. In the absence of 158 an explicit request for level of return of content such as that 159 provided in [DSN-SMTP], the agent that generated the delivery service 160 report SHOULD return the full message content. 162 When 8-bit or binary data not encoded in a 7-bit form is to be 163 returned, and the return path is not guaranteed to be 8-bit or binary 164 capable, two options are available. The original message MAY be re- 165 encoded into a legal 7-bit MIME message or the text/rfc822-headers 166 media type MAY be used to return only the original message headers. 168 4. The text/rfc822-headers Media Type 170 The text/rfc822-headers media type provides a mechanism to label and 171 return only the [MAIL] header of a failed message. The header is not 172 the complete message and SHOULD NOT be returned using the message/ 173 rfc822 media type defined in [MIME-TYPES]. The returned header is 174 useful for identifying the failed message and for diagnostics based 175 on the Received header fields. 177 The text/rfc822-headers media type is defined as follows: 179 MIME type name: text 181 MIME subtype name: rfc822-headers 183 Required parameters: None 185 Optional parameters: None 187 Encoding considerations: 7-bit is sufficient for normal mail 188 headers, however, if the headers are broken and require encoding 189 to make them legal 7-bit content, they may be encoded with quoted- 190 printable as defined in [MIME] 192 Security considerations: See Section 6 of this memo. 194 The text/rfc822-headers body part SHOULD contain all the mail header 195 fields from the message that caused the report. The header includes 196 all header fields prior to the first blank line in the message. They 197 include the MIME-Version and MIME content description fields. 199 5. IANA Considerations 201 IANA is directed to update the Media Type Registry to indicate that 202 this memo contains the current definition of the multipart/report and 203 text/rfc822-headers media types, obsoleting [OLD-REPORT]. 205 6. Security Considerations 207 Automated use of report types without authentication presents several 208 security issues. Forging negative reports presents the opportunity 209 for denial-of-service attacks when the reports are used for automated 210 maintenance of directories or mailing lists. Forging positive 211 reports may cause the sender to incorrectly believe a message was 212 delivered when it was not. 214 A signature covering the entire multipart/report structure could be 215 used to prevent such forgeries; such a signature scheme is, however, 216 beyond the scope of this document. 218 7. References 220 7.1. Normative References 222 [KEYWORDS] 223 Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", RFC 2119, March 1997. 226 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 227 October 2008. 229 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 230 Extensions (MIME) Part One: Format of Internet Message 231 Bodies", RFC 2045, November 1996. 233 [MIME-REG] 234 Freed, N. and J. Klensin, "Media Type Specifications and 235 Registration Procedures", RFC 4288, December 2005. 237 [MIME-TYPES] 238 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 239 Extensions (MIME) Part Two: Media Types", RFC 2046, 240 November 1996. 242 [OLD-REPORT] 243 Vaudreuil, G., "The Multipart/Report Content Type for the 244 Reporting of Mail System Administrative Messages", 245 RFC 3462, January 2003. 247 7.2. Informative References 249 [DSN-FORMAT] 250 Moore, K. and G. Vaudreuil, "An Extensible Message Format 251 for Delivery Status Notifications", RFC 3464, 252 January 2003. 254 [DSN-SMTP] 255 Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 256 Extension for Delivery Status Notifications (DSNs)", 257 RFC 3461, January 2003. 259 Appendix A. Acknowledgements 261 The author would like to thank Ned Freed and Keith Moore for their 262 input to this update. 264 Appendix B. Document History 266 Changes from draft-kucherawy-rfc3462bis-01 to 267 draft-kucherawy-rfc3462bis-02: 269 o Revert to removing the restriction altogether, noting that the DSN 270 and MDN RFCs re-state it. Thus, removing it here solves MARF's 271 problem but doesn't impact DSN and MDN. The restriction can be 272 clarified on those documents in separate efforts. 274 Changes from draft-kucherawy-rfc3462bis-00 to 275 draft-kucherawy-rfc3462bis-01: 277 o Clarify requirement that multipart/report must be the outermost 278 media type; require it only when generating a report. 280 o Highlight the forwarding-of-reports problem. 282 o Limit the constraint to time of report generation. 284 o Remove "Examples" section. 286 Changes from RFC3462 to draft-kucherawy-rfc3462bis-00: 288 o Remove requirement that multipart/report not be contained in 289 anything. 291 o Some minor adjustment to use current terminology, such as 292 distinguishing between a header and a header field. 294 o More obvious use of the standard normative words. 296 Author's Address 298 Murray S. Kucherawy 299 Cloudmark 300 128 King St., 2nd Floor 301 San Francisco, CA 94107 302 US 304 Phone: +1 415 946 3800 305 Email: msk@cloudmark.com