PMDF System Manager's Guide

41.4.4 Message Bodies and Attachment Handling

By default, multipart X.400 messages, sometimes referred to as "messages with attachments" will be converted by PMDF-X400 to and from multipart MIME messages in accordance with the recommendations of MIME-MHS, covered by RFCs 2157 (originally 1494), 2156 (originally 1327 and 1495), and 1496:

MIME body parts with a content type of "text/plain" are converted to and from X.400 IA5 or T.61.
Compaq Computer Corporation's registered X.400 body part 15 parts will be transferred to MIME application/vms_rms;mr-type=type-tag parts.
X.400 body parts other than IA5, T.61, ISO6937 (body part 13), forwarded Inter-Personal Messages, or Compaq body part 15's, are placed into MIME body parts with a content type of "application/x400-bp" and a "bp-type" parameter containing the body part context tag value.
MIME representations of "tunnelled" X.400 body parts, i.e., MIME application/x400-bp parts, are transferred back to native X.400 form.
MIME application/vms-rms;mr-type=mr-tag parts are transferred to Compaq Computer Corporation's registered Body Part 15 X.400 parts.
Other MIME encoded body parts that are not supported by X.400 maintain their MIME encoding and are written as X.400 IA5 with MIME content headers included in the IA5 body.

Alternatively, PMDF-X400 can be configured to transfer between MIME parts and a variety of X.400 body parts, including X.400 body part 14, X.400 File Transfer Body Part (FTBP), Compaq body part 15, or Hewlett-Packard body part 15. Section 41.4.4.1 and Section 41.4.4.2 discuss the MIME-TO-X400-CONTENT-TYPES and X400-TO-MIME-CONTENT-TYPES mapping tables used to control general attachment conversions; Section 41.4.4.3 discusses the use of the convert_octet_stream keyword on the MIME_TO_X400 and X400_TO_MIME channels which simply enables basic conversions such as X.400 body part 14 conversion.

41.4.4.1 MIME-TO-X400-CONTENT-TYPES Mapping Table

The MIME-TO-X400-CONTENT-TYPES mapping table is used to control the transfer between variously labelled MIME attachments and X.400 body part 15 or X.400 file transfer body part attachments; this table can also be used to control the transfer between MIME attachments with "generic" application/octet-stream labelling and X.400 body part 14 attachments. Also the MIME-TO-X400-CONTENT-TYPES mapping table can be used to cause additional sorts of MIME attachments to be converted to Compaq body part 15's.

The input to the MIME-TO-X400-CONTENT-TYPES mapping table takes the form channel-name|channel-type|type/subt ype where channel-name is the name of the current channel, e.g., mime_to_x400, and where channel-type is 1992 for 1988 mode MTAs or 1984 for 1984 mode MTAs, and the output of the mapping tells PMDF-X400 what sort of X.400 attachment to construct. To convert to Compaq X.400 body part 15 parts, the right hand side should be of the form DECBP;mrtag or DECBP;number where mrtag is one of the standard Compaq names for attachments types or number is the final number in the OID for that attachment type. A right hand side of MIME specifies "tunnelling" the attachment in as a MIME encoded part inside an X.400 text part, as the standards recommend. A right hand side of BP14 specifies constructing a bilaterally agreed upon, i.e., body part 14, part. A right hand of the form FTBP;oid specifies constructing a file transfer body part of the specified OID; that is, the OID for the application-reference. E.g.,

MIME-TO-X400-CONTENT-TYPES mime_to_x400|1992|APPLICATION/VND.MS-POWERPOINT FTBP;1.2.840.113556.4.5 mime_to_x400|1992|APPLICATION/POSTSCRIPT FTBP;1.3.6.1.7.1.2.1.2 mime_to_x400|1992|APPLICATION/WORDPERFECT5.1 DECBP;WPCORP mime_to_x400|1992|APPLICATION/MSWORD DECBP;WINWORD6 mime_to_x400|1984|APPLICATION/VND.MS-POWERPOINT BP14 mime_to_x400|1984|APPLICATION/WORDPERFECT5.1 BP14 mime_to_x400|1984|APPLICATION/MSWORD BP14

tells PMDF-X400 to send Wordperfect and Microsoft Word parts in Compaq body part 15 parts when sending out the mime_to_x400 channel to any remote MTA that operates in 1988 mode (as specified in an MTAID database), and to send Powerpoint parts in file transfer body parts when sending to any remote MTA that operates in 1988 mode, but to send such parts in body part 14 parts when sending out to any remote MTA that operates in 1984 mode.

More extensive examples can be found in the file x400_mappings.sample in the PMDF table directory.

41.4.4.2 X400-TO-MIME-CONTENT-TYPES Mapping Table

The X400-TO-MIME-CONTENT-TYPES mapping table is used to control the transfer between X.400 body parts and variously labelled MIME attachments. For each X.400 part, an initial probe of the X400-TO-MIME-CONTENT-TYPES mapping table is made to determine whether any further conversion of the part should be performed. If the initial probe is successful, then a second probe is performed to determine what sort of MIME part to convert to. Specifying the convert_octet_stream keyword on the X400_TO_MIME channel makes the first probe unnecessary---even without a first entry, the later, type-specific conversion will be performed. But specific initial entries in X400-TO-MIME-CONTENT-TYPES override any convert_octet_stream setting.

The format of the first probe of the X400-TO-MIME-CONTENT-TYPES mapping table takes the form DECBP for Compaq body part 15's, HPBP for Hewlett-Packard body part 15's, FTBP for file transfer body parts, or BP14 for body part 14's. To enable further conversion (in particular, a second probe), the mapping entry must return Yes. For body part 14 parts, there is only the first probe; if it is successful, the body part 14 parts are transferred to MIME application/octet-stream parts.

The format of the second probe of the X400-TO-MIME-CONTENT-TYPES mapping table takes different forms, depending on whether the X.400 part is an X.400 file transfer body part, an X.400 Compaq body part 15, or an X.400 HP body part 15. For Compaq body part 15 parts, the form is DECBP;mrtag or DECBP;number where mrtag is one of the standard Compaq names for attachments types or number is the final number in the OID for that attachment type. (The table is probed first using a Compaq name probe and only if that fails is a number probe made.) For HP body part 15 parts, the form is HPBP;number where number is the final number in the OID for that attachment type. For X.400 file transfer body parts, the probe takes the form FTBP;oid where oid is the OID for the part in question. For instance,

X400-TO-MIME-CONTENT-TYPES BP14 Yes DECBP Yes HPBP Yes FTBP Yes DECBP;WPCORP APPLICATION/WORDPERFECT5.1 DECBP;WINWORD6 APPLICATION/MSWORD FTBP;1.2.840.113556.4.5 APPLICATION/VND.MS-POWERPOINT FTBP;1.3.6.1.7.1.2.1.2 APPLICATION/POSTSCRIPT

If the initial probe of X400-TO-MIME-CONTENT-TYPES for FTBP succeeds, but the second probe with a specific OID does not succeed, then the file transfer body part will be transferred to a MIME application/octet-stream; application-reference=oid part.

More extensive examples can be found in the file x400_mappings.sample in the PMDF table directory.

41.4.4.3 The `convert_octet_stream` keyword's effect

The convert_octet_stream channel keyword can be used on the MIME_TO_X400 and X400_TO_MIME channel definitions (usually located in the x400.chans file in the PMDF table directory) to cause PMDF-X400 to transfer pure binary data between MIME "application/octet-stream" and X.400 body part 14. Note that a general convert_octet_stream setting can be overriden using the more specific MIME-TO-X400-CONTENT-TYPES and X400-TO-MIME-CONTENT-TYPES mapping described above in Section 41.4.4.2 and Section 41.4.4.1.

For more information on the convert_octet_stream keyword, see 2.3.4.53.

When using convert_octet_stream behavior, note that convert_octet_stream converts to X.400 body part 14 format only those MIME attachments labelled as "application/octet-stream", which is the MIME labelling for "generic binary data"; (converting any other sort of MIME attachment to an X.400 body part 14 would mean losing the more specific MIME labelling since X.400 body part 14 format does not have corresponding labelling). However, it is sometimes desirable to convert even any MIME attachments with specific labelling to X.400 body part 14 format. This is achieved by "downgrading" the MIME labelling on attachments going to an X.400 channel; see Section 6.1.2.2 for an example.

41.4.5 Notification Messages

PMDF-X400 supports transferring delivery receipt requests and reports and read receipt requests and reports between X.400 and the Internet, to the extent possible.

41.4.5.1 Delivery Receipts

The reportheader, reportnotary, reportboth, and reportsuppress channel keywords control PMDF-X400's use of delivery receipt request mechanisms and the format of delivery receipt messages. The current default is reportheader, meaning that PMDF-X400 will convert between X.400 delivery receipt requests and ad-hoc header delivery receipt requests, and will pass Internet DSNs through to X.400 as X.400 messages rather than as X.400 reports. The use of the recommended reportnotary keyword causes PMDF-X400 when operating in 1988 mode to convert between X.400 delivery receipt requests and standard Internet RFC 1891 (NOTARY) delivery receipt requests, and to pass Internet DNSs through to X.400 as X.400 Reports, when possible. This is discussed in more detail below.

PMDF-X400 will convert X.400 delivery receipt requests into Internet delivery receipt requests. In 1984 mode, the conversion will be into a header style delivery receipt request. In 1988 mode, the conversion will again by default be into a header style delivery receipt request, but use of the (recommended) reportnotary channel keyword on the mime_to_x400 channel will cause PMDF-X400 to convert the requests into RFC 1891 (NOTARY) delivery receipt requests.

PMDF-X400 will convert Internet delivery receipt requests into X.400 delivery receipt requests. By default, PMDF-X400 will look for header style Internet delivery receipt requests when determining whether to generate an X.400 delivery receipt request. But use of the (recommended) reportnotary channel keyword on the mime_to_x400 channel will cause PMDF-X400 to instead convert RFC 1891 (NOTARY) delivery receipt requests.

PMDF-X400 will convert X.400 Non Delivery Reports and Delivery Reports into structured RFC 1891 Delivery Status Notification messages.

In 1984 mode, and by default in 1988 mode, PMDF-X400 will convert structured RFC 1891 Delivery Status Notification messages into normal X.400 messages. But in 1988 mode, use of the (recommended) reportnotary channel keyword on the mime_to_x400 channel will cause PMDF-X400 to instead attempt to convert structured RFC 1891 Delivery Status Notification messages into X.400 Reports; some DSNs, however, can contain information that cannot be converted and in this case the DSNs will be converted to normal X.400 messages, rather than to X.400 Reports.

41.4.5.2 Read Receipts

PMDF-X400 will convert X.400 read receipt requests into RFC 2298 read receipt requests (Disposition-notification-to: headers) and vice versa. Be aware, however, that the design of read receipt requests in X.400 has fundamental restrictions and limitations that mean that often read receipt requests can not work in an X.400 environment; these restrictions and limitations are not PMDF-X400 limitations, but rather are inherent in X.400 read receipt design. Specifically, for X.400 read receipt requests, envelope and headers forms of an address have to "match"; however, such matching can routinely fail in any but the most simple addressing schemes and sites running PMDF-X400 are almost by definition likely to be encountering more complex addressing issues than X.400 read receipt design can encompass. Note that there are some X.400-1988 extensions to try to work around some of the X.400 read receipt problems and PMDF-X400 supports these extensions, so chances of read receipt request success are improved if all X.400 MTAs that handle a message are X.400-1988 MTAs.

PMDF-X400 will convert X.400 IPNs (read receipts) into RFC 822 messages.

Contents

Index