RFC 1892

Network Working Group · RFC 1892 · Category: Standards Track · January 1996

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

Okay bestie, the title block tells us everything we need 🎀 This is RFC 1892 from the Network Working Group, written by Gregory M. Vaudreuil of Octel Network Services. It's a Standards Track doc, dated January 1996. It doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC 🌸

---

Status of This Memo ✨

So this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🗣️ For the current 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 🌈

1. The Multipart/Report MIME content-type 🎀

Multipart/Report is the general "family" or "container" type for email reports of any kind 📦 This memo only defines how it's used for delivery status reports, but mail processing programs benefit when one content-type covers all kinds of reports, so it's lowkey the smart move 🧠

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 4 of this memo.

The syntax of Multipart/Report is identical to the Multipart/Mixed content type from [MIME] 🧩 When it's used to send a report, Multipart/Report must be the top-level MIME content type for any report message 👑 The report-type parameter identifies the type of report. 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. 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. 🔥

The Multipart/Report content-type contains either two or three sub-parts, in the following order:

(1) [required] The first body part is the human readable message 🙋‍♀️ Its purpose is to give an easy-to-understand description of the condition(s) that caused the report to be generated, for a human reader who might not have a user agent that can interpret 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 🌍 If you want the error described 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 can't be easily formatted into a Message/Report body part 📝

(2) [required] This is the machine parsable body part 🤖 It contains an account of the reported message handling event. Its purpose is a machine-readable description of the condition(s) that caused the report to be generated, plus details not in the first body part that might 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 of it 📨 This can help human experts diagnose problems 🔍 (Sure, it could also help the sender figure out which message the report was issued for, but the hope is that the envelope-id and original-recipient-address returned in the Message/Report body part will take over that job from the returned content 🙈)

Returning content can 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 level of returned content that's needed. Without an explicit request for a level of returned content, like the one provided in [DRPT], the agent that generated the delivery service report should return the full message content 💅

When data not encoded in 7 bits is to be returned, and the return path isn't guaranteed to be 8-bit capable, there are two options 🎀 The original message MAY be reencoded 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 MIME content-type 🦋

Text/RFC822-Headers gives us a way to label and return only the RFC 822 headers of a failed message 💌 These headers aren't the complete message, so they should not be returned as a Message/RFC822 🙅‍♀️ The returned headers are 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, they may be encoded in quoted-printable.
Security considerations: see section 4 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 include all lines prior to the blank line in the message 💜 They include the MIME-Version and MIME Content- headers ✨

3. References 📚

• [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, University of Tennessee, Octel Network Services, January 1996.
• [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
• [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
• [DRPT] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, University of Tennessee, January 1996.

4. Security Considerations 😭

Okay, this section is seriously important, bestie 🚨

Automated use of report types without authentication presents several security issues 🚨 Forging negative reports creates an opening 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 wrongly believe a message was delivered when it actually wasn't 😱

5. Author's Address 🖋️

Gregory M. Vaudreuil
Octel Network Services
17060 Dallas Parkway
Dallas, TX 75248-1905

Phone: +1-214-733-2722
EMail: Greg.Vaudreuil@Octel.com