Microsoft Exchange Server 2007 transport rules provide a rich interface to control messages based on certain properties of those messages. Microsoft made changes to Exchange Server architecture that have helped expose this functionality for easier administration and to provide better compliance and content control. Message classification complements transport rules as a means of tagging messages, either manually or automatically, for specific treatment. Microsoft Office Outlook 2007 and Outlook Web Access (OWA) 2007 with Exchange 2007 bring this control to life.
Exchange 2007 Changes Transport Architecture
With Exchange 2003 and Exchange 2000, Microsoft used the extensible SMTP engine of Microsoft Internet Information Services (IIS), running within the inetinfo.exe process, to provide Internet messaging services. Exchange used Component Object Model (COM)–based engines to integrate with IIS SMTP and provide programmatic access to the SMTP transport subsystem. SMTP event sinks provided the conduit between Exchange extensions of IIS SMTP and message transport. The coding required to implement a comprehensive event sink was beyond the scope of many Exchange administrators.
When Microsoft developed Exchange 2007, they rewrote the transport system from scratch in managed code. SMTP and message processing are now handled within Exchange by the Microsoft Exchange Transport Service (MSExchangeTransport.exe). The new architecture lets sequential agents access the SMTP stream at specific events. These SMTP Receive Agent events represent different commands and processes in an SMTP conversation. Table 1 outlines the different events exposed in the order they're met through an SMTP transaction.
Transport Agents and Rules
Transport agents represent code that interacts with SMTP messages through class libraries provided by Exchange 2007. Agents can read and change message properties and content during SMTP Receive Agent events. Transport rules depend on specific transport agents: the Edge Rules agent on Exchange 2007 servers running the Edge Transport role and the Transport Rule agent on servers with the Hub Transport role installed. These rules agents act at the OnEndOfData event in the SMTP stream. Administrators assign direction to the rules agents through the use of transport rules.
An example of transport agents at work is exhibited by the set of antispam agents employed by an Edge Transport server as well as Exchange servers running the Hub Transport role with the optional antispam agents installed. The antispam agents act on message properties exposed through SMTP events and can amend an email message, reject a message, and even re-address a message. To view the transport agents installed on a server, you can run the Exchange Management Shell (EMS) command
Get-TransportPipeline
Figure 1 shows the output from running this command on an Edge Transport server. You can see where the antispam agents reside in the transport process as well as the Edge Rules agent at the OnEndOfData event.
Microsoft doesn't apply any restrictions to transport agent behavior: They have significant access to message content and header information and therefore only trusted and tested transport agents should be deployed in production. For more information on transport agents, refer to the Microsoft article "Transport Agents" from the Exchange Server Developer Center Library.
Edge vs. Hub: A Tale of Two Roles
Transport rules can be managed through Exchange Management Console (EMC) as well as EMS. They can be implemented on Exchange 2007 servers hosting the Edge Transport role or the Hub Transport role. The method for administering transport rules on these separate roles is the same; however, the focus of the set of rules is different.
Transport rules on the Edge Transport role primarily contribute to message hygiene. The Edge Rules agent can protect your internal network from email-borne attacks, such as virus outbreaks or denial of service attacks. It can also prevent internal compromises from being escalated to your clients and other external contacts by identifying and blocking unwanted outbound messages. The Edge Transport server is an email gateway, so you can use transport rules here to help ensure content reaching users' Inboxes is relevant.
Edge Transport server rules are stored within the local implementation of Active Directory Application Mode (ADAM); therefore, where multiple Edge servers are used, each Edge server has an independent set of transport rules. ADAM is a somewhat portable subset of Active Directory (AD) and isn't replicated between servers. You can maintain identical, redundant Edge Transport servers hosting the same set of transport rules, or unique Edge Transport servers for managing specific traffic, such as separating inbound and outbound messaging gateways.
Transport rules on Hub Transport servers focus more on message compliance and policy enforcement. You can restrict or prevent email delivery between groups of users within the organization and ensure certain information doesn't get delivered to unintended recipients. Hub Transport rules can also be used to append content, such as a disclaimer, to message bodies prior to submission to an outbound gateway server. Transport Rules are stored in the Exchange Configuration container in AD. Because these transport rules are stored in AD and replicated to all domain controllers, all Hub Transport servers access the same set of transport rules. And because every message sent through an Exchange 2007 organization must pass through at least one Hub Transport server, every message has the Hub Transport rules applied to it. This situation provides a solid platform for meeting messaging compliance requirements.
There are three components to transport rules: conditions, exceptions, and actions. Conditions and exceptions are sometimes called predicates. Web Table 1 lists the predicates and actions available for Edge Transport and Hub Transport rules. Hub Transport rules have more options that give you greater control over message flow. Edge Transport rules identify message properties to help discern whether the message should pass freely, be amended, or even rejected.
The available options for transport rules might not meet the requirements of every organization, and they can't be edited. However, developers can make their own transport agents to meet message control requirements not met by the basic transport rule set. Within transport rules, there are predicates that are dependent on a value called classification and an action that can assign a message classification to an email message based on properties of the message—so now is when we see how message classifications can be added to the mix to provide more granular control over your environment.
Tony Redmond covers transport rules in more detail in "Exchange 2007 Transport Rules."
What Are Message Classifications?
Message classification, similar to message categories in the Outlook client, is a means of labeling and differentiating messages. These classification tags can then be used within a transport rule predicate so that specific actions can be invoked. Messages classifications can be assigned by a Hub Transport rule or by user action before sending a new message. This feature is new to Exchange 2007 and available only with Outlook 2007 and OWA 2007. Previous versions won't recognize message classifications.
Exchange includes several preconfigured message classifications. These samples can be changed or deleted, but they might fit the needs of your company. They are as follows:
- A/C Privileged
- Attachment Removed
- Company Confidential
- Company Internal
- Originator Requested Alternate Recipient Mail
- Partner
The EMS cmdlet Get-MessageClassification with the format list output option can list the details of message classifications. Here's an example using the A/C Privileged classification (that's Attorney/Client, not Air Conditioning as it's apt to mean here in the Mojave Desert):
Get-MessageClassification "A/C Privileged" |fl
Figure 2 shows the output from this command.