In a recent post, I described the basic approach to building an Exchange 2010 transport rule to build corporate disclaimers containing Active Directory data and formatted nicely with HTML that are then appended to all outgoing messages. The approach works well in most instances, but there are situations when you don’t want Exchange to go anywhere near an outgoing message.

Encrypted or signed messages are an obvious example. These messages only remain trusted as long as their integrity remains intact. It’s obvious that if a transport rule was to process a signed or encrypted message to append a disclaimer, its integrity would be pretty compromised. For this reason, Exchange doesn’t attempt to open signed or encrypted messages when it processes transport rules that might append some information (see TechNet for more information). Instead, these messages are wrapped in another message to which Exchange can apply the disclaimer and the message passes through to its destination, where the recipient sees a message containing the disclaimer and an attachment containing the original message.

In most cases, this is fine and the recipient is happy that they’ve received the content that they expect without any question that the email system has examined or interfered with the contents in any way. However, in some cases, you might want the original message to be passed through with no attempt being made by Exchange to apply the disclaimer.

As outlined in Exchange 2010 Help, the Exchange developers clearly anticipated this need because they provide the ExceptIfMessageTypeMatches parameter to allow transport rules to exclude certain types of messages. The supported types are:

• OOF
• AutoAccept
• AutoForward
• Encrypted
• Calendaring
• PermissionControlled
• Voicemail
• RSS
• Signed
• ApprovalRequest
• ReadReceipt

There’s some gold to be mined here because “Signed” and “Encrypted” are two of the supported message types. We can therefore go ahead and take a transport rule that applies a corporate disclaimer and amend it slightly to exclude the message type that we need to pass through without being processed. For example, to exclude digitally-signed messages, we would run the Set-TransportRule cmdlet as follows:

Set-TransportRule –Id “Disclaimer” –ExceptIfMessageTypeMatches "Signed"

Once the cmdlet runs, the transport system will begin to exclude signed messages from its processing and they will be passed intact through to their destination. You can also accomplish the same goal by selecting the transport rule with EMC and running the wizard to modify the rule. You need to move through the wizard to the fourth screen, which deals with exceptions. Scroll down to find the exception for message types, click on the check box and then select “Signed” or “Encrypted” from the list.

Using EMC to select a message type as an exception

So good so far, unless you want the rule to exclude both signed and encrypted messages from applying disclaimers. At this point you discover that the predicates used for conditions and exceptions in Exchange transport rules usually take just one value. In this case, it would be wonderful if you could run a command like:

Set-TransportRule –Id “Disclaimer” –ExceptIfMessageTypeMatches "Signed, Encrypted"

But this isn’t supported – at least, not in the current builds of Exchange 2010. Rats!

However, the flexibility of transport rules comes to our rescue again because we can deploy rules to “search and mark” signed and encrypted messages and then exclude the marked messages in our disclaimer rule. Remember that Exchange processes transport rules in order of priority so as long as our “search and mark” rules fire before the corporate disclaimer rule, all should be well.

Message classifications are useful here (actually, this is one of the few places that I have found them to be useful). First, we create a new message classification that we can use to mark messages through transport rules:

New-MessageClassification -Name 'Do Not Process' -DisplayName 'Do Not Process'              -SenderDescription 'Used by a transport rule - not for human beings'

Next, we create two new transport rules. The first rule looks for encrypted messages and does nothing except stamp these messages with our “Do Not Process” classification. The second rule does much the same thing for signed messages. After the transport system processes messages with these rules, any message that is signed or encrypted (or both) should be stamped with the “Do Not Process” classification.

New-TransportRule -Name 'Select Encrypted messages' -Comments 'This rule selects encrypted messages and stamps them with the Do Not Process classification' -Priority '1' -Enabled $True -FromScope 'InOrganization' -MessageTypeMatches 'Encrypted' -ApplyClassification 'Default\Do not process'

New-TransportRule -Name 'Select Digitally signed messages' -Comments 'This rule selects digitally signed messages and stamps them with the Do Not Process classification' -Priority '2’ -Enabled $True -FromScope 'InOrganization' -MessageTypeMatches 'Signed'                -ApplyClassification 'Default\Do not process'

We can then update the rule that applies corporate disclaimers with a new exception specified in the ExceptIfHasClassification parameter that looks for the classification that is applied to signed and encrypted messages. These messages are promptly excluded so they pass through without a disclaimer being applied. Note that the identity of the message classification includes “Default\” as you can have different language values for message classifications within an Exchange organization.

Set-TransportRule -Identity 'Corporate disclaimer' -Name 'Corporate disclaimer' -Comments 'This rule applies the approved corporate disclaimer text to all outgoing messages.'       -ExceptIfHasClassification 'Default\Do not process' -Priority '3'

So there you are… we hit a limitation in Exchange transport rule processing and overcame it using transport rules and accomplished our goal without burning up too many brain cells or time. I’m sure the more inventive members of the Exchange community will have other ideas as to how to best solve this problem, so I am all ears to hear their suggestions!

– Tony

Want more information about all the weird and wonderful things you can do with Exchange 2010 Transport Rules? Read all about them in chapter 16 of my most recent book, Microsoft Exchange Server 2010 Inside Out, also available at Amazon.co.uk. The book is also available in a Kindle edition.