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.
Adding New Message Classifications
You create new message classifications on the server side for use by transport rules or by Outlook 2007 and OWA 2007 clients. You use the aptly named New-MessageClassification cmdlet through EMS to create message classifications. A few parameters are required as well. The message classification DisplayName parameter represents what users see in Outlook 2007 or OWA 2007 when selecting from the message classification list, as we'll see shortly. The SenderDescription and RecipientDescription fields are shown on messages that have been classified. You can see a complete list of parameters for the cmdlet in the Microsoft TechNet article "New-MessageClassification."
As an example, the command
New-MessageClassification -Name Articles
-DisplayName Windows IT Pro
-SenderDescription "This message contains
information and content supporting
Windows IT Pro magazine articles."
creates a message classification with the minimum required parameters; it has an identity of Articles and a display name of Windows IT Pro. The new classification is added to the Exchange Configuration container in AD next to Transport Rules. Of course, Message Classifications can be deleted in a similar manner with the Remove-MessageClassification cmdlet.
Setting Up Outlook for Classifications
Outlook isn't automatically aware of message classifications. Classifications are stored in AD and need to be exported to an XML file for Outlook, which you can do with a PowerShell script found in the scripts folder in the Exchange 2007 installation path (\program files\microsoft\exchange server\scripts\export-messageclassification.ps1). When you execute the script, pipe the output to an XML file:
c:\program files\microsoft\exchange server\scripts\
export-messageclassification.ps1 >>mclass.xml
Exporting multiple times to the same XML file appends the content instead of replacing it, which makes the file unusable by Outlook. You must use a unique name or remove any existing XML file by the same name before exporting.
Message classifications are available only with Outlook 2007 using MAPI or with OWA on an Exchange 2007 server running the Client Access role and accessing an Exchange 2007 mailbox. They aren't visible to Windows Mobile clients, other ActiveSync clients, or clients accessing Exchange with other Internet protocols, including POP3 and IMAP4. Classifications are defined in the exported XML file, but that file needs to be pushed out to clients. You could use a network share, but pushing the XML file to the actual workstation is recommended, especially if users work offline with Cached Exchange Mode.
You have to enable message classifications in Outlook 2007 on an individual client basis through the creation and configuration of a registry subkey, HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Policy. The subkey Policy doesn't exist by default and should only be created if the user's mailbox resides on an Exchange 2007 Mailbox server. You also don't need to enable clients that won't access the message classification system. In the Policy subkey, set the following values:
- "AdminClassificationPath"="c:\\Email\mclass.xml"
- "EnableClassifications"=dword:00000001
- "TrustClassifications"=dword:00000001
The full path and file name for the XML file must match what you assign using the AdminClassificationPath value in the registry.
Step-by-Step Message Classification Distribution
Message classification in Exchange 2007 isn't a set-and-forget configuration for Outlook and OWA. Any changes or additions made to the classifications on the Exchange server require another XML export and redistribution to Outlook clients. As a mini-review, the steps to distributing or updating message classifications for use at the client are:
- Add or change message classification through EMS
- Run the export shell script to create the XML file for clients
- Add registry subkey on clients that don't have it yet
- Distribute the XML file to clients to the location defined in the local client registry
- Restart Outlook if necessary
After these steps are completed, any changes or additions to message classifications can be used in transport rules to control message flow, maintain compliance, and enforce policy.
The requirement to manually create and distribute the XML file for message classification has been its Achilles' heel, limiting its adoption, especially for larger organizations. However, when a company establishes a solid set of message classifications and has them in place on Outlook 2007 clients, no further maintenance is required. It's only when changes need to be applied, whether adding a new classification or reinstalling a client workstation, that the tedious nature of message classification deployment arises.
There are tools within typical Windows networks that can assist in the distribution of updates to clients, including Group Policy and the Office Customization Tool for Office 2007. Some third-party application management products can apply registry changes and distribute files to workstations as well. Even with these tools, message classification adds administrative complexity that, for some companies, might not be worth the value of the deployed feature.
Using Transport Rules with Classifications
Message classifications are a way for users and organizations to better describe messages. They aren't associated with any transport rule by default. With Hub Transport rules, you can control how messages move within your organization. These rules evaluate whether messages meet one or more conditions, then check whether they meet any exceptions. If a message passes through these predicates, then the configured action is taken. In each step—conditions, exceptions, and actions—there's an option for consideration of message classifications.
Let's put the sample message classification we created earlier, named Articles, to work. First, follow the steps outlined in the previous section. Add a recipient description using EMS as follows:
Set-MessageClassification -Identity Articles
-RecipientDescription
"Alert! Windows IT Pro Article Content!"
RecipientDescription is an optional parameter in message classification creation. Next, run the export script to create a new XML file with this change; if you have more than one change to make, it's more efficient to do them all before creating the XML file.
You should verify the changes by sending a test message and confirming the message classification works as expected. Create a new email message and select the new classification from the drop-down menu under the Permissions button, as Figure 3 shows. When this message classification is selected in Outlook 2007, the sender description text appears at the top of the message.
With this message classification in place, let's create a transport rule for illustration purposes. The goal of this rule will be to assign the classification Articles to messages sent to our internal editor address unless they're sent with low importance. In EMC, navigate to the Organization Configuration container and select Hub Transport. Recall that transport rules are stored in AD and apply to all Hub Transport servers in the organization. Select the Transport Rules tab, then click New Transport Rule in the Action pane to open the New Transport Rule wizard.
Transport rules must be assigned a name, but the description is optional. Click Next to go to the Conditions screen, select the check box for sent to people, and edit the description so the rule is applied to messages sent to Editor, as Figure 4 shows. Next, the wizard displays the Action screen where you can assign the message classification Articles, selected by its display name of Windows IT Pro, to messages meeting the conditions of the rule, as Figure 5 shows. Now, this rule needs an exception for messages sent with Low Importance, which you can set on the Exceptions screen. Click Next to complete the new transport rule, and the final window shows the PowerShell command you could use to create this same rule through EMS.
To test this transport rule, you can send an email message without any message classifications assigned to it to the Editor mailbox and verify that the message is assigned the message classification when it arrives. Figure 6 shows the Recipient Description text applied by the message classification Articles, which was assigned to the test email by the transport rule.
The full set of Hub Transport rule conditions and exceptions shown in Web Table 1 is available for transport rules based on message classification. Transport rule actions can be applied based on the presence of a specific message classification, and a message classification can be applied to a message based on certain transport rule conditions. Messages to or from specific people or groups, messages with specific words or text patterns in addresses, message bodies, or header content, and even attachment name or size can all be used by companies to regulate message flow.
As an example, a small law firm in Vancouver uses message classifications and transport rules to separate important client communication into a resource mailbox. Their goal is to use the resource mailbox as a mini–client archive for important communication only, regardless of sender. Users assign message classifications before sending critical email messages to clients, and a transport rule copies the message to the resource mailbox based on the presence of the message classification and the recipient address.
Some companies might use message classification to emphasize the importance or confidentiality of an email message. The HR department could send out a message advising staff about changes in the health plan and select a message classification designed to display specific recipient text at the top of messages read in Outlook 2007 and OWA 2007.
Rules and Classifications: Better Together
When you use message classification in the formation of Hub Transport rules, either as a condition, an exception, or an action, you get greater administrative control over message flow. Classifications can help you use transport rules to enforce corporate policy, adhere to compliance initiatives, and generally prevent email content from being distributed to recipients that shouldn't have access to it. The system of transport rules is far from perfect, and the challenges of message classification distribution might prevent some companies from deploying the feature. Still, the full versatility of transport rules from enforcing ethical walls to appending disclaimers is enhanced by the message labeling system called message classification.