Individual Submission M. Kucherawy Internet-Draft Cloudmark Obsoletes: 3462 (if approved) July 26, 2011 Intended status: Standards Track Expires: January 27, 2012 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages draft-kucherawy-rfc3462bis-01 Abstract The multipart/report Multipurpose Internet Mail Extensions (MIME) media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used to for all kinds of reports. 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 January 27, 2012. Copyright Notice Copyright (c) 2011 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 Kucherawy Expires January 27, 2012 [Page 1] Internet-Draft Multipart/Report Media Type July 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions . . . . . . . . . . . . . . . . . . . . . 4 3. The multipart/report Media Type . . . . . . . . . . . . . . . 5 4. The text/rfc822-headers Media Type . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Document History . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Kucherawy Expires January 27, 2012 [Page 2] Internet-Draft Multipart/Report Media Type July 2011 1. Introduction [OLD-REPORT] and its antecedent declared the multipart/report media type for use within the [MIME] construct to create a container for mail system administrative reports of various kinds. Practical experience has shown that the general requirement of having that media type constrained to be used only as the outermost MIME type of a message, while well-intentioned, has provided little operational benefit and actually limits such things as the transmission of multiple administrative reports within a single overall message container. In particular, it prevents one from forwarding a report as part of another mulipart MIME message. This memo rewrites the constraint such that it only applies at the time the report is generated. No other changes other than some editorial ones are made. Kucherawy Expires January 27, 2012 [Page 3] Internet-Draft Multipart/Report Media Type July 2011 2. Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [KEYWORDS]. Kucherawy Expires January 27, 2012 [Page 4] Internet-Draft Multipart/Report Media Type July 2011 3. The multipart/report Media Type The multipart/report MIME media type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the multipart/report media type with respect to delivery status reports, mail processing programs will benefit if a single media type is used to for all kinds of reports. Per [MIME-REG], the multipart/report media type is defined as follows: MIME type name: multipart MIME subtype name: report Required parameters: boundary, report-type Optional parameters: none Encoding considerations: 7bit should always be adequate Security considerations: see Section 6 of this memo The syntax of multipart/report is identical to the multipart/mixed content type defined in [MIME]. The report-type parameter identifies the type of report. The parameter is the MIME sub-type of the second body part of the multipart/report. User agents and gateways need to be able to determine automatically that a message is a mail system report and need to be processed as such. Placing the multipart/report as the outermost content provides a mechanism whereby an auto-processor can detect through parsing the message header that the message is a report. Therefore, when used to generate a report, the multipart/report content-type MUST be the top- level MIME content type for any report message. However, when forwarding or otherwise packaging a previously-generated report, this constraint is not in effect. The multipart/report media type contains either two or three sub- parts, in the following order: 1. [REQUIRED] The first body part contains a human readable message. The purpose of this message is to provide an easily understood description of the condition(s) that caused the report to be generated, for a human reader who may not have a user agent capable of interpreting the second section of the multipart/ report. The text in the first section may be in any MIME Kucherawy Expires January 27, 2012 [Page 5] Internet-Draft Multipart/Report Media Type July 2011 standards-track media type, charset, or language. Where a description of the error is desired in several languages or several media, a multipart/alternative construct MAY be used. This body part MAY also be used to send detailed information that cannot be easily formatted into the second body part. 2. [REQUIRED] A machine parsable body part containing an account of the reported message handling event. The purpose of this body part is to provide a machine-readable description of the condition(s) that caused the report to be generated, along with details not present in the first body part that may be useful to human experts. An initial body part, message/delivery-status is defined in [DSN-FORMAT]. 3. [OPTIONAL] A body part containing the returned message or a portion thereof. This information could be useful to aid human experts in diagnosing problems. (Although it might also be useful to allow the sender to identify the message about which the report was issued, it is hoped that the envelope-id and original-recipient-address returned in the message/report body part will replace the traditional use of the returned content for this purpose.) Return of content may be wasteful of network bandwidth and a variety of implementation strategies can be used. Generally the sender should choose the appropriate strategy and inform the recipient of the required level of returned content required. In the absence of an explicit request for level of return of content such as that provided in [DSN-SMTP], the agent that generated the delivery service report SHOULD return the full message content. When 8-bit or binary data not encoded in a 7-bit form is to be returned, and the return path is not guaranteed to be 8-bit or binary capable, two options are available. The original message MAY be re- encoded into a legal 7-bit MIME message or the text/rfc822-headers media type MAY be used to return only the original message headers. Kucherawy Expires January 27, 2012 [Page 6] Internet-Draft Multipart/Report Media Type July 2011 4. The text/rfc822-headers Media Type The text/rfc822-headers media type provides a mechanism to label and return only the [MAIL] header of a failed message. The header is not the complete message and SHOULD NOT be returned using the message/ rfc822 media type defined in [MIME-TYPES]. The returned header is useful for identifying the failed message and for diagnostics based on the Received header fields. The text/rfc822-headers media type is defined as follows: MIME type name: text MIME subtype name: rfc822-headers Required parameters: None Optional parameters: None Encoding considerations: 7-bit is sufficient for normal mail headers, however, if the headers are broken and require encoding to make them legal 7-bit content, they may be encoded with quoted- printable as defined in [MIME] Security considerations: See Section 6 of this memo. The text/rfc822-headers body part SHOULD contain all the mail header fields from the message that caused the report. The header includes all header fields prior to the first blank line in the message. They include the MIME-Version and MIME content description fields. Kucherawy Expires January 27, 2012 [Page 7] Internet-Draft Multipart/Report Media Type July 2011 5. IANA Considerations IANA is directed to update the Media Type Registry to indicate that this memo contains the current definition of the multipart/report and text/rfc822-headers media types, obsoleting [OLD-REPORT]. Kucherawy Expires January 27, 2012 [Page 8] Internet-Draft Multipart/Report Media Type July 2011 6. Security Considerations Automated use of report types without authentication presents several security issues. Forging negative reports presents the opportunity for denial-of-service attacks when the reports are used for automated maintenance of directories or mailing lists. Forging positive reports may cause the sender to incorrectly believe a message was delivered when it was not. A signature covering the entire multipart/report structure could be used to prevent such forgeries; such a signature scheme is, however, beyond the scope of this document. Kucherawy Expires January 27, 2012 [Page 9] Internet-Draft Multipart/Report Media Type July 2011 7. References 7.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [MAIL] Resnick, P., "Internet Message Format", RFC 5322, October 2008. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005. [MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003. 7.2. Informative References [DSN-FORMAT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. Kucherawy Expires January 27, 2012 [Page 10] Internet-Draft Multipart/Report Media Type July 2011 Appendix A. Acknowledgements The author would like to thank Ned Freed and Keith Moore for their input to this update. Kucherawy Expires January 27, 2012 [Page 11] Internet-Draft Multipart/Report Media Type July 2011 Appendix B. Document History Changes from RFC3462 to draft-kucherawy-rfc3462bis-00: o Clarify requirement that multipart/report must be the outermost media type; require it only when generating a report. o Some minor adjustment to use current terminology, such as distinguishing between a header and a header field. o More obvious use of the standard normative words. Kucherawy Expires January 27, 2012 [Page 12] Internet-Draft Multipart/Report Media Type July 2011 Author's Address Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US Phone: +1 415 946 3800 Email: msk@cloudmark.com Kucherawy Expires January 27, 2012 [Page 13]