The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
RFC 3462
Document | Type |
RFC - Draft Standard
(January 2003; No errata)
Obsoleted by RFC 6522
Updated by RFC 5337
Obsoletes RFC 1892
Was draft-vaudreuil-1892bis (individual in app area)
|
|
---|---|---|---|
Author | Gregory Vaudreuil | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3462 (Draft Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ned Freed | ||
IESG note | RFCs 3461-3464 published 23-Jan-2003 | ||
Send notices to | (None) |
Network Working Group G. Vaudreuil Request for Comments: 3462 Lucent Technologies Obsoletes: 1892 January 2003 Category: Standards Track The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract The Multipart/Report Multipurpose Internet Mail Extensions (MIME) content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content- type is used to for all kinds of reports. This document is part of a four document set describing the delivery status report service. This collection includes the Simple Mail Transfer Protocol (SMTP) extensions to request delivery status reports, a MIME content for the reporting of delivery reports, an enumeration of extended status codes, and a multipart container for the delivery report, the original message, and a human-friendly summary of the failure. Vaudreuil Standards Track [Page 1] RFC 3462 Multipart/Report January 2003 Table of Contents Document Conventions................................................2 1. The Multipart/Report Content Type................................2 2. The Text/RFC822-Headers..........................................4 3. Security Considerations..........................................4 4. Normative References.............................................5 Appendix A - Changes from RFC 1893..................................6 Author's Address....................................................6 Full Copyright Statement............................................7 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, RFC 2119 [RFC2119]. 1. The Multipart/Report Content Type The Multipart/Report MIME content-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 content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. The Multipart/Report content-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 3 of this memo The syntax of Multipart/Report is identical to the Multipart/Mixed content type defined in [MIME]. When used to send a report, the Multipart/Report content-type must be the top-level MIME content type for any report message. The report-type parameter identifies the type of report. The parameter is the MIME content sub-type of the second body part of the Multipart/Report. User agents and gateways must be able to automatically determine that a message is a mail system report and should be processed as such. Placing the Multipart/Report as the outermost content provides a mechanism whereby an auto-processor may detect through parsing the RFC 822 headers that the message is a report. Vaudreuil Standards Track [Page 2] RFC 3462 Multipart/Report January 2003 The Multipart/Report content-type contains either two or three sub- parts, in the following order: 1) [Required] The first body part contains 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 standards-track content-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.Show full document text