Summary

  • RFC 3462 made multipart/report an outermost MIME container with two required, ordered parts: an explanation for people and a typed record for machines. A third part could return the original message or only a useful portion.
  • The envelope made reports recognizable, not trustworthy. Software could identify the second part from report-type, yet a forged report could still mislead a reader or trigger destructive automation.

A report needed two readers at once

Mail failure was an awkward object. A person wanted an intelligible account: which address failed, what might be corrected, and whether another attempt made sense. Software wanted stable fields whose meanings did not shift with language or phrasing. Putting machine data into prose made automation brittle. Showing only machine fields made the report needlessly hostile to the sender.

RFC 3462, published in January 2003, solved the packaging problem rather than the delivery problem. Its plain-text form, RFC Editor record, Datatracker entry, document history, references, later citations and errata search anchor the record. It obsoleted RFC 1892 while preserving the central idea: one MIME structure could serve human inspection and automatic handling without confusing their evidence roles.

The Content-Type had to be multipart/report, and it had to be the outermost MIME type of the message. Like other multipart types under RFC 2046, it required a boundary. It also required report-type, whose value named the MIME subtype of the second body part. That linkage meant a processor could inspect the outer header and know what machine record it should expect before parsing the entire body.

Order was part of the meaning

The container held two or three parts in a fixed sequence. The first was required and intended for a human. It could use any standards-track MIME type and an appropriate charset or language; multipart/alternative could offer several presentations. The freedom was deliberate. Human explanation depends on audience, language and diagnostic judgment.

The second part was also required, but it was for software. It described a message-handling event in a registered media type. In a delivery-status notification, RFC 3464 used message/delivery-status. The generic container did not define those fields or promise delivery semantics itself. RFC 3461 governed SMTP requests for notifications, while RFC 3463 supplied enhanced status codes. The distinction matters: RFC 3462 says where the machine evidence goes and how it is identified, not whether a particular receipt should exist.

The third part was optional. It returned the original message or a portion useful for diagnosis and correlation. Returning everything was the recommended default when the sender had not requested a return level, but it could waste bandwidth or expose content unnecessarily. If an uncertain path could not safely carry 8-bit or binary material, the generator could encode the original into legal 7-bit MIME or return only text/rfc822-headers. Those headers, defined against the message tradition of RFC 822, were not a complete message and could not honestly be labeled message/rfc822.

This three-way separation created a small evidence discipline. The first part could explain; the second could be parsed; the third could supply context. None substituted for the others. A polished sentence was not a status field. A status field was not the original message. A header-only return was not the complete object it described.

Recognition did not confer authenticity

Outermost placement made detection efficient. A mail agent could recognize a report from the Content-Type header and route it to suitable handling. The IANA media-type registry gave the subtype family a shared public namespace. Later report formats reused the structure: message disposition notifications were first specified in RFC 3798 and later revised by RFC 8098; internationalized delivery status appeared in RFC 6533.

But RFC 3462 explicitly warned that the container did not authenticate its contents. A forged negative report could cause an automated mailing-list or directory manager to remove a valid address, turning convenient cleanup into denial of service. A forged positive report could encourage a false belief that delivery succeeded. A signature covering the complete multipart/report structure could reduce that risk, but the standard left such authentication outside its scope.

That limit is more important than it looks. Syntax can prove that bytes fit a grammar. It cannot prove who produced them, whether the described event occurred, or whether a human saw the returned explanation. Automation that collapses those layers converts a parse result into operational authority.

Heng Lu's later reality-layer discipline helps name the separation: a formatted claim, a parser's interpretation, a mail system's event and an operator's consequential action are different receipts. His argument for running-code primacy directs scrutiny toward the actual MIME tree, the generator, the verifier and the automation that consumes the result. These are later editorial lenses, not evidence of the RFC authors' private intent.

RFC 3462's achievement was modest and durable. It placed an explanation, a machine record and optional returned material in one envelope while refusing to merge their meanings. The form made coordinated handling possible. Trust still had to come from somewhere else.

Sources