Ignorencoding, ignoremessageencoding, ignoremultipartencoding, interpretencoding, interpretmessageencoding, interpretmultipartencoding Channel Options

Encoding header interpretation
The MTA has the ability to convert various non-standard message formats to MIME via the  . In particular, the RFC 1154 format uses a non-standard Encoding: header line. However, some gateways emit incorrect information on this header line, with the result that sometimes it is desirable to ignore this header. The  source  channel option instructs the MTA to ignore any Encoding: header. (Note that unless the MTA has a  enabled, such headers will be ignored in any case.) The   source channel option instructs the MTA to pay attention to any Encoding: header line, if otherwise configured to do so, and is the default.

New in 6.3 are the,  ,  , and   source channel options. The MIME standards, RFC 2045 (which updates RFC 1521) and RFC 2046, restrict the set of allowed content-transfer-encodings permitted on MIME multipart or message parts to 7BIT, 8BIT, or BINARY in general, with the particular message subtypes message/partial and message/external-body being further restricted to allow only 7BIT. Nevertheless, buggy/incompliant software may sometimes emit messages that illegally label multipart or message parts as having another content-transfer-encoding. Now when such an illegal encoding label is seen, the question is whether the material is in fact encoded (illegally) as claimed, or whether the material is not in fact encoded and the claim is simply false.

Prior to 7.0.5, the MTA&#x27;s default handling (and the only handling available prior to 6.3) is to believe the Content-transfer-encoding: label---and the MTA can (and will) "decode" such messages. This corresponds to  and   channel options. This leads to "successful" handling of messages that are broken due to illegally being encoded---but will not be equally satisfactory for messages that are broken due to an outright false labelling with the contents not actually being encoded.

Alternatively, the new in 6.3  and   channel options, when placed on a source channel, will cause the MTA to ignore any claimed Content-transfer-encoding: on message parts or multipart parts, respectively, which can be more useful when broken software is emitting messages that falsely claim encoding of such parts. (Note that since what RFC 2045 specifies as the permitted and legal 7BIT, 8BIT, and BINARY content-transfer-encodings are all identity encodings---no transformation of the data is involved, with the content-transfer-encoding label merely recording what sort of material the part contains, which the MTA can determine for itself---it causes no harm to RFC 2045 conformant message or multipart parts to ignore the content-transfer-encoding. So for the moment, use of   channel options is "safe" for RFC 2045 legal messages. However, the experimental EAI (Email Address Internationalization) specifications are likely to change this MIME restriction, permitting encodings on such parts; at such time, support for correct messages would require respecting and interpreting any encodings on such parts.  So the   channel options, while a useful and safe-for-the-moment short-term workaround for broken, remote software, must be considered short-term: they may not continue to be safe to use in future.)

Note that the  utility has switches for testing and describing the (MIME) structure of messages, switches which correspond to these channel keywords.

Note that in Messaging Server 7.0u3 and prior versions, the  and   channel options would have no effect (be ignored) when placed on a    or SMS channel, or on any site-written channels.

The  channel option is the default in all versions. Prior to 7.0.5,  was also the default. But as of 7.0.5,  is the default.

See also:
 * CHARSET-CONVERSION mapping table
 * Attachments and MIME processing channel options
 * Channel options