7Internet Engineering Task Force (IETF) M. Kucherawy, Ed.
8Request for Comments: 6522 Cloudmark
11Category: Standards Track
15 The Multipart/Report Media Type for
16 the Reporting of Mail System Administrative Messages
20 The multipart/report Multipurpose Internet Mail Extensions (MIME)
21 media type is a general "family" or "container" type for electronic
22 mail reports of any kind. Although this memo defines only the use of
23 the multipart/report media type with respect to delivery status
24 reports, mail processing programs will benefit if a single media type
25 is used for all kinds of reports.
27 This memo obsoletes "The Multipart/Report Content Type for the
28 Reporting of Mail System Administrative Messages", RFC 3462, and
29 marks RFC 3462 and its predecessor as "Historic".
33 This is an Internet Standards Track document.
35 This document is a product of the Internet Engineering Task Force
36 (IETF). It represents the consensus of the IETF community. It has
37 received public review and has been approved for publication by the
38 Internet Engineering Steering Group (IESG). Further information on
39 Internet Standards is available in Section 2 of RFC 5741.
41 Information about the current status of this document, any errata,
42 and how to provide feedback on it may be obtained at
43 http://www.rfc-editor.org/info/rfc6522.
58Kucherawy Standards Track [Page 1]
60RFC 6522 Multipart/Report Media Type January 2012
65 Copyright (c) 2012 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
92 1. Introduction ....................................................3
93 2. Document Conventions ............................................3
94 3. The Multipart/Report Media Type .................................3
95 4. The text/rfc822-headers Media Type ..............................5
96 5. Registering New Report Types ....................................7
97 6. IANA Considerations .............................................7
98 7. Security Considerations .........................................7
99 8. References ......................................................7
100 8.1. Normative References .......................................7
101 8.2. Informative References .....................................8
102 Appendix A. Acknowledgements ......................................9
114Kucherawy Standards Track [Page 2]
116RFC 6522 Multipart/Report Media Type January 2012
121 [OLD-REPORT] and its antecedent declared the multipart/report media
122 type for use within the [MIME] construct to create a container for
123 mail system administrative reports of various kinds.
125 Practical experience has shown that the general requirement of having
126 that media type constrained to be used only as the outermost MIME
127 type of a message is overly restrictive and limits such things as the
128 transmission of multiple administrative reports within a single
129 overall message container. In particular, it prevents one from
130 forwarding a report as part of another multipart MIME message.
132 This memo removes that constraint. No other changes apart from some
133 editorial ones are made. Other memos might update other documents to
134 establish or clarify the constraints on use of multipart/report in
135 contexts where such are needed.
137 This memo obsoletes RFC 3462. RFC 3462 and its predecessor, RFC
138 1892, have been marked as "Historic".
1402. Document Conventions
142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
144 document are to be interpreted as described in [KEYWORDS].
1463. The Multipart/Report Media Type
148 The multipart/report MIME media type is a general "family" or
149 "container" type for electronic mail reports of any kind. Although
150 this memo defines only the use of the multipart/report media type
151 with respect to delivery status reports, mail processing programs
152 will benefit if a single media type is used for all kinds of reports.
154 Per [MIME-REG], the multipart/report media type is defined as
161 Required parameters: boundary, report-type
163 Optional parameters: none
170Kucherawy Standards Track [Page 3]
172RFC 6522 Multipart/Report Media Type January 2012
175 Encoding considerations: 7bit should always be adequate
177 Security considerations: see Section 7 of [RFC6522]
179 Interoperability considerations: see Section 1 of [RFC6522]
181 Published specification: [RFC6522]
183 Applications that use this media type: Mail Transfer Agents, Mail
184 User Agents, spam detection and reporting modules, virus detection
185 modules, and message authentication modules.
187 Additional information:
191 File extension(s): N/A
193 Macintosh file type code(s): N/A
195 Person and email address to contact for further information: Murray
196 S. Kucherawy <msk@cloudmark.com>
198 Intended usage: common
200 Restrictions on usage: none; however, other applications that
201 register report types may establish such restrictions.
203 Author: Murray S. Kucherawy <msk@cloudmark.com>
205 Change controller: IESG
207 The syntax of multipart/report is identical to the multipart/mixed
208 content type defined in [MIME]. The report-type parameter identifies
209 the type of report. The parameter is the MIME subtype of the second
210 body part of the multipart/report. (See Section 5.)
212 The multipart/report media type contains either two or three sub-
213 parts, in the following order:
215 1. (REQUIRED) The first body part contains a human-readable message.
216 The purpose of this message is to provide an easily understood
217 description of the condition(s) that caused the report to be
218 generated, for a human reader who might not have a user agent
219 capable of interpreting the second section of the multipart/
220 report. The text in the first section can use any IANA-
221 registered MIME media type, charset, or language. Where a
222 description of the error is desired in several languages or
226Kucherawy Standards Track [Page 4]
228RFC 6522 Multipart/Report Media Type January 2012
231 several media, a multipart/alternative construct MAY be used.
232 This body part MAY also be used to send detailed information that
233 cannot be easily formatted into the second body part.
235 2. (REQUIRED) A machine-parsable body part containing an account of
236 the reported message handling event. The purpose of this body
237 part is to provide a machine-readable description of the
238 condition(s) that caused the report to be generated, along with
239 details not present in the first body part that might be useful
240 to human experts. An initial body part, message/delivery-status,
241 is defined in [DSN-FORMAT].
243 3. (OPTIONAL) A body part containing the returned message or a
244 portion thereof. This information could be useful to aid human
245 experts in diagnosing problems. (Although it might also be
246 useful to allow the sender to identify the message about which
247 the report was issued, it is hoped that the envelope-id and
248 original-recipient-address returned in the message/report body
249 part will replace the traditional use of the returned content for
252 Return of content can be wasteful of network bandwidth and a variety
253 of implementation strategies can be used. Generally, the sender
254 needs to choose the appropriate strategy and inform the recipient of
255 the required level of returned content required. In the absence of
256 an explicit request for level of return of content such as that
257 provided in [DSN-SMTP], the agent that generated the delivery service
258 report SHOULD return the full message content.
260 When 8-bit or binary data not encoded in a 7-bit form is to be
261 returned, and the return path is not guaranteed to be 8-bit or binary
262 capable, two options are available. The original message MAY be
263 re-encoded into a legal 7-bit MIME message or the text/rfc822-headers
264 media type MAY be used to return only the original message headers.
2664. The text/rfc822-headers Media Type
268 The text/rfc822-headers media type provides a mechanism to label and
269 return only the [MAIL] header of a failed message. The header is not
270 the complete message and SHOULD NOT be returned using the message/
271 rfc822 media type defined in [MIME-TYPES]. The returned header is
272 useful for identifying the failed message and for diagnostics based
273 on the Received header fields.
282Kucherawy Standards Track [Page 5]
284RFC 6522 Multipart/Report Media Type January 2012
287 The text/rfc822-headers media type is defined as follows:
291 Subtype name: rfc822-headers
293 Required parameters: None
295 Optional parameters: None
297 Encoding considerations: 7-bit is sufficient for normal mail
298 headers, however, if the headers are broken or extended and
299 require encoding to make them legal 7-bit content, they MAY be
300 encoded with quoted-printable as defined in [MIME].
302 Security considerations: See Section 7 of [RFC6522].
304 Interoperability considerations: none
306 Published specification: [RFC6522]
308 Applications that use this media type: Mail Transfer Agents, Mail
309 User Agents, spam detection and reporting modules, virus detection
310 modules, and message authentication modules.
312 Additional information:
316 File extension(s): N/A
318 Macintosh file type code(s): N/A
320 Person and email address to contact for further information: Murray
321 S. Kucherawy <msk@cloudmark.com>
323 Intended usage: common
325 Restrictions on usage: none
327 Author: Murray S. Kucherawy <msk@cloudmark.com>
329 Change controller: IESG
331 The text/rfc822-headers body part SHOULD contain all the mail header
332 fields from the message that caused the report. The header includes
333 all header fields prior to the first blank line in the message. They
334 include the MIME-Version and MIME content description fields.
338Kucherawy Standards Track [Page 6]
340RFC 6522 Multipart/Report Media Type January 2012
3435. Registering New Report Types
345 Registration of new media types for the purpose of creating a new
346 report format SHOULD note in the Intended Usage section of the media
347 type registration that the type being registered is suitable for use
348 as a report-type (i.e., the second body part) in the context of this
3516. IANA Considerations
353 IANA has updated the Media Type Registry to indicate that this memo
354 contains the current definition of the multipart/report and text/
355 rfc822-headers media types, obsoleting [OLD-REPORT].
3577. Security Considerations
359 Automated use of report types without authentication presents several
360 security issues. Forging negative reports presents the opportunity
361 for denial-of-service attacks when the reports are used for automated
362 maintenance of directories or mailing lists. Forging positive
363 reports can cause the sender to incorrectly believe a message was
364 delivered when it was not.
366 A signature covering the entire multipart/report structure could be
367 used to prevent such forgeries; such a signature scheme is, however,
368 beyond the scope of this document.
3728.1. Normative References
374 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
375 Requirement Levels", BCP 14, RFC 2119, March 1997.
377 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
380 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
381 Mail Extensions (MIME) Part One: Format of Internet
382 Message Bodies", RFC 2045, November 1996.
384 [MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications
385 and Registration Procedures", BCP 13, RFC 4288,
388 [MIME-TYPES] Freed, N. and N. Borenstein, "Multipurpose Internet
389 Mail Extensions (MIME) Part Two: Media Types",
390 RFC 2046, November 1996.
394Kucherawy Standards Track [Page 7]
396RFC 6522 Multipart/Report Media Type January 2012
3998.2. Informative References
401 [DSN-FORMAT] Moore, K. and G. Vaudreuil, "An Extensible Message
402 Format for Delivery Status Notifications", RFC 3464,
405 [DSN-SMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP)
406 Service Extension for Delivery Status Notifications
407 (DSNs)", RFC 3461, January 2003.
409 [OLD-REPORT] Vaudreuil, G., "The Multipart/Report Content Type for
410 the Reporting of Mail System Administrative Messages",
411 RFC 3462, January 2003.
450Kucherawy Standards Track [Page 8]
452RFC 6522 Multipart/Report Media Type January 2012
455Appendix A. Acknowledgements
457 The author would like to thank Dave Crocker, Frank Ellermann, Ned
458 Freed, Randall Gellens, Alexey Melnikov, and Keith Moore for their
459 input to this update.
461 Thanks also go to Gregory M. Vaudreuil, the original creator of this
466 Murray S. Kucherawy (editor)
468 128 King St., 2nd Floor
469 San Francisco, CA 94107
472 Phone: +1 415 946 3800
473 EMail: msk@cloudmark.com
506Kucherawy Standards Track [Page 9]