Mapping between X.400 and RFC-822/MIME Message Bodies
Extracted elements (27)
Gateways are given wide latitude in choosing conversions because both the MIME and X.400 worlds are in a 'stable state of flux' with non-text content. The specification acknowledges that SMTP->X.400->SMTP round-trips may lose information and that different gateways may apply different translations, which is considered unavoidable.
HARPOON encapsulation (rather than BP15 or FTBP) is mandated for multipart/signed because the signature is computed over the encoded body part; HARPOON is the only encapsulation method that preserves the content-transfer-encoding, and all other methods break end-to-end security integrity.
The 'application/x-ftbp.oid' MIME type for FTBP encapsulation uses an unregistered x- prefix because registering a namespace (rather than individual names) is not currently permitted by MIME type registration rules; a specific OID-based name lets MIME readers be configured for each concrete usage without formal registration.
Some implementations use the ASN.1 octet-aligned EXTERNAL encoding choice when the ASN.1 type is OCTET STRING for BP15, rather than the preferred single-ASN1-type choice; gateways must tolerate both, as X.420 still permits generating the octet-aligned form even though single-ASN1-type is the agreed preferred encoding.
The BP15 body part definition is fully compatible with RFC 1494. The multipart-message HEADING-EXTENSION uses id-hex-multipart-message-v2 (not the RFC 1494 version) because the original definition was insufficient for new multipart subtypes (Signed, Related). If both extensions appear on a message, a MIXER gateway should prefer the v2 one.
The IA5Text body part maps to/from text/plain;charset=US-ASCII with no data conversion; the currency symbol at position 2/4 is silently converted to the dollar symbol because the IA5 and ASCII repertoires differ only there and real-world usage invariably intends dollar. Non-standard 8-bit data inside IA5 body parts is addressed by RFC 1428 guidance but is not required for MIXER conformance.
A conformant MIXER gateway MUST be able to be configured for encapsulation when no mapping is known for a body part; the choice between discarding, rejecting, or encapsulating may otherwise be configurable.
A gateway MUST implement encapsulation of multipart/encrypted using HARPOON; any other processing at the gateway raises grave security concerns as it violates the principle of keeping decryption keys close to the user.
A gateway MUST implement encapsulation of multipart/signed using HARPOON, because the signature is computed on the encoded body part and HARPOON is the only encapsulation that preserves the content-transfer-encoding.
A gateway MUST support the encapsulation of message/partial; if it implements transparent reassembly, it MUST support a configurable timeout defaulting back to encapsulation.
In HARPOON encapsulation, all implementations MUST place the MIME-Version: header first in the IA5 body part. Headers placed by MIXER into other parts of the message MUST NOT be placed in the MIME body part.
MIXER conformance requires implementing: FTBP/x400-bp/application/x-ftbp.oid encapsulations, HARPOON for security multiparts, text/plain<->IA5Text, text/plain;charset=iso-8859-*<->GeneralText, multipart/*<->ForwardedIPMessage, message/RFC822<->ForwardedIPMessage, application/octet-stream<->FTBP unknown and BilaterallyDefined, and a configurable choice between the two octet-stream translations.
Normal security precautions MUST be taken when using a Content-Disposition filename on a local filesystem; no special significance is assumed for '/' and '\' characters in the carried pathname.
The registration of an X.400/MIME equivalence MUST supply: the MIME type name (preregistered), X.400 body part, OIDs and ASN.1 syntax if BP15 or FTBP is used, conversion algorithms, and expected effect of 'Conversion prohibited' / 'Conversion with loss prohibited'; the description must permit independent implementation.
When mapping from MIME to X.400, if the IPMS.Body contains multiple body parts and the first IA5 body part starts with 'RFC-822-Headers:' as the first line, a gateway shall check the consistency and syntax of this body part to ensure the resulting message conforms to RFC 822.
The BP15 encapsulating body part (mime-body-part) carries any MIME content in X.400 via an OCTET STRING data field and a MimeParameters structure containing content-type, content-parameters, and other-header-fields. It is fully backward compatible with RFC 1494.
The FTBP encapsulating body part uses application-reference id-mime-ftbp-data; the MIME body's canonical octet stream is placed in FileTransferData.FTdata.value.octet-aligned and all headers including Content-Type are mapped into FTBP ExtensionsField. This mapping is lossless and does not work with multipart types directly.
The MIME type application/x400-bp with parameter 'bp-type=' carries any X.400 body part through MIME. For basic body parts the bp-type is the numeric tag; for Extended Body Parts it is the OBJECT IDENTIFIER from IPMS.body.externally-defined.data.direct-reference. The body is the raw BER encoding of IPM.Body.BodyPart including the initial tag octet.
The multipart-message HEADING-EXTENSION (id-hex-multipart-message-v2) carries a MultipartType with a subtype IA5String and an isAMessage BOOLEAN (DEFAULT TRUE). It is generated for every nested multipart and is needed to allow correct reconstruction of MIME multipart types on the X.400-to-MIME path.
The wanted-MIME-conversion HEADING-EXTENSION (WantedMIMEConversions) carries a SEQUENCE OF X400toMIMEConversion in an X.400 message heading, each specifying an X400Type (standard integer, extended OID, or FTBP OID) and a MIMEType (type string, optional encoding, optional parameters).
The Wanted-X400-Conversion RFC 822 header lets a MIME sender specify an explicit conversion target (bp14/bp15/ftbp/ia5) and optionally the X.400 object identifier or 'tunnel'. When used in a multipart, the 'from mime-type' parameter selects which body part type the conversion applies to, including nested messages.
IANA maintains an Equivalence Registry for X.400/MIME body part mappings. Anyone may register or update an entry; the IESG may lock registrations defined in standards-track documents (including RFC 2157) so that changes require IESG approval. Registration uses the form in Appendix D.
OID subtrees under the mixer OID are assigned: mixer-bp-data { mixer 2 1 } for Extended Body Part data OIDs and mixer-bp-parameter { mixer 2 2 } for parameter OIDs. Specific assignments include id-mime-bp-data (.1), id-mime-bp-parameters (.2), id-mime-postscript-body (.3), id-mime-jpeg-body (.4), id-mime-gif-body (.5 under data, as FTAM ref), and heading extensions id-hex-multipart-message-v2.
Three security issues are identified: (1) filenames arriving in body part headers (section 2.3.2) must be sanitized before use on a local filesystem; (2) gateways handling encrypted or signed content (sections 7.3/7.4) compromise end-to-end security; (3) a gateway fetching message/external-body on behalf of a recipient may be tricked into inappropriate actions by malicious senders.
FTBP body parts encapsulated in MIME use the content-type 'application/x-ftbp.' followed by the dot-notation OID digits from FileTransferParameters.environment.application-reference.registered-identifier. This is an intentionally unregistered x- type; if IANA namespace registration becomes possible the x- prefix may be dropped.
HARPOON encapsulation creates an IA5String body whose first bytes are: 'MIME-Version: <ver>\r\n', 'Content-Type: <type>\r\n', 'Content-Transfer-Encoding: <7bit|qp|base64>\r\n', optional Content headers, '\r\n', then the encoded body bytes. The MIME-Version header must appear first.
MimeParameters ASN.1 SEQUENCE for BP15 contains: content-type (IA5String), content-parameters (SEQUENCE OF SEQUENCE { parameter IA5String, parameter-value IA5String }), and other-header-fields (RFC822FieldList). MIME-Version, Content-Type, and Content-Transfer-Encoding are NOT copied into other-header-fields.