Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2010-02-11

This topic explains how transport rules are applied across a Microsoft Exchange Server 2007 organization. For more information about transport rules, see Overview of Transport Rules.

Transport Rule Scope

You can configure transport rules to use together with the Transport Rules agents that are configured on computers that have the Hub Transport server role or the Edge Transport server role installed. The procedures to configure transport rules on each server role are the same, but the scope of the transport rules on each server role is very different.

Transport component Hub Transport server role Edge Transport server role

Agent

Transport Rules agent

Edge Rules agent

Transport event

OnRoutedMessage

EndOfData

Rule storage

Active Directory domain controllers

Active Directory Lightweight Directory Services (AD LDS) (local)

Rule replication

Active Directory replication

No automated replication between Edge Transport servers

Rule scope

Entire Exchange organization

Local to each Edge Transport server

Message types

All messages except system messages

All messages except system messages

Lookup distribution group membership

Yes

No

Lookup Active Directory attributes

Yes

No

Inspect or modify Information Rights Management (IRM)-protected message content

Yes (requires transport decryption)

No

Rule Storage and Replication

The transport rules that you configure on one Hub Transport server are applied via the Active Directory directory service to all other Hub Transport servers in the Exchange 2007 organization. This means that each Hub Transport server in the organization applies the same set of transport rules, and the same transport rules are applied to all e-mail messages that are sent or received in the organization. Transport rules on Hub Transport servers evaluate all messages that meet the following criteria:

  • Meeting requests, regular messages, encrypted messages, and rights-protected messages that are sent between authenticated users.

  • All e-mail messages that are sent anonymously, regardless of message type, sender or recipient.

Note:
Exchange 2007 relies on Active Directory to replicate transport rules across the organization. For more information, see "Transport Rule Replication" later in this topic.

The transport rules that you configure on an Edge Transport server are applied only to e-mail messages that pass through that specific Edge Transport server. The Transport Rule agents that run on each Edge Transport server do not interact with other Transport Rule agents on other Edge Transport servers. Therefore, you can configure Edge Transport servers to apply distinct transport rules depending on the e-mail messaging traffic that they manage. Transport rules on Edge Transport servers evaluate all messages that they encounter.

Message Types Processed by Transport Rules in Exchange 2007 RTM

The following message types are processed by transport rules in the release to manufacturing (RTM) version of Exchange 2007:

  • Anonymous e-mail messages   Anonymous e-mail messages are messages that have been submitted to a Hub Transport server or Edge Transport server by an unauthenticated sender or server.

  • Interpersonal e-mail messages   Interpersonal e-mail messages are messages that contain a single rich text format (RTF), HTML, or plain-text message body, or a multipart or alternative set of message bodies.

  • Opaque e-mail messages   Opaque e-mail messages are messages that have been encrypted and may also have been signed.

  • Clear-signed e-mail messages   Clear-signed e-mail messages are messages that have been signed, but have not been encrypted.

Message Types Processed by Transport Rules in Exchange 2007 SP1

The following message types are processed by transport rules in Exchange 2007 Service Pack 1 (SP1):

  • Anonymous e-mail messages   Anonymous e-mail messages are messages that have been submitted to a Hub Transport server or Edge Transport server by an unauthenticated sender or server.

  • Interpersonal e-mail messages   Interpersonal e-mail messages are messages that contain a single RTF, HTML, or plain-text message body or a multipart or alternative set of message bodies.

  • Opaque e-mail messages   Opaque e-mail messages are messages that have been encrypted and may also have been signed. Transport rules can access envelope headers contained in encrypted messages and process messages based on predicates that inspect them. Rules with predicates that require inspection of message content, or actions that may modify content, cannot be processed.

  • Clear-signed e-mail messages   Clear-signed e-mail messages are messages that have been signed, but have not been encrypted.

  • Unified Messaging e-mail messages   Unified Messaging e-mail messages are messages created or processed by the Unified Messaging server role, such as voice mail, fax, missed call notifications, and messages created or forwarded by using Outlook Voice Access.

  • IPM.Note. e-mail messages   E-mail messages that have a message class prefix of IPM.Note. are messages created by using applications, custom forms, or both.

Transport Rule Replication

Transport rules that are configured on a Hub Transport server are applied to the whole Exchange 2007 organization, except Edge Transport servers. When a new transport rule is created or an existing transport rule is modified or deleted on a Hub Transport server, the change is replicated to all Active Directory servers in the organization. All the Hub Transport servers in the organization then read the new configuration from the Active Directory servers and apply the new or modified transport rules to e-mail messages that pass through the Hub Transport server. By replicating all the transport rules across the organization, Exchange 2007 enables you to provide a consistent set of transport rules across the organization. All e-mail messages that pass in or through your Exchange 2007 organization are subject to the same transport rules.

Important:
Replication of transport rules across an organization is dependant on Active Directory replication. Replication time between Active Directory domain controllers varies depending on the number of sites in the organization, slow links, and other factors outside the control of Exchange. When you configure transport rules in your organization, make sure that you consider replication delays. For more information about Active Directory replication, see Active Directory Replication Technologies.
Important:
Each Hub Transport server maintains a recipient cache that is used to look up recipient and distribution list information. The recipient cache reduces the number of requests that each Hub Transport server must make to an Active Directory domain controller. The recipient cache updates every four hours. You can't modify the recipient cache update interval. Therefore, changes to transport rule recipients, such as the addition or removal of distribution list members, may not be applied to transport rules until the recipient cache is updated. To force an immediate update of the recipient cache, you must stop and start the Microsoft Exchange Transport service. You must do this for each Hub Transport server where you want to forcibly update the recipient cache.
Note:
Each time the Hub Transport server retrieves a new transport rule configuration, an event is logged in the Security log in Event Viewer.

Transport rules that are configured on Edge Transport servers are applied only to the local server on which the transport rule was created. New transport rules and changes to existing transport rules affect only e-mail messages that pass through that specific Edge Transport server. If you have more than one Edge Transport server and you want to apply a consistent set of rules across all Edge Transport servers, you must either manually configure each server or export the transport rules from one server and import them into all other Edge Transport servers.

Predicates

Predicates are used by conditions and by exceptions. Predicates define what part of an e-mail message the conditions and exceptions examine to determine whether the transport rule should be applied to that message. Some predicates examine the To or From fields of a message, whereas other predicates examine the subject, body, or attachment size. To determine whether a transport rule should be applied to a message, most predicates require that you specify a value that the predicates use to test against the message.

Conditions

Transport rule conditions are used to indicate which e-mail message attributes, headers, recipients, senders, or other parts of the message are used to identify the e-mail messages to which a transport rule action should be applied. Most conditions accept a value that the condition should look for in the message. If the data in the section of the e-mail message that the condition is inspecting matches the value of the condition, the message matches that condition.

You can configure multiple conditions on a transport rule to narrow the scope of the transport rule so that it applies actions only to messages that have very specific criteria. Alternatively, you may decide not to apply any conditions. If you don't include any conditions on a transport rule, the transport rule is applied to all messages that the transport rule encounters. The number of conditions that you can apply to a single transport rule is unlimited. However, when you apply more conditions, the number of e-mail messages that meet each specified condition is reduced.

Important:
If you configure multiple conditions on the same transport rule, all the conditions must be met for the transport rule to apply the configured action to a particular e-mail message.

When you specify multiple values on a single condition, if one or more of the values are matched, the condition is satisfied. For example, if an e-mail message has the subject Stock price information, and the SubjectContains condition on a transport rule is configured to match the words Contoso and stock, the condition is satisfied because the subject contains at least one of the values of the condition.

Although conditions are used to determine which e-mail messages to include when a transport rule applies an action, transport rules also use exceptions to determine which e-mail messages to exclude from having an action applied, even though the message matches all the conditions. For more information about exceptions, see "Exceptions" later in this topic.

To view a list of predicates that you can use to configure transport rule conditions, see Transport Rule Predicates.

Exceptions

Transport rule exceptions are based on the same predicates that are used to create transport rule conditions. However, unlike transport rule conditions, exceptions identify the e-mail messages to which a transport rule action should not be applied. Transport rule exceptions override conditions and prevent a transport rule action from being applied to an e-mail message, even if the message matches all configured transport rule conditions.

Most exceptions accept a value that the exception should look for in the message. If the data in the section of the e-mail message that the exception is inspecting matches the value of the exception, the message matches that exception.

You can configure multiple exceptions on a transport rule to expand the criteria that is used to identify e-mail messages to which a transport rule action should not be applied. Alternatively, you may decide not to apply any exceptions. If you don't include any exceptions on a transport rule, the transport rule applies the rule based on whether the message matches all the configured transport rule conditions. The number of exceptions that you can apply to a single transport rule is unlimited.

Important:
If you configure multiple exceptions on the same transport rule, only one exception must be matched for the transport rule action to be excluded from being applied to an e-mail message.

When you specify multiple values on a single exception, if one or more of the values are matched, the exception is satisfied. For example, if an e-mail message has the subject Stock price information, and a transport rule uses the SubjectContains exception, which is configured to match the words Contoso and stock, the exception is satisfied because the subject contains at least one of the values of the exception.

To view a list of predicates that you can use to configure transport rule exceptions, see Transport Rule Predicates.

Actions

Actions are applied to e-mail messages that match the conditions and none of the exceptions that are present on transport rules that are configured on Transport Rules agents. Each action affects e-mail messages in a different way, from redirecting the e-mail message to another address, to dropping the message.

After you select the actions that you want to use, you can then assign a value to those actions. The value of the action modifies how a particular action behaves when it is applied to an e-mail message.

To view a list of predicates that you can use to configure transport rule actions, see Transport Rule Actions.

Order in Which Transport Rules Are Applied

Transport rules are applied in the following order:

  1. Whether the rule is enabled or disabled:   Only enabled rules are applied. When a rule is disabled, the rule does not lose its priority. However, the rule is not included in the evaluation process.

  2. Message scope:   The first check performed by rules agents is whether a message falls within the scope of the agent. Transport rules aren't applied to all types of messages.

  3. Priority:   For messages that fall within the scope of the rules agent, the agent starts processing rules based on rule priority in ascending order. Rules that have lower priority are applied first. Transport rule priority values range from 0 to n-1, where n is the total number of transport rules. Only enabled rules are applied, regardless of priority. You can change the priority of rules by using the Exchange Management Console or the Exchange Management Shell.