The issue we are experiencing was introduced by our hub transport server when it was running Exchange 2010 update 3.
The hub transport server contained journaling rules which caused all email messages passing through the hub server to be journaled to, our email archiving SaaS provider.
Due to a bug in Exchange (see MSKB982209) the journal server rules under update 3 cause the Content-Type and Content-Encoding-Type headers of the email message to incorrectly show the following;
Content-Type: text/plain; charset="utf-8"
However the message body or attachments were not actually encoded using these methods so when the message is opened in an email client, such as Microsoft Outlook the message body appears garbled.
See the attached screen shot for an example of what the end user sees when viewing the message.
The journaled messages with the incorrect values for the Content-Type and Content-Transfer-Encoding were successfully delivered to our Email Archive provider but the messages as they exist within the archive are unreadable as they cannot be opened in an email client.
If the values for Content-Type and Content-Transfer-Encoding headers in a message are updated to the ACTUAL method used by the hub transport server to encode the messages the messages display normally within Outlook or any other email client.
Our ultimate goal is to repair the message headers so they reflect the ACTUAL encoding method used by the transport server thereby allowing the message body (and message attachments) to appear normally when opened within an email client.
To repair the messages in the archive we need to know the following;
1) How can we programmatically identify messages that suffer from this encoding mismatch problem; i.e. where the Content-Type and Content-Transfer-Encoding differ from the actual encoding method used.
2) Within a garbled message what should the Content-Type and Content-Transfer-Encoding field values be updated to so the message can be displayed normally within an email client such as MS Outlook. (What Content-Type and Content-Transfer-Encoding method was actually used by the hub transport server running Exchange Update 3. There are three types of messages for which we need this information;
a. A message with no attachments where only the message body appears garbled when viewed in an email client
b. A message with attachments where the message body displays correctly but the attachments cannot be opened because they are garbled (Again we believe due to an encoding mis-match). This problem occurs more frequently.
c. A message with attachments where both the message body displays garbled and the attachments cannot be opened because that are garbled (Again both due to an encoding mis-match).
Our goal is to identify the algorithmic bug exhibit in an exchange transport server running Update 3 (and was subsequently fixed in RU4, see above KB article) and reverse apply it to correct the garbled messages currently in our Digital Archive.
This is an extremely time sensitive issue and I need to learn if this problem can be addressed programmatically and if it can be done how to do it.
Time is of the essence.