Summary

  • RFC 3459 attached Handling=REQUIRED|OPTIONAL to individual MIME body parts: inability to pass a REQUIRED part failed the entire message, while an OPTIONAL part could disappear silently without making delivery fail.
  • Missing and unknown values defaulted to REQUIRED, while marker placement on signed or encrypted wrappers, control objects and payloads decided whether a gateway could transform the protected content or had to reject it.

Partial delivery needed a sender-side contract

General Internet mail expected a MIME-capable receiver to retain or expose every body part even when it lacked the right renderer. A voice-messaging system could have a narrower reality: it might store audio and fax but not a word-processing attachment or video. A content gateway therefore knew the endpoint's capabilities and sometimes removed what the endpoint could not accept.

RFC 3459, published in January 2003, made that transformation explicit. The plain text, RFC Editor record, Datatracker file, history, references, later citations and errata search bound the standards record. The mechanism updated RFC 3204 by separating its Handling parameter from ISUP/QSIG transport.

Placed on a Content-Disposition parameter, REQUIRED meant that the sender would not count the message as delivered if that part could not pass. Failure of one such part failed the entire message. OPTIONAL meant the gateway could silently delete the part and must not issue a delivery failure unless a REQUIRED part also failed.

The terms did not rank emotional or business importance. They allocated transformation authority and failure consequences. A user agent might have inserted a hidden auxiliary part without the sender noticing; marking it optional could keep an incapable voice system from rejecting useful audio because of an attachment the sender did not care about.

Silence, failure and notification were separate decisions

The default was deliberately conservative. An unmarked part was REQUIRED. An unrecognized future value also had to be treated as REQUIRED. Old gateways could ignore an unknown Content-Disposition parameter under the existing MIME rules, while new gateways failed closed rather than silently discarding content whose new semantics they did not understand. RFC 2045 supplied the MIME foundation, and RFC 2421 shows the voice-messaging profile context that motivated constrained receivers.

Criticality itself did not request a receipt. SMTP delivery notifications still followed RFC 3461; message disposition notifications followed RFC 3798; an inability to store or render a type could use the 5.6.1 code from RFC 3463. A gateway acting before final delivery could generate a DSN. A component acting after delivery as a user agent could generate an MDN. SIP returned a status response, including 415 in the RFC 3204 case. Topology and role determined the receipt; the REQUIRED label alone did not.

Cryptographic wrappers made location part of the policy

The most consequential rules involved multipart security from RFC 1847. Marking a multipart/signed enclosure REQUIRED demanded intact passage and true end-to-end verification; an endpoint unable to verify forced rejection. Marking the signature control object REQUIRED let a capable gateway verify before forwarding, but failed verification still forced rejection. If the signature data was OPTIONAL while the enclosed material was REQUIRED, the gateway could strip signature information for an incapable endpoint, although verification and tamper indication remained strongly recommended. RFC 2480 supplied related disposition guidance.

Encryption exposed the same jurisdiction more sharply. A REQUIRED encryption control object demanded end-to-end encryption. If it was OPTIONAL, an authorized capable gateway could decrypt and forward cleartext to an endpoint that could not decrypt. That permission existed only because the sender placed the marker there. A marker hidden inside encrypted data was difficult for a gateway to discover without decrypting first, so unmarked encrypted material remained REQUIRED by default.

These were not generic promises that gateways were trustworthy. They were rules for what a conforming gateway could do after it knew both the message structure and receiver capability. The OPES discussion in RFC 3238 provided a wider accountability backdrop: transformation needed consent, notification semantics and non-blocking behavior rather than invisible modification.

Heng Lu's later reality-layer discipline helps distinguish four receipts: the sender's mark, the gateway's capability claim, the transformation actually performed and the result returned. Running-code primacy directs attention to the MIME tree before and after the gateway, not to a reassuring label. These are later editorial lenses, not evidence of the RFC author's private intent.

RFC 3459 turned partial delivery from an invisible accident into an explicit allocation of consequence. An optional part could vanish and delivery could still succeed. A required part could be tiny, yet its loss invalidated the whole message.

Sources