A clash between S/MIME and transport rules

S/MIME support for Outlook Web App (OWA) is one of the resurrected features that made its appearance in Exchange 2013 SP1. Apart from the welcome replacement of a heap of registry entries to control the S/MIME configuration on servers with the Set-SMIMEConfig cmdlet, the feature set delivers much the same functionality as in Exchange 2010, with the exception that only recent versions of Internet Explorer (IE9 and above) are supported. These browsers can download an updated version of the S/MIME control and OWA boasts the necessary user interface to allow default message options for encryption or digitally signing to be set. You can also apply these options to individual messages.

SP1 appeared some months ago - we're now waiting for CU7 to be released early next month, but it takes me time to test things out. In any case, I eventually got around to sending a signed message to my nearest and dearest to advise her that I was en route home for lunch.

Unfortunately the message was bounced by the transport system and my lunch wasn’t quite in the state that I anticipated when I arrived home. Not that matrimonial discontent then ensued. More of a case of “you know where lunch is, serve yourself”, if you know what I mean.

Getting back to technology, I resolved to discover why Exchange didn’t like my signed message. Everything had worked the last time I had looked at S/MIME in the early builds of SP1; the necessary certificates were in place; I had clicked on the right checkboxes; and OWA confirmed the signed status of my message with a tasteful icon. All seemed to be well.

But life is complex and software configurations have a nasty habit of interfering with the best-laid plans. The root cause of my problem was another Exchange feature, Data Loss Prevention (DLP), or rather, the transport rules that embody a DLP policy.

DLP, as you’ll recall, is a compliance mechanism intended to help users to avoid sending confidential or sensitive data types such as credit card or social security numbers in email. A DLP policy tells Exchange what sensitive data types to check for, including those created by a company through the document fingerprinting facility. Once advised, Exchange pushes information (an XML payload) to Outlook and OWA clients so that they can examine message content as it is input by users to detect potential policy violations and prompt them if necessary. As I am sure you will agree, we all like being told that we have included some sensitive data in messages.

Users can ignore the velvet glove approach of policy prompts and continue to send messages that contain sensitive data. That’s where the iron fist of transport rules come crashing down to examine messages passing through the transport pipeline and, if those messages contain data that shouldn’t be there, take an appropriate action up to and including bouncing messages.

You’ll have recognized by now that a message home to tell loved ones known of your imminent arrival for lunch is probably outside the boundaries of the DLP design as envisaged by its creators. Lunch times and locations might be ultra-sensitive when conducting an illicit affair de coeur, but they hardly come into the same category as passport numbers or bank account details.

Nevertheless, my message had been bounced. And with some examination of the transport rules enabled by the DLP policy, I found the answer. Microsoft kindly provides some out-of-the-box templates to help you build a suitable DLP policy. I had selected the “U.S. Federal Trade Commission (FTC) Consumer Rules” template. Exchange then created five transport rules to enable the policy, including one called “U.S. FTC Rules: Attachment not supported.”

The function of this rule is to block any attempt to send a message through the transport system that has an attachment that cannot be read by the system. Exchange understands the content of many attachment types including all the common Microsoft Office types and Adobe PDF because the transport system uses the same filters as the Search Foundation uses to build its content indexes. However, when you send a signed S/MIME message, the message body is dispatched as an attachment that is, naturally enough, unsupported because the transport system doesn’t know how to access the encrypted content. Cue bounced message, frustration, and a less than satisfying lunch.

These rules were created with the RTM release of Exchange 2013 and if you create the rules today from the same DLP template you'll see that the action in the rule is a lot less aggressive as it only audits the fact that an unsupported attachment was encountered. It seems that the development group took the decision that this was a better starting point for rule enforcement than blocking the message and made it the standard. After all, if you want a more stringent policy, you can update the rule and change the action.

As is often the case, the solution was simple. Transport rules allow for a great deal of conditional processing and you can add exceptions to rules so that they do not fire in specific circumstances. The solution is therefore to add an exception so that the rule ignored signed messages. As it happened, I had to update the standard (non-DLP) transport rule that applied my corporate disclaimer with the same exception as it would also bounce the message on the logical basis that you can’t add a chunk of HTML text to the bottom of a signed message.

The adjustments to the set of transport rules allow signed and unsigned lunch time notifications to now flow normally. The sense of relief was palpable.

Seriously, the experience proves once again that a very real need exists to carefully test all the features of a new software release before deployment into production. You never know when one feature might disagree with another – and that can lead to more serious consequences than lunchtime woes.

Follow Tony @12Knocksinna