idnits 2.17.1 draft-ietf-appsawg-rfc3462bis-04.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 (November 29, 2011) is 4531 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) ** Obsolete normative reference: RFC 4288 (ref. 'MIME-REG') (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 3462 (ref. 'OLD-REPORT') (Obsoleted by RFC 6522) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission M. Kucherawy, Ed. 3 Internet-Draft Cloudmark 4 Obsoletes: 3462 (if approved) November 29, 2011 5 Intended status: Standards Track 6 Expires: June 1, 2012 8 The Multipart/Report Media Type for the Reporting of Mail System 9 Administrative Messages 10 draft-ietf-appsawg-rfc3462bis-04 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. The IESG is also requested to mark 22 RFC1892 and RFC3462 as "historic". 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 1, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 5 72 3. The multipart/report Media Type . . . . . . . . . . . . . . . 6 73 4. The text/rfc822-headers Media Type . . . . . . . . . . . . . . 9 74 5. Registering New Report Types . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 80 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 81 Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 [OLD-REPORT] and its antecedent declared the multipart/report media 87 type for use within the [MIME] construct to create a container for 88 mail system administrative reports of various kinds. 90 Practical experience has shown that the general requirement of having 91 that media type constrained to be used only as the outermost MIME 92 type of a message is overly restrictive and limits such things as the 93 transmission of multiple administrative reports within a single 94 overall message container. In particular, it prevents one from 95 forwarding a report as part of another multipart MIME message. 97 This memo removes that constraint. No other changes apart from some 98 editorial ones are made. Other memos might update other documents to 99 establish or clarify the constraints on use of multipart/report in 100 contexts where such are needed. 102 This memo obsoletes RFC3462. The IESG is also requested to mark 103 RFC1892 and RFC3462 as "historic". 105 2. Document Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [KEYWORDS]. 111 3. The multipart/report Media Type 113 The multipart/report MIME media type is a general "family" or 114 "container" type for electronic mail reports of any kind. Although 115 this memo defines only the use of the multipart/report media type 116 with respect to delivery status reports, mail processing programs 117 will benefit if a single media type is used for all kinds of reports. 119 Per [MIME-REG], the multipart/report media type is defined as 120 follows: 122 Type name: multipart 124 Subtype name: report 126 Required parameters: boundary, report-type 128 Optional parameters: none 130 Encoding considerations: 7bit should always be adequate 132 Security considerations: see Section 7 of [this memo] 134 Interoperability considerations: see Section 1 of [this memo] 136 Published specification: [this memo] 138 Applications that use this media type: Mail Transfer Agents, Mail 139 User Agents, spam detection and reporting modules, virus detection 140 modules, message authentication modules 142 Additional information: 144 Magic number(s): N/A 146 File extensions(s): N/A 148 Macintosh file type code(s): N/A 150 Person and email address to contact for further information: Murray 151 S. Kucherawy 153 Intended usage: common 155 Restrictions on usage: none; however, other applications that 156 register report types may establish such restrictions 158 Author: Murray S. Kucherawy 160 Change controller: IESG 162 The syntax of multipart/report is identical to the multipart/mixed 163 content type defined in [MIME]. The report-type parameter identifies 164 the type of report. The parameter is the MIME sub-type of the second 165 body part of the multipart/report. (See Section 5.) 167 The multipart/report media type contains either two or three sub- 168 parts, in the following order: 170 1. (REQUIRED) The first body part contains a human readable message. 171 The purpose of this message is to provide an easily understood 172 description of the condition(s) that caused the report to be 173 generated, for a human reader who might not have a user agent 174 capable of interpreting the second section of the multipart/ 175 report. The text in the first section can use any IANA- 176 registered MIME media type, charset, or language. Where a 177 description of the error is desired in several languages or 178 several media, a multipart/alternative construct MAY be used. 179 This body part MAY also be used to send detailed information that 180 cannot be easily formatted into the second body part. 182 2. (REQUIRED) A machine parsable body part containing an account of 183 the reported message handling event. The purpose of this body 184 part is to provide a machine-readable description of the 185 condition(s) that caused the report to be generated, along with 186 details not present in the first body part that might be useful 187 to human experts. An initial body part, message/delivery-status 188 is defined in [DSN-FORMAT]. 190 3. (OPTIONAL) A body part containing the returned message or a 191 portion thereof. This information could be useful to aid human 192 experts in diagnosing problems. (Although it might also be 193 useful to allow the sender to identify the message about which 194 the report was issued, it is hoped that the envelope-id and 195 original-recipient-address returned in the message/report body 196 part will replace the traditional use of the returned content for 197 this purpose.) 199 Return of content can be wasteful of network bandwidth and a variety 200 of implementation strategies can be used. Generally the sender needs 201 to choose the appropriate strategy and inform the recipient of the 202 required level of returned content required. In the absence of an 203 explicit request for level of return of content such as that provided 204 in [DSN-SMTP], the agent that generated the delivery service report 205 SHOULD return the full message content. 207 When 8-bit or binary data not encoded in a 7-bit form is to be 208 returned, and the return path is not guaranteed to be 8-bit or binary 209 capable, two options are available. The original message MAY be re- 210 encoded into a legal 7-bit MIME message or the text/rfc822-headers 211 media type MAY be used to return only the original message headers. 213 4. The text/rfc822-headers Media Type 215 The text/rfc822-headers media type provides a mechanism to label and 216 return only the [MAIL] header of a failed message. The header is not 217 the complete message and SHOULD NOT be returned using the message/ 218 rfc822 media type defined in [MIME-TYPES]. The returned header is 219 useful for identifying the failed message and for diagnostics based 220 on the Received header fields. 222 The text/rfc822-headers media type is defined as follows: 224 Type name: text 226 Subtype name: rfc822-headers 228 Required parameters: None 230 Optional parameters: None 232 Encoding considerations: 7-bit is sufficient for normal mail 233 headers, however, if the headers are broken or extended and 234 require encoding to make them legal 7-bit content, they MAY be 235 encoded with quoted-printable as defined in [MIME] 237 Security considerations: See Section 7 of [this memo]. 239 Interoperability considerations: none 241 Published specification: [this memo] 243 Applications that use this media type: Mail Transfer Agents, Mail 244 User Agents, spam detection and reporting modules, virus detection 245 modules, message authentication modules 247 Additional information: 249 Magic number(s): N/A 251 File extensions(s): N/A 253 Macintosh file type code(s): N/A 255 Person and email address to contact for further information: Murray 256 S. Kucherawy 258 Intended usage: common 260 Restrictions on usage: none 262 Author: Murray S. Kucherawy 264 Change controller: IESG 266 The text/rfc822-headers body part SHOULD contain all the mail header 267 fields from the message that caused the report. The header includes 268 all header fields prior to the first blank line in the message. They 269 include the MIME-Version and MIME content description fields. 271 5. Registering New Report Types 273 Registration of new media types for the purpose of creating a new 274 report format SHOULD note in the Intended Usage section of the media 275 type registration that the type being registered is suitable for use 276 as a report-type (i.e., the second body part) in the context of this 277 specification. 279 6. IANA Considerations 281 IANA is directed to update the Media Type Registry to indicate that 282 this memo contains the current definition of the multipart/report and 283 text/rfc822-headers media types, obsoleting [OLD-REPORT]. 285 7. Security Considerations 287 Automated use of report types without authentication presents several 288 security issues. Forging negative reports presents the opportunity 289 for denial-of-service attacks when the reports are used for automated 290 maintenance of directories or mailing lists. Forging positive 291 reports can cause the sender to incorrectly believe a message was 292 delivered when it was not. 294 A signature covering the entire multipart/report structure could be 295 used to prevent such forgeries; such a signature scheme is, however, 296 beyond the scope of this document. 298 8. References 300 8.1. Normative References 302 [KEYWORDS] 303 Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", RFC 2119, March 1997. 306 [MAIL] Resnick, P., "Internet Message Format", RFC 5322, 307 October 2008. 309 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 310 Extensions (MIME) Part One: Format of Internet Message 311 Bodies", RFC 2045, November 1996. 313 [MIME-REG] 314 Freed, N. and J. Klensin, "Media Type Specifications and 315 Registration Procedures", RFC 4288, December 2005. 317 [MIME-TYPES] 318 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 319 Extensions (MIME) Part Two: Media Types", RFC 2046, 320 November 1996. 322 8.2. Informative References 324 [DSN-FORMAT] 325 Moore, K. and G. Vaudreuil, "An Extensible Message Format 326 for Delivery Status Notifications", RFC 3464, 327 January 2003. 329 [DSN-SMTP] 330 Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 331 Extension for Delivery Status Notifications (DSNs)", 332 RFC 3461, January 2003. 334 [OLD-REPORT] 335 Vaudreuil, G., "The Multipart/Report Content Type for the 336 Reporting of Mail System Administrative Messages", 337 RFC 3462, January 2003. 339 Appendix A. Acknowledgements 341 The author would like to thank Dave Crocker, Frank Ellermann, Ned 342 Freed, Randall Gellens, Alexey Melnikov and Keith Moore for their 343 input to this update. 345 Thanks also go to Gregory M. Vaudreuil, the original creator of this 346 media type. 348 Appendix B. Document History 350 [RFC Editor: Please remove this section prior to publication.] 352 Changes from draft-ietf-appsawg-rfc3462bis-01 to 353 draft-ietf-appsawg-rfc3462bis-02: 355 o Minor copy editing based on WGLC feedback. 357 o Make OLD-REPORT into an informative reference. 359 o Update media type registration templates. 361 Changes from draft-ietf-appsawg-rfc3462bis-00 to 362 draft-ietf-appsawg-rfc3462bis-01: 364 o Minor copy editing based on WG feedback. 366 Changes from draft-kucherawy-rfc3462bis-02 to 367 draft-ietf-appsawg-rfc3462bis-00: 369 o Renamed. 371 Changes from draft-kucherawy-rfc3462bis-01 to 372 draft-kucherawy-rfc3462bis-02: 374 o Revert to removing the restriction altogether, noting that the DSN 375 and MDN RFCs re-state it. Thus, removing it here solves MARF's 376 problem but doesn't impact DSN and MDN. The restriction can be 377 clarified on those documents in separate efforts. 379 Changes from draft-kucherawy-rfc3462bis-00 to 380 draft-kucherawy-rfc3462bis-01: 382 o Clarify requirement that multipart/report must be the outermost 383 media type; require it only when generating a report. 385 o Highlight the forwarding-of-reports problem. 387 o Limit the constraint to time of report generation. 389 o Remove "Examples" section. 391 Changes from RFC3462 to draft-kucherawy-rfc3462bis-00: 393 o Remove requirement that multipart/report not be contained in 394 anything. 396 o Some minor adjustment to use current terminology, such as 397 distinguishing between a header and a header field. 399 o More obvious use of the standard normative words. 401 Author's Address 403 Murray S. Kucherawy (editor) 404 Cloudmark 405 128 King St., 2nd Floor 406 San Francisco, CA 94107 407 US 409 Phone: +1 415 946 3800 410 Email: msk@cloudmark.com