Topic Last Modified: 2009-02-17

When a user who is outside an Exchange organization receives an e-mail message that includes an attachment named Winmail.dat from Microsoft Exchange Server 2007, the user cannot open the attached file.

This topic provides information about how to troubleshoot this issue, which can occur when the following conditions are true:

When a message is digitally signed or sealed, it cannot be changed. Therefore, a transport rule cannot add a disclaimer directly to the digitally signed or digitally sealed message. To make sure that a disclaimer is added to all messages, an administrator can configure a transport rule in Exchange so that a new message is created that includes the disclaimer. Then, Exchange "wraps" the new message around the original message if the original message cannot be changed. To do this, the original message is added to the wrapper message as a bodypart that has a "message/rfc822" content type.  In this scenario, the recipient receives a message that contains the disclaimer together with an attachment that contains the signed or sealed original message. The content of the original message is a binary attachment in TNEF format named Winmail.dat. However, not all e-mail client programs can interpret TNEF files.

Because some e-mail client programs cannot interpret TNEF files, when a message is sent to a recipient who does not belong to the local organization, the Hub Transport server converts the TNEF bodyparts to standard Internet bodyparts. However, the conversion to standard Internet bodyparts occurs after the message is wrapped in the disclaimer e-mail message. Bodyparts that are wrapped in a "message/rfc822" content type are not checked and converted. Therefore, the original message in the attached file is not converted to a format that can be deciphered by the recipient e-mail client.

Inside an Exchange organization, e-mail content is transmitted primarily in the form of TNEF-encoded bodyparts. TNEF-encoded bodyparts are not a problem inside the Exchange organization because Outlook can interpret TNEF-encoded content. Also, mechanisms exist to make sure that TNEF is converted into standard Internet-bodyparts when an Exchange user does not use Outlook to access messages.