RFC 3462

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

Okay bestie, here's the deets on RFC 3462 🎀. It's a Standards Track doc from the Network Working Group, written by Gregory M. Vaudreuil (G. Vaudreuil) at Lucent Technologies, dated January 2003. It obsoletes RFC 1892 🫶, so 1892 is officially retired and this is the new version. The title block doesn't list anything it updates.

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright Notice 🌈

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

Abstract 🦋

So the Multipart/Report MIME content-type is basically a general "family" or "container" type for email reports of any kind 📦. This memo only defines how to use Multipart/Report for delivery status reports, but mail processing programs will be happier if one content-type handles all kinds of reports.

This document is part of a four document set describing the delivery status report service 💅. The 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.

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 👑

Okay so the Multipart/Report MIME content-type is a general "family" or "container" type for email reports of any kind 💖. Even though this memo only covers delivery status reports, mail processing programs will benefit if a single content-type is used for all kinds of reports. It's giving organization 🧚.

The Multipart/Report content-type is defined like this:

   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 you send a report, the Multipart/Report content-type must be the top-level MIME content type for any report message 🍓. The report-type parameter tells you what kind of report it is. Its value 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 🤖. Putting Multipart/Report as the outermost content gives auto-processors a way to spot that a message is a report just by parsing the RFC 822 headers. Main character energy 🌸.

The Multipart/Report content-type has either two or three sub-parts, in this order:

1. [Required] The first body part is a human readable message 🙈. Its job is to explain in plain language what condition(s) caused the report, for a human who might not have a user agent that can read the second section of the Multipart/Report.

The text in this first section may be in any MIME standards-track content-type, charset, or language 🌍. If you want the error described in several languages or several media, you can use a Multipart/Alternative construct.

This body part can also carry detailed information that doesn't fit neatly into a Message/Report body part 📝.

(2) [Required] This is the machine parsable body part, and it's an account of the reported message handling event 🤖💜. It gives a machine-readable description of the condition(s) that caused the report, plus details that aren't in the first body part but might help human experts. The initial body part, Message/delivery-status, is defined in [DSN].

(3) [Optional] This body part holds the returned message or a portion of it 🔍. It can help human experts diagnose problems. (It might also help the sender figure out which message the report was about, but the envelope-id and original-recipient-address returned in the Message/Report body part are expected to replace the traditional use of returned content for that purpose 🫶.)

Returning content can waste network bandwidth, so there are a few strategies you can use 🦋. Generally, the sender should choose the right strategy and tell the recipient what level of returned content is required. If there's no explicit request for the level of content return, like the one provided in [DRPT], then the agent that generated the delivery service report should return the full message content 💅.

Now, if 8-bit or binary data that isn't encoded in 7 bit form needs to be returned, and the return path isn't guaranteed to handle 8-bit or binary, you have two options 🚦. 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.

2. The Text/RFC822-Headers content-type 🎀

The Text/RFC822-Headers MIME content-type is a way to label and return only the RFC 822 headers of a failed message 📮. These headers are not the complete message, so they should not be returned as a Message/RFC822. They're still super useful for identifying the failed message and for diagnostics based on the received lines.

The Text/RFC822-Headers content-type is defined like this:

   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 that caused the report 🧾. The RFC822 headers are every line before the blank line in the message, and that includes the MIME-Version and MIME Content-Headers 💜.

3. Security Considerations 🔐

Okay, this part is serious, so listen up 🚨. Automated use of report types without authentication opens up several security issues 💀. Forging negative reports gives attackers a shot at denial-of-service attacks when reports are used for automated maintenance of directories or mailing lists. Forging positive reports can make the sender wrongly believe a message was delivered when it wasn't 😭.

A signature covering the entire multipart/report structure could stop these forgeries. But that signature scheme is beyond the scope of this document 🙈.

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.

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

Heads up: the Table of Contents says "Changes from RFC 1893", but the heading here says 1892. Both are kept exactly as written 👀.

Author's Address 💌

   Gregory M. Vaudreuil
   Lucent Technologies
   7291 Williamson Rd
   Dallas Tx, 75214

   Phone: +1 214 823 9325
   EMail: GregV@ieee.org

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. 💜