TNEF & Winmail.dat

Issue with TNEF:

The use of TNEF is commonly affected by settings in Outlook that are referred to as "Microsoft Outlook Rich Text Format." Rich Text Format and TNEF are not exactly the same, but they are closely related.

A TNEF-encoded message contains a plain text version of the message, and a binary attachment that "packages" various other parts of the original message. In most cases, the binary attachment will be named Winmail.dat, and may include:

In addition to the information listed above, the path to your personal folders file (PST) file and your logon name are embedded in the winmail.dat file. Although this data is not explicitly exposed to the recipient, if the recipient opens the winmail.dat file for editing in a binary or text editor, he can see the path and logon name. Note that no password information is revealed. To ensure that the path to your PST file or your logon name is not included in the winmail.dat attachment, use the steps in this article to send mail that does not include winmail.dat.

Some Outlook features require TNEF encoding to be understood correctly by an Internet e-mail recipient who also uses Outlook. For example, when you send a message with voting buttons to a recipient over the Internet, if TNEF is not enabled for that recipient, the voting buttons will not be received. Alternatively, for sending messages with regular file attachments, TNEF is not needed. If you are sending e-mail with file attachments to a recipient who does not use Outlook or the Exchange Client, you should manually choose to use a mail format that does not require TNEF (such as plain text). By not sending TNEF messages, the recipient will be able to view and save the attachments as expected.

Issues when Send & Receiving mails:

When a message containing TNEF information is received by a mail client that does not understand TNEF, there are three common results:

In addition to the receiving client, it is not uncommon for a mail server to strip out TNEF information from mail messages as it delivers them. If a server option to remove TNEF is turned on, clients will always receive a plain text version of the message. Microsoft Exchange Server is an example of a mail server application that has the option to remove TNEF from messages.

Internet Standards - Message Encoding:

The Internet standards for encoding messages such as Multipart Internet Mail Extensions (MIME) and UUENCODE are used independently of TNEF. TNEF can exist in a MIME-encoded message as a MIME body part of type "application/ms-tnef," or in a UUENCODED message as an attachment named Winmail.dat.

When a TNEF message is sent using MIME, an entry similar to the following is added to the message:

------ =_NextPart_000_01BA6275.348C1000 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IisSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAEAAQ ABBJAGAEgBAAABAAAADAAAAAMAADACAAAACwAPDgAAAAACAf8PAQAAAHQAAAAAAAAAtTvC [. . .]

Alternatively, if a TNEF message is sent using UUENCODE, information similar to the following is added to the bottom of the message:

begin 600 WINMAIL.DAT M>)\^(C<.`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$%@ ,` M#@```,L'" `$``<`)P`O``4`0 $!"8 !`"$````S,S5$,C,W,#%"0T-#13$ [. . .]

In either case, the TNEF encoding is sent to the recipient and must be understood by the receiving client to correctly display the encapsulated information.

For more information, please read this article

TNEF & Winmail.dat 

Exchange Server 2003 uses transport neutral encapsulation format (TNEF) to convert MAPI messages to RFC 822 format. TNEF appears on a message as a MIME attachment of type application/ms-tnef. The attachment is called Winmail.dat. It contains the full message content and any attached files. Only MAPI clients, such as Outlook, are able to decode the Winmail.dat attachment. Non-MAPI clients are unable to decode TNEF and might show Winmail.dat as a typical, but useless file.

Note: Recipients with mailboxes on an Exchange server, who use Internet clients to access their messages, are not considered non-MAPI recipients. This is because the Exchange store that hosts the mailboxes can produce the necessary RFC 822 content in non-MAPI format when users download MAPI messages from their Inboxes using a POP3 or an IMAP4 client. There are several possible Exchange-to-Exchange transfer scenarios that require MAPI to RFC 822 conversion:

• Recipient is on an Exchange server in the same routing group   Exchange Server 2003 renders MAPI messages into Summary-TNEF (S/TNEF) format, a special kind of transport-neutral encapsulation format (TNEF), which has no plain text part and is rendered in eight-bit binary format. S/TNEF messages consist only of Winmail.dat.

Note: Within a routing group, Exchange Server 2003 always uses S/TNEF, because in all remote delivery cases, the message is guaranteed to take either an SMTP hop directly to a server running Exchange 2000 Server or Exchange Server 2003 or go to the Exchange MTA. Exchange 2000 Server and Exchange Server 2003 support binary MIME. On the other hand, if the message is passed to the Exchange MTA for delivery to a server running Exchange Server 5.5 through RPCs, message conversion is not required, because the RFC 822 format is not used.

• Recipient is on an Exchange server in another routing group and the Exchange organization is operating in native mode   Exchange Server 2003 renders MAPI messages into Summary-TNEF (S/TNEF) format, because in native mode an Exchange organization can include only servers running Exchange 2000 Server and Exchange Server 2003 that support binary MIME.

• Recipient is on an Exchange server in another routing group and the Exchange organization is operating in mixed mode   In mixed mode, it is possible to use the Internet Mail Service of Exchange Server 5.5 as an SMTP connector, but Internet Mail Service does not support binary MIME. Because the RFC 822 representation of S/TNEF that IMAIL generates is binary MIME, Internet Mail Service is unable to transfer S/TNEF messages. Because the Exchange categorizer cannot detect beforehand what route a message will take, the categorizer does not convert the message to S/TNEF for a recipient that is on a server outside the local routing group in mixed mode. To accommodate a potential Internet Mail Service instance in the transfer path, the Exchange categorizer converts the message to a plain text part and an attachment in legacy TNEF, which is seven-bit MIME that Internet Mail Service, can transfer.

• Recipient is a MAPI recipient outside the local Exchange organization Users and administrators can enable the transfer of TNEF across the boundaries of the local Exchange organization for recipients in external messaging environments who use Outlook. Because the recipient is not in the local Exchange organization, the Exchange categorizer cannot determine if all SMTP hosts involved in the message transfer support binary MIME. Correspondingly, the Exchange categorizer converts the message to a plain text part and an attachment in legacy TNEF.

Note: Non-MAPI recipients typically prefer to receive a message in plain text or HTML without TNEF, because their clients cannot decode the Winmail.dat file that includes the message and all attachments. TNEF encapsulation prevents non-MAPI clients from accessing attachments. Non-Microsoft tools, such as EPOC WMDecode for Windows, might be able to extract attachments from Winmail.dat files.

• MAPI messages sent to public folders   Messages sent to public folders are always relayed in legacy TNEF format.
• MAPI messages sent to an expansion server over SMTP   If a message contains a distribution list with an explicit expansion server that is not the local server, the message is forwarded to the expansion server in legacy TNEF format (if SMTP is used for message transfer). In this case, a property is transmitted in the message transfer envelope through XEXCH50 that notifies the expansion server of the time the message was originally received through the Exchange store driver. After the categorizer on the expansion server expands the distribution list, it must apply the effective RFC 822 message formats to the individual recipients. The categorizer uses the Exchange store driver to copy the message to the Exchange store, where IMAIL reads the TNEF data to construct a MAPI message with the submit time of the original message. The SMTP transport subsystem can then read the MAPI message from the store in an RFC 822 format consistent with the recipients' formatting requirements.

You can control the TNEF format behavior for sending messages by adding the following registry key. The number nn represents the virtual server instance for this machine.