How different versions of Outlook and Exchange deal with HTML message body?

[The_Exchange_Team]

This post provides a brief explanation of how the body of a message (HTML in particular) is handled by the different versions of Outlook (Outlook 97, Outlook 98, Outlook 2000, Outlook XP and Outlook 2003) and Exchange (Exchange 5.5, Exchange 2000, and Exchange 2003). We got a question related to this in one of our earlier postings.

For the Exchange server:

Exchange 5.5 doesn't support HTML messages and can only support clients that use the rich text (stored on the server under PR_RTF_COMPRESSED) representation of the body.

Exchange 2000 can handle both Rich Text and HTML messages and can convert between them when asked by clients.

Exchange 2000 also has a feature that determines the best body of a message and returns the best body when requested by a client.

Exchange 2003 is the same as Exchange 2000 except it has added capability for security filtering of HTML which is primarily used by Outlook Web Access. This feature was to remove potentially dangerous content from HTML, which could create virus or do other harm.

For the Outlook client:

Outlook 97 doesn't support retrieving the body from the server as HTML and will only ask the server for the Rich Text format representation of the body. This means that it will always ask the Exchange server for the Rich text format (PR_RTF_COMPRESSED) of a message and any conversion to a different format (text/HTML) will occur on the client.

Outlook 98 started supporting HTML bodies and it can handle retrieving both the HTML (PR_HTML) and Rich Text (PR_RTF_COMPRESSED) representations of the body. It will ask for the HTML body only if it determines that the server supports it otherwise it will ask for the Rich Text body.

Outlook 2000 behaves same as Outlook 98.

Outlook XP is capable of using the best body feature of the Exchange server. The best body feature can only be used when in online mode and won't work properly for offline mode.

Outlook 2003 supports best body feature in both online and offline modes. The feature is also enabled for cache mode resulting in the same body handling logic for both PST and OST. Other than those, it works the same as Outlook XP.

The converter library (used for doing client/server side conversion between HTML/Plain Text/Rich Text) is different in each Outlook/Exchange version and as such the output can change slightly between Outlook/Exchange versions.

- Je Seog Park

[#2]

What about Entourage ??

[#3]

Um, are you sure about Exchange 5.5? If Exchange 5.5 didn't support HTML messages, then how could you use Outlook Express, for example, to send an HTML message over Exchange?

My impression, having launched Exchange 5.5 and being involved in many of the perf tests, is that Exchange 5.5 *always* generates the RTF property when encountering an HTML message, and then stores the RTF alongside the HTML. This of course is a performance and storage bummer if none of your Internet-native clients understand RTF to begin with.

Exchange 2000 (and 2003) doesn't do any conversion from HTML to RTF at all, unless the message is specifically requested by an RTF client. From that point, the RTF bodypart is available on the message; no further conversion is necessary should other RTF clients request the same message.

Chris

[#4]

To take on to Corentin's comment.. how do the various iterations of Outlook.MAC and Entourage deal with the conversion of HTML content?

[#5]

In 5.5 the HTML content is encoded inside PR_RTF_COMPRESSED. When you hit the server through pop3/smtp, we do the decoding on the fly.

[#6]

To add to the mix - Outlook 98/2000 in the IMO mode (which cannot connect to Exchange) only uses PR_HTML_BODY (same as PR_HTML, but is PT_STRING8 rather than PT_BINARY), but never PR_RTF_COMPRESSED.

Does Outlook use the STORE_HTML_OK bit in PR_STORE_SUPPORT_MASK to figure out what it needs to request?

[#7]

We have here some problems on Ex2K with HTML Mails and german mutation (Umlaute). Mutations in E-Mails sent from Windows to Mac get corrupted :(
Any suggestions?

[#8]

Christian,

I spoke to Je Seog on this; We'd need to look at the EML file of the message itself to tell what might be wrong. Is there an email that we can contact you on?