Even though multipart messages have been around for ages and generally the features and interoperability across all sorts of email clients are pretty good I often come across issues where in particular Outlook can’t quite handle certain content types.

On this occasion the problem was such that emails with attachments from a particular sender were getting delivered fine but the recipient couldn’t see the attachments anywhere even though the message size clearly suggested there should be some. After some quick investigation it became apparent that while Outlook 2010 didn’t display the attachments OWA did albeit without showing the usual paperclip icon next to the message. Users were also able to see the attachments on their blackberries. This suggested that the issue lies within outlook (2010 in my case but it later transpired that Outlook 2007 would do the same).

Quick google revealed a KB article which pretty nicely matched my problem. The problem is with Exchange not validating reference to an inline attachment and hiding the attachment. I have followed the resolution steps:

1. Stop the Exchange Transport service.
2. Locate the EdgeTransport.exe.config file. This file is located in the following path:  <drive> :\Program Files\Microsoft\Exchange Server\Bin\
3. In the EdgeTransport.exe.config file, add the following entry between the <appSettings> element and the </appSettings> element: <add key=”TreatInlineDispositionAsAttachment” value=”true” />
4.  Restart the Transport service.

After getting the affected sender to resend the message the attachments were displayed but no paperclip in the navigation pane. I was a little bit intrigued as to why would Exchange regard the attachments as inline in the first place when I knew these were individual attachments. To get to the bottom of this problem I have compared the headers of two messages – one that was displayed correctly and one without the paperclip. Messages from the affected senders had the Content-Type header value as multipart/related while a normally displayed message would be multipart/mixed. You can find all the details on RFC2387 here but to get to my point the use of multipart/related isn’t correct in this scenario where the recipient is expected to view individual attachments.

Exchange considers all attachment parts inside multipart/related as inline attachments which should be accessible from inside the body and therefore hides them from the attachments list which explains why the first solution worked but suggests a nicer solution.

Since the MIME is malformed we really should be fixing the original message format. In most cases you will have no control over the sender’s infrastructure so the only option left is creating a hub transport rule on your Exchange server to change the content-type value from multipart/related to multipart/mixed:

1. Launch Exchange Management Console
2. Expand Organization Configuration, and select Hub Transport
3. Select New Transport Rule … in the action pane
4. Give the rule a name (ex. Change Content-Type)
5. Select When the message header contains text patterns
6. Under message header enter Content-Type and multipart/related under text patterns. Click Next.
7. Select Set header with value and enter Content-Type as header.
8.  Enter multipart/mixed as value and click Next.
9. You don’t need to create any exceptions (unless you want to).
10. Click finish to complete the rule creation.

With this solution you should have the message display nicely including the paperclip in Outlook navigation pane.