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

From MsgServerDocWiki

Encoding header interpretation (ignorencoding, ignoremessageencoding, ignoremultipartencoding, interpretencoding, interpretmessageencoding, interpretmultipartencoding)

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

New in 6.3 are the ignoremessageencoding, interpretmessageencoding, ignoremultipartencoding, and interpretmultipartencoding 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.

The MTA'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 the default interpretmessageencoding and interpretmultipartencoding 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 ignoremessageencoding and ignoremultipartencoding 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 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 correct message or multipart parts to ignore the content-transfer-encoding.)