OK, here's my explanation for what TNEF is. Skip it if you've heard me say it at MEC. Exchange and Outlook clients, against Exchange servers, typically use MAPI to talk to the server. In this mode of operation (as opposed to POP or IMAP), the Outlook client does not generate a MIME message, it sets different message properties (To, body, attachments, special calendaring or task properties, etc.) as certain predefined MAPI properties. The client uses RPC to marshall these properties over to the server, where they are stored in the message store. Now, when this message needs to go over to another server, it's very important the properties be maintained exactly as they are set. In the old days (Exchange 4.x, 5.x), servers usually used RPC to send the properties acrosss to other servers in the same Organization. When the message went via RPC, there was no problem keeping the properties the same as they went across. But then, we introduced SMTP as a way to send messages from one server to another. The problem was: how to maintain those properties? There was no standard way in MIME to map all of those properties. They could have chosen to add a bunch of X-headers, but that would been pretty ugly. So, they decided to invent a way to encapsulate the MAPI properties and attach them to the SMTP message. In those days, you were just as likely to want to send uuencode as MIME, so they invented a filename as well as a MIME type: winmail.dat, and application/ms-tnef. They might have used a different MIME type in the beginning, I'm not sure.
A TNEF'd message will have a plain text rendering of the body, and a TNEF attachment that contains the MAPI properties, including a rich rendering of the body and any custom properties. The other piece of information about TNEF is that when you send a message that has an attachment and it goes out with TNEF, the attachment is encapsulated inside the TNEF. So this is where the experience that if a message comes in with TNEF to a recipient that can't parse TNEF, it seems OK to the recipient (since they see the plain text rendering), but they "lose the attachments", because the attachments are encoded within the TNEF. Anyway, that's what TNEF is: a way to make sure that MAPI properties as set on one server are persisted as the message travels across SMTP to another server. Exchange servers and Outlook clients know how to take the TNEF attachment apart and put it back into the native MAPI properties that they understand. Most other clients do not know how to deal with TNEF. A friend of mine wrote a TNEF parser for UNIX, since he worked at a company that used Exchange but refused to use Outlook (http://www.fiction.net/blong/programs/#tnef2txt). Whether or not a message will go out with TNEF has nothing to do with the way the message body is encoded within the TNEF, it is a completely orthogonal setting. You can have a message whose body is encoded as plain text, as HTML, or as RTF (remember, RTF is a file format for Microsoft Word! It has nothing to do with TNEF), but the body is encoded within TNEF. Whether or not a message is TNEF'd depends on the way the recipients are set. By default, a message to a one-off recipient in Outlook will be set as "not TNEF", or "not Outlook Rich Text Format". You can select to have a recipient get TNEF, either in the properties of the one-off recipient, or if they are created as a contact you can set it by right-clicking on the email address in the contact record just the same way (in OL 2000 there was a checkbox and they called it "Exchange Rich Text Format"). Additionally, since you all are Exchange admins, you will probably recognize the server-based setting that lets you set a given domain to get "Exchange Rich Text Format" either always, never, or (the default) based on user settings. The default "user" setting lets individual users set whether or not a given recipient will get TNEF. Disclaimer: This information is provided "as is" with no warranties. David -----Original Message----- From: Daniel Chenault [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 7:29 PM To: Exchange Discussions Subject: Re: win.dat attachments ?? Using any kind of rich text results in 8-bit characters that have to be converted. In MIME this creates a type of MS-TNEF which only a handful of clients can read. The rest, if they can unravel it at all, show a winmail.dat attachment that nothing can open. msinternal: in KB search "danich mime ms-tnef" Unless I'm seriously misunderstanding what you're saying, that is... ----- Original Message ----- From: "David Lemson" <[EMAIL PROTECTED]> To: "Exchange Discussions" <[EMAIL PROTECTED]> Sent: Tuesday, February 12, 2002 8:10 PM Subject: RE: win.dat attachments The key string is "Exchange Rich Text" or "Outlook Rich Text". Wherever you see that, choose NOT Rich Text. This will result in not sending winmail.dat. Incidentally, this has nothing to do with RTF at all. David -----Original Message----- From: Daniel Chenault [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 12, 2002 2:36 PM To: Exchange Discussions Subject: Re: win.dat attachments Disallow RTF to the Internet, a setting on the IMS. ----- Original Message ----- From: "wade robinson" <[EMAIL PROTECTED]> To: "Exchange Discussions" <[EMAIL PROTECTED]> Sent: Tuesday, February 12, 2002 10:19 AM Subject: win.dat attachments > I have an Exchange 2000 server that includes several separate > customers attaching via Outlook 2002. One customer (several different > users) is having an issue sending attachments to some external > recipients. The attachments (word, excel) will be received and > displayed as win.dat. This does not happen to all external > recipients. We have been able to recreate this issue sending > attachments to a hot mail account, however sometimes the attachment > arrives in tact to the hot mail account sent from the same client. We > have turned off word as an editor and configured Outlook to send in > Exchange RTF and HTML with the same results. Even using OWA produce > the win.dat attachment on the external account. I have to believe it > is a client setting as none of the other customers riding the same > infrastructure have had this problem. Any help would be greatly > appreciated. > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
