Le Café Central de Deva
..... Deva blogs!!
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:
The formatted text version of the message (font information, colors, and such)
OLE objects (embedded pictures, embedded Office documents, and such)
Special Outlook features (custom forms, voting buttons, meeting requests, and such)
Regular file attachments that were added to the original message
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:
The plain text version of the message is received and it contains an attachment named Winmail.dat. The Winmail.dat attachment does not contain any useful information when opened since it is in the special TNEF format.
The plain text version of the message is received and it contains an attachment with a generic name such as ATT00008.dat or ATT00005.eml. In this case the client is unable to recognize the TNEF part of the message, and is unable to recognize the Winmail.dat file name, so it creates a file name to hold the TNEF information.
The plain text version of the message is received and the client ignores the Winmail.dat attachment. This is the behavior found in Microsoft Outlook Express. Outlook Express does not understand TNEF, but it does know to ignore TNEF information. The result is a plain text message.
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:
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.
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.
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.
HKey_Local_Machine\Software\Microsoft\Exchange\StoreDriver\Exchange\ nn \EnableTnef
A value of 0x0 disables TNEF, and messages are generated without using TNEF. A value of 0x1 will generate a message using legacy TNEF when S/TNEF would ordinarily be generated. A value of 0x2 has no effect, as that is the default behavior.
PingBack from http://geeklectures.info/2007/12/18/tnef/
Great article. Still applies to 2010 and Office 365! Just had a problem where users in Office 365 would send mail to our on-premise mailbox. That mailbox then forwarded to a contact with an external SMTP address. Since we're federated with Microsoft, the cloud sent the S/TNEF message (thinking we were in the same exchange organization) to our on-prem not knowing it would ultimately be sent externally. Our outside users would get winmail.dat and we couldn't control it through the normal means in Exchange (RTF, remote-domain, etc). We had to remove the forward in the EMC/account and create a server-side rule using Outlook that redirected all messages to the external contact.
Thanks to Jeff Thibodeau at MS Exchange Support for this!