Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
updated by
- rfc-5621 — Message Body Handling in the Session Initiation Protocol (SIP)
updates
- rfc-3204 — MIME media types for ISUP and QSIG Objects
Extracted elements (28)
By marking the encryption control object OPTIONAL, the sending user explicitly grants permission for the gateway to decrypt and forward cleartext. Because the default is REQUIRED, a sending UA that takes no explicit action causes gateways to assume end-to-end encryption is required.
Critical content processing is explicitly scoped as a content gateway function, not an MTA or UA function. This insight (attributed to Greg White) clarifies that the mechanism is about what gateways should do when bridging networks of differing capability, not about enforcing delivery at every hop.
The default value for Handling is REQUIRED so that existing notification mechanisms work correctly for sending agents that are unaware of critical content processing. All body parts default to critical, ensuring messages are not silently degraded by ignorant agents.
The Handling parameter was implemented as a Content-Disposition parameter rather than a new MIME entity because IMAP servers would need to extend BODYSTRUCTURE or add new retrieval methods to expose a standalone Critical-Content MIME entity, an approach that had already proved difficult with Content-Location.
The word REQUIRED in this document does not follow the RFC 2119 definition because REQUIRED is the name of a parameter value, not a requirement keyword. There are no RFC 2119 REQUIRED-level requirements in this document, avoiding ambiguity.
Criticality indicators affect only the outermost level of the message (or the outermost level of the selected multipart/alternative). Receiving systems MUST ignore criticality indicators in embedded body parts (e.g., inside a message/rfc822 enclosure) to prevent forwarded messages from triggering undesired reporting.
DSN generation requires ESMTP. If MTAs in the path do not support ESMTP, the DSN request will be rejected and the message defaults to notification on delay or failure. This is a backward-compatibility limitation when using critical content with non-ESMTP paths.
For SIP, all requests already have notification via response status codes; RFC 3204 specifies that a content gateway generates a 415 (Unsupported Media Type) response when a REQUIRED body part cannot be delivered. The DSN/MDN notification table in Section 5.2 is informative for SIP.
The Handling parameter is fully backward compatible: Content-Disposition-compliant user agents that do not recognize the parameter will ignore it, and the default REQUIRED value means that unknown-to-gateway body parts are treated as critical, preserving prior behavior.
If a critical content indicator is on the signature object and the content does not pass verification, the gateway MUST reject the message.
If a multipart/alternative's selected alternative has HANDLING=OPTIONAL, the content gateway MUST NOT generate any delivery notifications, explicitly overriding DSN and MDN request mechanisms.
If a sending UA wishes to allow gateway decryption of encrypted content, the sending UA MUST mark the encrypted content as not REQUIRED; otherwise the gateway will treat unmarked encrypted content as REQUIRED.
If the content gateway cannot pass a body part marked OPTIONAL, the receiving system MUST NOT return a delivery failure unless parts marked REQUIRED have also failed.
If the content gateway cannot pass an OPTIONAL body part, the gateway MUST NOT generate a notification; the gateway treats the message as if the body part was not present.
If the encrypted control object is marked REQUIRED and the endpoint cannot decrypt the message, then the gateway MUST reject the message, enforcing end-to-end encryption.
If the sending UA marks the multipart/signed enclosure REQUIRED and the endpoint cannot perform MIME signature verification, the gateway MUST reject the message.
If the value of the Handling field is OPTIONAL, the content gateway MUST NOT generate a delivery notification. If REQUIRED and a notification was requested, the content gateway MUST generate a notification for the whole message on failure.
The content gateway MUST treat unrecognized Handling values as REQUIRED, providing backward compatibility with future extensions of the Content-Criticality entity.
The gateway MUST honor signature processing: if the sending UA marks signature components REQUIRED and the endpoint cannot do MIME signature processing, the gateway MUST establish an appropriate signature mechanism between gateway and endpoint.
DSN generation is preferred over MDN: a content gateway operating as an MTA generates DSNs; one operating as a mail user agent generates MDNs. For SIP endpoints, the appropriate success or error response code serves as notification.
The content gateway role is defined as a gateway connecting a first network to a second network of lesser capability. It may be integrated with the receiving UA, positioned between MTAs, or operate as a post-processing disaggregated step after the final MTA has accepted the message.
The Handling parameter is a Content-Disposition parameter inserted by the sending agent to indicate whether a body part is critical. Defined values are REQUIRED (sender requires delivery) and OPTIONAL (sender does not care about delivery). This parameter is not case sensitive per RFC 2183.
IANA registration for the Content-Disposition parameter HANDLING, originally registered by RFC 3204 and updated here as the normative reference. Allowable values are REQUIRED and OPTIONAL; both the parameter name and values are case-insensitive.
A content gateway that verifies or strips signatures on behalf of endpoints becomes a target for tampering. When the gateway establishes a signature mechanism between itself and the endpoint, the gateway must be secured, as it holds responsibility for signed component integrity.
Receiving systems and users MUST NOT place any authentication value on the Handling parameter, as it can be modified in transit. The parameter conveys the sender's intent about delivery criticality, not authenticated identity or authorization.
Sending UAs can use digital signatures over critical content indicators to ensure the integrity of the Handling parameter. Gateways must honor this: if signature components are marked REQUIRED and the endpoint cannot verify them, the gateway must establish an appropriate signature mechanism or reject the message.
Content gateway behavior follows a two-axis decision table: body part marked REQUIRED × deliverable → take appropriate action (DSN/MDN if requested); REQUIRED × undeliverable → fail entire message; OPTIONAL × deliverable → ignore; OPTIONAL × undeliverable → ignore (no notification).
The Handling parameter syntax in ABNF: `"handling" "=" notification-type CRLF` where `notification-type = "REQUIRED" / "OPTIONAL" / other-handling / generic-param` and `other-handling = token`. Both the parameter name and values are case-insensitive.