CHARSET-CONVERSION mapping table

The  mapping table specifies what sorts of channel-to-channel character set conversions and message reformatting should be done. As suggested by the mapping name, character set conversion is its primary purpose.

The  mapping can also be used to alter the  format of  messages. Facilities are provided to convert a number of non-MIME formats into MIME. Changes to MIME encodings and structure are also possible. These options are used when messages are being relayed to systems that only support MIME or some subset of MIME. And finally, conversion from MIME into non-MIME formats is provided in a small  number of cases.

As of MS 8.0.2.1, enabling charset conversions also checks for and attempts to mitigate the various so-called MailSploit attacks. More specifically, if charset conversions are enabled for a given destination, the MTA will:



 Check the content of and remove unnecessary encoded-words during submission. In particular, encoded-words consisting of nothing but an atom or domain will be decoded. Note that this happens only when using SUBMIT, which should always be before DKIM or similar protection mechanisms are applied. 

 Remove control characters other than those needed for MIME-compatible charsets. This includes, but is not limited to NUL, CR and LF. 

 Remove any empty encoded-words that result from (2). 

 Recognize and process encoded-words outside the contexts where they normally appear. (This behavior is appropriate for an MTA seeking to mitigate attacks that may depend on broken clients that recognize encoded-words outside the contexts where they normally occur.) 



Note that the removal of NULs and similar CTLs is justified from a standards perspective since RFC 2047 requires that encoded words represent printable material in a MIME text/US-ASCII compatible charset. As such, this material should not be present in standards-compliant encoded-words.

The MTA will probe the  mapping table in two  different ways. The first probe is used to determine whether or not the MTA should reformat (or at least process) the message and if so, what formatting options  should be used. (If no reformatting is specified, then the MTA does not bother to check for specific character set conversions.) The input  string for this first probe has (by default) the general form: IN-CHAN=in-channel;OUT-CHAN=out-channel;CONVERT Here  is the name of the source channel  (where the message comes from) and   is  the name of the destination channel (where the message is going). New in MS 6.3, setting bit 0 (value 1) of the    MTA option will cause  this first probe to instead have the form IN-CHAN=in-channel;OUT-CHAN=out-channel;TAG=tag-list;CONVERT where  is a comma-separated list of any  conversion tags present on the message.

If the probe matches the pattern (left hand side) of a   mapping table entry, then the resulting string  (right hand side of the mapping entry) should be a comma-separated list  of keywords. The following keywords are provided:

If a match is found, the MTA will perform any requested message reformatting, discussed further in Message reformatting, and for text parts, also check whether charset conversion is desired, as discussed further in Character set conversion. A  is assumed if no match occurs.

If the message has a conversion tag set, note that the  " "  flag will be set, and this can be tested for (when a match on the  pattern, i.e., left hand side, occurred) using a    test in the template (right hand side) output string. Such tests are more commonly used in the    mapping table, but under less common conditions may potentially be useful here  in the    mapping table.

See also:
 * Character set conversion and message reformatting
 * Character set conversion
 * Message reformatting
 * Relabelling MIME header lines
 * Service conversions
 * MacMIME format conversions
 * thurman Option
 * include_conversiontag MTA Option
 * Conversion tags
 * original_channel_probe MTA Option
 * CONVERSIONS mapping table