Transport Rules: Exception to the Rule

[The_Exchange_Team]

When constructing Transport Rules, it is pretty straight forward to define a set of conditions and then specify the action to take when those conditions are met. It is easy to overlook an optional third component: Exceptions. Several customer questions that I have come across for how to enforce more complex policies were solved through the use of exceptions in their rule constructions. This article will present some example customer scenarios to help illustrate how exceptions can be used in Transport Rules.

I won't go into a full overview of what Transport Rules are, or how they are managed (e.g., EMC, ECP, or PowerShell) in this article. If you are unfamiliar with the Exchange 2010 Transport Rules features, you may find it useful to first read the Transport Rule documentation on TechNet.

What are transport rule exceptions?

Transport rule exceptions look very similar to transport rule conditions. Transport rule conditions are used to identify which messages are to have the transport rule action applied to them; however, exceptions are used to exclude specific messages from the transport rule action. Exceptions are essentially loopholes in the transport rule, overriding the conditions and preventing a transport rule action from being applied to an e-mail message.

You can configure multiple exceptions in a given transport rule, and it is important to understand that the logical relationship of these exceptions is such that if any one of the exceptions evaluates as true, then the message bypasses the rule - even if all of the conditions are met. To further explain the logical relationships in a transport rule:

Condition 1 AND Condition 2 AND Condition 3	All of these conditions must be TRUE for the action to be performed
Action 1	This is the action performed on the message
Exception 1 OR Exception 2 OR Exception 3	None of these conditions can be TRUE for the action to be performed.  In other words: if any of these conditions are TRUE, then do not perform the action.

To view a full list of predicates that you can use for transport rule exceptions, see Transport Rule Predicates in Exchange 2010 documentation.

Below are some example scenarios in which using exceptions are critical to meeting the organization's policy goals. Note that with the rich flexibility of transport rules there is often more than one way to construct a rule - the scenarios below are just examples to highlight the use of exceptions, and in many cases you could use different conditions to accomplish the same or similar goals.

Scenario 1: Restrict to the same organizational division

In this scenario, Contoso has a group of users that are working on a top secret project, and due to the sensitive nature of this project, these users should not be communicating project data with anyone outside of the project. Members of the secret project team can freely communicate with other members of the top secret project, and with the Human Resources department. Messages sent outside of these allowances must be approved by the team manager before delivery.

Note that a company's policy statement may not match one-to-one with the logical components in the transport rule structure, so it may be necessary to restructure the policy statement into a Condition/Action/Exception logic for the transport rule. In the example above, we can recompose the policy statement to say:

All messages sent from members of the top secret project team must be moderated by the team manager, except for messages sent to Human Resources or between members of the secret project team.

Then to enforce this policy, the Contoso Exchange admin creates this Transport Rule:

Conditions	Apply rule to messages from a member of 'Project X'
Actions	Forward the message to 'Joe Manager' for moderation
Exceptions	Except when the message is sent to a member of 'Human Resources'   OR except when the message is sent between members of 'Project X' and 'Project X'

Scenario 2: Closed perimeter; only allow privileged users or specific external domains

In this scenario (also known as the "Closed Campus" scenario), Contoso wishes to lock down their email perimeter to only allow internal communications. Users are not allowed to send or receive messages outside of the organization, unless they are members of a privileged group or the communication is with a specific partner e-mail domain.

There are several different ways to do achieve this goal, but the key is still in configuring the Exceptions in a transport rule. For example, if Contoso wants to block all outbound messages except messages to fabrikam.com...

Conditions	Apply rule to messages sent to users that are "Outside the organization"
Actions	Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1"
Exceptions	Except when a recipient's address contains "fabrikam.com"

By default all employee messages from Contoso to an external address will be blocked, except for external recipients with fabrikam.com in their email address (for example, "ed.banti@fabrikam.com"). Then, Contoso wants to additionally lift the restriction for a specific group of privileged Contoso users, so they add the following exception to the rule:

Exceptions

Except when a recipient's address contains "fabrikam.com" OR except when the message is from a member of "Privileged Users"

Finally, this scenario will actually need two transport rules to be complete. The rule to control outbound messages is shown above. Another rule to control inbound messages is needed, and would look like this:

Closed Perimeter - Inbound

Conditions	Apply rule to messages sent to users that are "Outside the organization"
Actions	Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1"
Exceptions	Except when a recipient's address contains "fabrikam.com" OR except when the message is from a member of "Privileged Users"

Scenario 3: Closed perimeter, with a twist

Now, let's twist the previous scenario - let's say that you want to block all outbound external messages unless the sender is in a privileged group AND it is to a specific external domain. You will remember from earlier in this article that multiple exceptions in a single rule are in a logical "OR" relationship, so how do we accomplish this goal?

Answer: you need multiple rules that fire in sequence (remember, that transport rules fire in order of their priority value). If you break up enforcement of this policy into two stages, you can ensure that both exceptions have to be matched before letting the message out of the organization. For example:

Outbound Rule 1 (priority = 1)

Conditions	Apply rule to messages sent to users that are "Outside the organization"
Actions	Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1"
Exceptions	Except when the message is from a member of "Privileged Users"

Outbound Rule 2 (priority = 2)

Conditions	Apply rule to messages sent to users that are "Outside the organization"
Actions	Send a rejection notice "You are not permitted to send e-mail to people outside of this organization" to the sender with the status code "5.7.1"
Exceptions	Except when a recipient's address contains "fabrikam.com"

The first rule will only allow outbound messages from members of the Privileged Users group, and the second rule will then only allow the privileged senders to send mail to the fabrikam.com email domain.

Other scenarios:

The Technet online help for Exchange 2010 has some additional Transport Rules scenario examples, which rely on exceptions. I won't repeat the configuration details here, but I've provided links to the relevant articles below:

• Disclaimers: an exception is used to prevent the application of a disclaimer where one already exists.
• Ethical Wall: an exception (in the PowerShell example) is used to allow Executives in restricted groups to communicate with each other.

If you have other example transport rules that you've implemented, in which the use of exceptions were key to meeting your policy goals, please share them with the rest of the community by posting them up in comments to this blog post. Thanks!

-- Steve Clagg

[#2]

Great article, Steve. It looks like the two rule examples in Scenario 3 have the same exceptions though. Wouldn't one contain the special group?

[#3]

@bday: Thanks for catching that - the exception text was updated.