SMTP and MIME Extensions for Content Conversion
Extracted elements (30)
Content-Convert header fields alone serve only as advisory guidance to intermediaries; they do not block delivery on conversion failure. Coupling Content-Convert with CONPERM raises the originator's preference to a requirement enforced by the mail transfer service.
Failure handling is determined solely by the originator's direction (advisory vs. require), not the recipient's. If the originator says 'advise', the original content is delivered even if conversion fails; if 'require', the message is returned without delivery regardless of recipient preference. This preserves the existing email practice of delivering content a recipient might not be able to process.
In direct SMTP mode (originator's system connects directly to recipient's system), CONPERM is unnecessary because the SMTP client already has the originator's permission and the SMTP server directly knows the recipient's capabilities; only CONNEG is needed.
When all SMTP servers along the path support CONPERM but none offer CONNEG, the message is delivered in original form to the recipient. This is acceptable — the recipient then receives the original content together with an explicit list of conversions the originator deems acceptable.
When an intermediary receives capability information for some recipients but not others, those without capability information are treated as if no CONNEG took place — the intermediary MAY split the address list and continue CONPERM forwarding for the uncovered recipients rather than failing them outright.
When CONNEG returns different capabilities for different recipients of the same message, an intermediary MAY either create a single converted copy acceptable to all recipients, or create multiple copies and send each to an appropriate subset of recipients in separate SMTP sessions.
A CONPERM client MUST interact with each next-hop server about: (1) the server's ability to enforce authorized conversions via CONPERM, and (2) the target's capabilities via CONNEG.
Conversion MUST be performed by the first CONPERM intermediary that obtains CONNEG capability information. The MIME Content-Type MUST conform to the result of the converted content as per [MEDTYP].
Each converted MIME body-part MUST have a Content-Previous header field indicating the previous form and a Content-Features header field indicating the new form, as part of the CONNEG processing by a CONPERM-acting client.
If a CONPERM client's next-hop SMTP server does not support CONPERM or CONNEG, the client MUST terminate the session without sending the message and MUST return a DSN to the originator with status code 5.6.3 (Conversion required but not supported).
If a message is protected by strong content authentication or privacy techniques, an intermediary that converts content MUST ensure the results are similarly protected; otherwise it MUST NOT perform conversion.
If the client issues CONNEG with RCPT-TO but the server does not support the CONNEG parameter, the server MUST reject the RCPT-TO addressee with a 504 reply.
If the client specifies CONPERM in MAIL-FROM but the server does not support it, the server MUST reject the MAIL-FROM with a 504-CONPERM reply. If the server accepts CONPERM, it MUST either relay the message under CONPERM or convert the message according to CONNEG information.
If the server issued 250-CONPERM and the client is participating in CONPERM for this message, the client MUST issue the CONPERM parameter in MAIL-FROM. If the server does not issue 250-CONPERM, the client MUST treat the transmission as permanently rejected.
If the server supports CONNEG and knows the capabilities of the target device or system, it MUST provide that information through CONNEG. The capability listing MUST conform to the specifications in [SYN].
The Content-Convert header field MUST be carried unmodified and delivered to the recipient. If it is absent, intermediaries SHOULD NOT perform content conversion. If Content-Convert is present, a Content-Features header field MUST also be present.
When a CONPERM client encounters a next-hop server supporting CONNEG, it MUST request CONNEG information, MUST perform requisite conversions before sending, and MUST fail message processing (returning DSN with status 5.6.5) if any conversion fails.
When an intermediary performs conversion, it MUST record details of the previous representation in a Content-Previous header field and MUST create or revise the Content-Features header field for that MIME body-part to reflect the conversion result.
When performing conversions, the client MUST add a Content-Previous header field and a Content-Features header field (replacing existing ones) to each converted MIME body-part.
The CONNEG ESMTP extension (keyword 'CONNEG') is declared in EHLO and added as a parameter to RCPT-TO. The server responds with a multi-line listing of content capabilities that can be received on behalf of the addressed recipient, formatted per the [SYN] filter syntax.
The CONPERM ESMTP extension (keyword 'CONPERM') is declared in EHLO and added as a parameter to MAIL-FROM. It signals that the originator requires enforcement of authorized content conversions by intermediaries along the transfer path.
The Content-Convert MIME header field specifies permitted conversions for the associated MIME body-part. Its value is 'ANY', 'NONE', or an explicit list of permitted final forms using the [SYN] filter syntax. It may be used independently of the ESMTP extensions.
The Content-Features MIME header field describes the characteristics of the current version of the content in the MIME body-part where it appears. It is updated by each converting intermediary to reflect the new form, replacing any existing Content-Features header.
The Content-Previous MIME header field records, per converted body-part, the previous representation from which conversion was performed. It contains Date (conversion timestamp), By (intermediary domain), and the prior content characteristics in [SYN] filter syntax.
The Content-Convert MIME header field is registered for use with the Mail (RFC 2822) protocol, with status Proposed Standard. The IETF is the change controller and RFC 4141 is the specification document.
The Content-Previous MIME header field is registered for use with the Mail (RFC 2822) protocol, with status Proposed Standard. The IETF is the change controller and RFC 4141 Section 8 is the specification document.
CONNEG discloses recipient content capabilities, but no authentication mechanism for the requestor or respondent is specified. The disclosed information is intended to be safe for public distribution; the disclosing server or client is responsible for determining whether additional security measures are required.
Content conversion by unspecified intermediaries carries significant risk of malicious or damaging transformations. Although CONPERM/CONNEG do not introduce new intermediary capabilities, they may encourage more exploration of conversion potential and increase misbehavior risk. RFC 3238 is cited for broader discussion.
The specification permits potentially unbounded computation by intermediary MTAs for content conversion. This could enable denial-of-service attacks, since Internet mail typically allows intermediaries to receive messages from all Internet sources.
When message content is encrypted, intermediaries cannot perform conversion because they lack the keying material. When content is signed but not encrypted, conversion will invalidate the signature, so intermediaries must not convert without re-signing under the same protections.