MIME Boundary Headers

From MsgServerDocWiki

What causes MIME "Boundary" headers to be rewritten?

UPDATE, 9/13/2010: This information has been moved to http://wikis.sun.com/pages/viewpage.action?pageId=216498848. Refer to that page from now on.

The MTA routinely rewrites MIME boundary markers if it needs to process the MIME content in a message.

There are many conditions that can cause the MTA to perform MIME content scanning, including but not limited to:

• Use of certain channel options such as inner or thurman
• The need to downgrade a message from 8bit to 7bit encoding
• Conversion channel processing
• Use of charset conversion facilities

To understand more about why this is happening in a specific case, get a slave_debug (on _all_ relevant incoming tcp_* channels), MM_DEBUG=5 in option.dat, tcp_local_slave.log* file showing what the message looked like as it was being received by the MTA.

However, even if you are able to determine why MIME processing is happening in a particular case and prevent it, this often turns into a fool's errand. For better or worse, MIME was designed from the outset to allow transport intermediaries to process MIME content, and even if you eliminate one case there can be others waiting to activate for some other message variant.

The rules for MIME boundary markers can be found in the MIME specifications, specifically in section 5.1.1 of RFC 2046. In particular, while "=" is a valid (even recommended!) character to use in boundary markers, it must be quoted in the parameter specification on the original Content-type: header line.

One issue that comes up is software that incorrectly specifes a Content-transfer-encoding - perhaps QUOTED-PRINTABLE - on message/rfc822 or multipart types, which is illegal. The MTA by default interprets such bogus MIME by assuming that the part really is encoded, which means that "=" characters, for instance, get "decoded". This creates a situation where the boundaries cannot be found and hence the part content cannot be extracted.

New in Messaging Server 6.3 are the ignoremessageencoding and ignoremultipartencoding channel options, which control whether or not the MTA will honor a content-transfer-encoding field attached to a message or multipart object. Care must be taken when using these keywords, as some messages that employ these fields on non-leaf objects do have the stated encoding present. For this reason fixing the broken software that emits invalid MIME is always the preferred solution.