Content type and TNEF handling in Exchange 2010 for remote domains

At work it came up that we needed to have our emails downgraded to plain text if they were being sent out to the internet. The reason for this was so that our filtering software could remove PII without having to worry about the HTML code behind the human-readable version getting false flagged. As the filter was on the edge appliance internal emails could be left as HTML without fear of being false-flagged.

This sounds pretty simple to do. Unfortunately, it turned into a trip down the rabbit hole.

Under Exchange 2010 there are policies for remote domains, with the natural fallback of Default handling anything not already defined. I proceeded to do what one would natural expect would accomplish the desired goal. I first issued the following commands:

Set-RemoteDomain Default -ContentType MimeText
Set-RemoteDomain Default -TNEFEnabled $False

Everything appeared to work at first. Then I found Outlook clients weren’t sending their messages as plain text. This resulted in me spending several hours trying to puzzle it out, and finally a support call to Microsoft.

The call managed to explain why I was seeing what I was seeing.

There are three points of action : Outlook client, Contact/Mail user, and Remote Domain settings on the server.

For TNEF settings the order of application is exactly that – Outlook client, Contact/Mail user, and Remote Domain settings on the server. The server setting for the remote domain overrides anything set for a mail user/contact entry which overrides anything from Outlook.

However, ContentType is not that way. Instead it is the exact opposite, with the Outlook client having the last say in the equation. MOst people are now thinking “WHAT?!!! Why would the client be allowed to override the server’s setting?!!” I was given no clear answer on this from Microsoft, instead receiving the patent “By design” response.

What I was able to work out with Microsoft was the following:
1] For OWA clients I had to disable the Premium experience. While this did not prevent reading in HTML it did force ALL new, reply, and forward emails to be in plain-text.
2] For Outlook clients the implementations was a little more complicated. I had to create a GPO which had to have the following settings:
User Configuration|Policies|Administrative Templates|Classic Administrative Templets|Microsoft Outlook 2010|Disable Items in User Interface|Custom
Disable command bar buttons and menu items : 5564,5565
User Configuration|Policies|Administrative Templates|Classic Administrative Templets|Microsoft Outlook 2010|Mail Format|Internet Formatting
Outlook Rich Text Options :    Enabled
Use this format :    Convert to plain text
User Configuration|Policies|Administrative Templates|Classic Administrative Templets|Microsoft Outlook 2010|Mail Format|Internet Formatting|Message Format
Set message format : Enabled
Use the following format for e-mail messages:    Plain Text
User Configuration|Policies|Administrative Templates|Classic Administrative Templets|Microsoft Outlook 2010|Outlook Options|Preferences|E-mail Options
Read e-mail as plain text :    Enabled
Essentially what this did was force Outlook to read messages in plain text, and to write new messages in plain text. It also disabled the buttons under the Format tab for RTF and HTML. Now a user could still read the message in HTML by clicking the info message and choosing Display in HTML, and from there reply or forward in HTML but that is not something most people are going to do for every message every time it is opened.

Hopefully Microsoft will one day correct the precedence with ContentType conversion such that it is as Administrators would expect and want, namely server overrides client.

Copyright Info

Advertisements

Comments are closed.