Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3462

The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages

Pages: 7
Obsoletes:  1892
Obsoleted by:  6522
Updated by:  5337

ToP   noToC   RFC3462 - Page 1
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.
ToP   noToC   RFC3462 - Page 2

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.
ToP   noToC   RFC3462 - Page 3
   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.

   This body part may also be used to send detailed information that
   cannot be easily formatted into a Message/Report 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].

   (3) [Optional] A body part containing the returned message or a
   portion thereof.  This information may be useful to aid human experts
   in diagnosing problems.  (Although it may also be useful to allow the
   sender to identify the message 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 [DRPT], 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
   content-type MAY be used to return only the original message headers.
ToP   noToC   RFC3462 - Page 4

2. The Text/RFC822-Headers content-type

The Text/RFC822-Headers MIME content-type provides a mechanism to label and return only the RFC 822 headers of a failed message. These headers are not the complete message and should not be returned as a Message/RFC822. The returned headers are useful for identifying the failed message and for diagnostics based on the received lines. The Text/RFC822-Headers content-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 RFC822 headers, however, if the headers are broken and require encoding to make them legal 7 bit content, they may be encoded in quoted-printable. Security considerations: See section 3 of this memo. The Text/RFC822-Headers body part should contain all the RFC822 header lines from the message which caused the report. The RFC822 headers include all lines prior to the blank line in the message. They include the MIME-Version and MIME Content-Headers.

3. 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.
ToP   noToC   RFC3462 - Page 5

4. Normative References

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 3461, January 2003. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
ToP   noToC   RFC3462 - Page 6

Appendix A - Changes from RFC 1892

Changed Authors contact information Updated required standards boilerplate Edited the text to make it spell-checker and grammar checker compliant

Author's Address

Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas Tx, 75214 Phone: +1 214 823 9325 EMail: GregV@ieee.org
ToP   noToC   RFC3462 - Page 7
Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.