PMDF System Manager's Guide
PMDF-REF-6.0

Previous | Contents

6.1.2 Message reformatting

As described above, the CHARSET-CONVERSION mapping is also used to effect the conversion of attachments between MIME and several proprietary mail formats. Use of the Pathworks Mail conversion is described in Section 19.3 .

The following sections give examples of some of the other sorts of message reformatting which can be affected with the CHARSET-CONVERSION mapping.

6.1.2.1 Non-MIME binary attachment conversion

Mail from the Microsoft Mail (MSMAIL) SMTP gateway is automatically converted into MIME format if CHARSET-CONVERSION is enabled for any of the channels involved in handling the message. If you have a tcp_local channel then it is the incoming channel for messages from a Microsoft Mail SMTP gateway, and the following will enable the conversion of messages delivered to your local users: 
CHARSET-CONVERSION 
 
  IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT         Yes
You may also wish to add entries for channels to other local mail systems. For instance, an entry for the mr_local channel:³ 
CHARSET-CONVERSION 
 
  IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT         Yes 
  IN-CHAN=tcp_local;OUT-CHAN=mr_local;CONVERT  Yes
Alternatively, to cover every channel you can simply specify OUT-CHAN=* instead of OUT-CHAN=l. However, this may bring about an increase in message processing overhead as all messages coming in the tcp_local channel will now be scrutinized instead of just those bound to specific channels.4

To convert MIME into the format Microsoft Mail SMTP gateway understands, use a separate channel in your PMDF configuration for the Microsoft Mail SMTP gateway, e.g., tcp_msmail, and put the following in the mappings. file: 

CHARSET-CONVERSION 
 
  IN-CHAN=*;OUT-CHAN=tcp_msmail;CONVERT        RFC1154

6.1.2.2 Relabelling MIME headers

Some user agents or gateways may emit messages with MIME headers which are less informative than they might be, but which nevertheless contain enough information to construct more precise MIME headers. Although the best solution is to properly configure such user agents or gateways, if they are not under your control, you can instead ask PMDF to try to reconstruct more useful MIME headers.

If the first probe of the CHARSET-CONVERSION mapping table yields a "Yes" or "Always" keyword, then PMDF will check for the presence of a conversions file, (named by the logical PMDF_CONVERSION_FILE on OpenVMS or the PMDF_CONVERSION_FILE option in the PMDF tailor file on UNIX, hence usually PMDF_TABLE:conversions. on OpenVMS, or /pmdf/table/conversions on UNIX, or C:\pmdf\table\conversions on NT). If a conversions file exists, then PMDF will look in it for an entry with RELABEL=1 and if it finds such an entry, PMDF will then perform any MIME relabellings specified in the entry. See Section 6.2.3 for complete information on PMDF conversions file entries.

For instance, the combination of a CHARSET-CONVERSION table such as 

CHARSET-CONVERSION 
 
   IN-CHAN=tcp_local;OUT-CHAN=mr_local;CONVERT            Yes
and PMDF conversions file entries of 
out-chan=mr_local; in-type=application; in-subtype=octet-stream; 
 in-parameter-name-0=name; in-parameter-value-0=*.ps; 
 out-type=application; out-subtype=postscript; relabel=1 
 
out-chan=mr_local; in-type=application; in-subtype=octet-stream; 
 in-parameter-name-0=name; in-parameter-value-0=*.msw; 
 out-type=application; out-subtype=msword; relabel=1
will result in messages that arrive on the tcp_local channel and are routed to the mr_local channel, and that arrive originally with MIME labelling of application/octet-stream but have a filename parameter with the extension ps or msw, being relabelled as application/postscript or application/msword, respectively. (Note that this more precise labelling is what the original user agent or gateway should have performed itself.) Such a relabelling can be particularly useful in conjunction with a MIME-CONTENT-TYPES-TO-MR mapping table, used to convert such resulting MIME types back into appropriate MRTYPE tags, which needs precise MIME labelling in order to function optimally; if all content types were left labelled only as application/octet-stream, the MIME-CONTENT-TYPES-TO-MR mapping table could only, at best, unconditionally convert all such to one sort of MRTYPE.

With the above example and MIME-CONTENT-TYPES-TO-MR mapping table entries including 

APPLICATION/POSTSCRIPT            PS 
APPLICATION/MSWORD                MW
a labelling coming in as, e.g., 
Content-type: application/octet-stream; name=stuff.ps
would be relabelled as 
Content-type: application/postscript
and then converted into an MRTYPE tag PS to let Message Router know to expect PostScript.

Sometimes it is useful to do relabelling in the opposite sort of direction, "downgrading" specific MIME attachment labelling to application/octet-stream, the label for generic binary data. In particular, "downgrading" specific MIME labelling is often used in conjunction with the convert_octet_stream channel keyword on the mime_to_x400 channel (PMDF-X400) or xapi_local channel (PMDF-MB400) to force all binary MIME attachments to be converted to X.400 bodypart 14 format.

For instance, the combination of a CHARSET-CONVERSION mapping table such as 

CHARSET-CONVERSION 
 
   IN-CHAN=*;OUT-CHAN=mime_to_x400*;CONVERT      Yes
and PMDF conversions file entries of 
out-chan=mime_to_x400*; in-type=application; in-subtype=*; 
  out-type=application; out-subtype=octet-stream; relabel=1 
 
out-chan=mime_to_x400*; in-type=audio; in-subtype=*; 
  out-type=application; out-subtype=octet-stream; relabel=1 
 
out-chan=mime_to_x400*; in-type=image; in-subtype=*; 
  out-type=application; out-subtype=octet-stream; relabel=1 
 
out-chan=mime_to_x400*; in-type=video; in-subtype=*; 
  out-type=application; out-subtype=octet-stream; relabel=1
will result in downgrading various specific MIME attachment labelling to the generic application/octet-stream labelling (so that convert_octet_stream will apply) for all messages going to mime_to_x400* channels.

6.1.2.3 MacMIME format conversions

Macintosh files have two parts, a resource fork which contains Macintosh specific information, and a data fork which contains data usable on other platforms. This introduces an additional complexity when transporting Macintosh files, as there are four different formats in common use for transporting the Macintosh file parts.5 Three of the formats, Applesingle, Binhex, and Macbinary, consist of the Macintosh resource fork and Macintosh data fork encoded together in one piece. The fourth format, Appledouble, is a multipart format with the resource fork and data fork in separate parts. Appledouble is hence the format most likely to be useful on non-Macintosh platforms, as in this case the resource fork part may be ignored and the data fork part is available for use by non-Macintosh applications. But the other formats may be useful when sending specifically to Macintoshes.

PMDF can convert between these various Macintosh formats. The CHARSET-CONVERSION keywords Appledouble, Applesingle, Binhex, or Macbinary tell PMDF to convert other MacMIME structured parts to a MIME structure of multipart/appledouble, application/applefile, application/mac-binhex40, or application/macbinary, respectively. Further the Binhex or Macbinary keywords also request conversion to the specified format of non-MacMIME format parts that do nevertheless contain X-MAC-TYPE and X-MAC-CREATOR parameters on the MIME Content-type: header. The CHARSET-CONVERSION keyword Block tells PMDF to extract just the data fork from MacMIME format parts, discarding the resource fork; (since this loses information, use of Appledouble instead is generally preferable).

For instance, the following CHARSET-CONVERSION table would tell PMDF to convert to Appledouble format when delivering to the VMS MAIL mailbox or a GroupWise postoffice, and to convert to Macbinary format when delivering to the Message Router channel: 

 
CHARSET-CONVERSION 
 
  IN-CHAN=*;OUT-CHAN=l;CONVERT           Appledouble 
  IN-CHAN=*;OUT-CHAN=wpo_local;CONVERT   Appledouble 
  IN-CHAN=*;OUT-CHAN=mr_local;CONVERT    Macbinary
The conversion to Appledouble format would only be applied to parts already in one of the MacMIME formats. The conversion to Macbinary format would only be applied to parts already in one of the MacMIME formats, or non-MacMIME parts which included X-MAC-TYPE and X-MAC-CREATOR parameters on the MIME Content-type: header.

When doing conversion to Appledouble or Block format, the MAC-TO-MIME-CONTENT-TYPES mapping table may be used to indicate what specific MIME label to put on the data fork of the Appledouble part, or the Block part, depending on what the Macintosh creator and Macintosh type information in the original Macintosh file were. Probes for this table have the form format|type|creator|filename where format is one of SINGLE, BINHEX or MACBINARY, where type and creator are the Macintosh type and Macintosh creator information in hex, respectively, and where filename is the file name. For instance, to convert to Appledouble when sending to the l channel and when doing so to use specific MIME labels for any MS Word or PostScript documents converted from MACBINARY or BINHEX parts, appropriate tables might be: 

CHARSET-CONVERSION 
 
  IN-CHAN=*;OUT-CHAN=l;CONVERT     Appledouble 
 
MAC-TO-MIME-CONTENT-TYPES 
 
! PostScript 
   MACBINARY|45505346|76677264|*     APPLICATION/POSTSCRIPT$Y 
   BINHEX|45505346|76677264|*        APPLICATION/POSTSCRIPT$Y 
! Microsoft Word 
   MACBINARY|5744424E|4D535744|*     APPLICATION/MSWORD$Y 
   BINHEX|5744424E|4D535744|*        APPLICATION/MSWORD$Y
Note that the template (right hand side) of the mapping entry must have the $Y flag set in order for the specified labelling to be performed. Sample entries for additional types of attachments may be found in the file mac_mappings.sample in the PMDF table directory.

If you wish to convert non-MacMIME format parts to Binhex or Macbinary format, such parts need to have X-MAC-TYPE and X-MAC-CREATOR MIME Content-type: parameter values provided. Note that MIME relabelling can be used to force such parameters onto parts that would not otherwise have them; see Section 6.1.2.2 for a discussion of MIME relabelling.

Note

³ There is no need to make entries for cc:Mail or Novell MHS channels as they will automatically perform the necessary conversions.

4 More importantly, such undiscriminated conversions may place your system in the dubious and frowned upon position of converting messages --- not necessarily your own site's --- which are merely passing through your system, a situation in which you should merely be acting as a transport and not necessarily altering anything beyond the message envelope and related transport information.

5 See RFC 1740 (MacMIME) and RFC 1741 (Binhex).

Previous | Next | Contents