A Note on Content Conversion and Exchange 2007/2010

When referring to content conversion what I am talking about is the decision to send a message encapsulated in TNEF vs. HTML/Plaintext when sending outgoing messages.

Now I see there is some confusion as to when Exchange/Outlook will decide to send in TNEF as opposed to keeping a message in its native HTML and/or plain text format. It is the hope of this blog post to clear up some of that confusion.

First a bit of background-

In Exchange 2007/2010 (and Exchange 2003 as well) there are essentially three places where these content conversion choices can be influenced-

1. Remote Domains object (Internet message Formats in Exchange 2003)

2. Contact object

3. The outlook message properties

Here they are-

Remote Domain

Contact

Message properties (as viewed via MFCMAPI)

The above is also the order of precedence as well.

In other words all things being equal the settings on the Remote Domain will override the settings on the contact which will override the settings on the message property.

Now the above also happens to list the default values which are shown below again but via the shell this time-

Remote Domain

Contact

So based on the above we see that the default settings are set to, well, default.

What that means is they are not set so we need to go down one step further and see what the message properties are.

Now this is where some confusion lies. By default Outlook (all versions 2003 to 2010) will set the PR_SEND_RICH_INFO property of a message to TRUE if it can resolve an object in the address book. So if we are sending to a contact that is in the GAL (or OAB) and all the other settings are default the message will go out encapsulated in TNEF (with the corresponding Winmail.dat attachment).

To override this behavior we set the contact “UseMapiRichTextFormat” to NEVER or the remote domain “TNEFEnabled” to FALSE. Then we can block TNEF from leaving the org no matter what the client message properties are set to.

Now I need to mention that the above is a change from Exchange 2003 behavior. In Exchange 2003 when you create a mail contact in ADUC you will see that the mAPIRecipeint property (which corresponds to the UseMapiRichTextFormat in Exchange 2007/2010) is set to FALSE.

As you recall from the above discussion what this means is that outlook will be blocked from sending TNEF encapsulated messages to that particular contact.

So to summarize, in Exchange 2007/2010 when you create a contact in EMC/EMS the TNEF settings will be unset. In other words it will default to the client. As we know the client (outlook) will set the PR_SEND_RICH_INFO MAPI property to TRUE since it can resolve the contact in the address book.

With Exchange 2003 when you create a contact with ADUC the settings governing TNEF will be set to FALSE thus not allowing TNEF out of the org for that contact.

Note the above settings do not apply to one-off addresses. For these outlook will never set PR_SEND_RICH_INFO to TRUE and thus will always send HTML/Plaintext.

A Final Note About TNEF-

TNEF is used interchangeably a lot with Rich Text Format but they are NOT the same thing. And a lot of our own our documentation is guilty of this as well but they are really two separate concepts.

TNEF or transport neutral encapsulation format is a MIME complaint container for encapsulating messages in transport. This will be a multipart/mixed message with a Winmail.dat attachment.

These messages can be HTML or plain text or rich text. The point being that there does not have to be rich text format messages in this TNEF container. In fact if you get a TNEF parser and pop open a typical default outlook message where TNEF is allowed out of the ORG you will see no RTF within the Winmail.dat.

Rich Text Format is a MSFT proprietary message format that is used to display things like voting buttons etc. RTF needs to use TNEF as a MIME compliant transport.

So the take away is RTF needs to travel contained in TNEF but TNEF does not need to contain RTF.

Get it?

Thanks for reading.