Executive Summary:
| Microsoft Exchange Server 2003’s and Microsoft Exchange 2000 Server’s messaging architectures make compliance with legislation and other regulatory requirements difficult. |
| Microsoft Exchange Server 2007’s transport rules feature makes compliance with legislation and other regulatory requirements easier. |
| You can use Microsoft’s Exchange 2007 Management Console (EMC) or Microsoft Exchange Management Shell (EMS) commands to create Microsoft Exchange Server 2007 transport rules. |
Since the financial and other corporate scandals such as Enron that occurred around 2000, organizations are under increased pressure to comply with legislative and other regulatory requirements. Many companies must comply with the Sarbanes-Oxley Act’s audit requirements; financial companies are required to comply with Securities and Exchange Commission (SEC) regulations; and state and local governments often must comply with freedom of information legislation. In addition, various governments around the world have imposed requirements, such as the European Union (EU) directive that requires companies to include corporate information in all outgoing messages. Because more communication is electronic than ever before, email systems are under increasing scrutiny. Complying with regulations is often difficult in a Microsoft Exchange Server 2003 or Exchange 2000 Server environment. Exchange Server 2007 introduces transport rules that make compliance easier.
Exchange 2003 and 2000 Problem
Exchange 2003’s and Exchange 2000’s message transport architecture isn’t easily customizable for compliance because multiple paths exist for messages to flow through an Exchange server. You can write transport sinks, which are highly specialized code that you must integrate into the Exchange Transport service and that the Transport service can invoke to examine the contents, recipients, and other data as messages pass between servers. Transport sinks perform actions such as adding disclaimers to outgoing messages or ensuring that ethical walls stop certain groups of users who shouldn’t communicate from being able to send email messages to each other.
However, transport sinks can be expensive to create because few programmers have experience writing this kind of code to work with Exchange. In addition, the code is expensive to maintain because administrators must test it against every new hotfix, service pack, and new version of Exchange. Even worse, you can’t guarantee that the transport sink will process every message that flows through the system, because Exchange 2003’s and Exchange 2000’s Store process delivers local mail (messages sent from one mailbox to another on the same server) and doesn’t call the code in the transport sink. The Exchange Store is a closed process; programmers can’t integrate their own code into it to implement compliance checks. To achieve compliance, administrators must resort to tricks such as placing users who shouldn’t communicate with one another on different servers (to force messages through the transport system) or putting specific servers into certain routing groups (to journal messages for all users of a specific type, such as executives). The result is too much complexity and expense for too little functionality.
One Path for Exchange 2007
Microsoft recognized that the lack of a single path for messages through the transport system was a fundamental obstacle to successful compliance. Exchange 2007’s solution is two-fold. First, Exchange 2007 implements the concept of server roles, one of which is the hub transport server. All messages flow through the hub transport server, including messages destined for a local mailbox. In addition, Microsoft amended the Transport service’s categorizer component to be able to call transport and journal rules. The categorizer is responsible for preparing messages for delivery by expanding distribution groups, checking that recipients are valid, and so on. Transport and journal rules are implemented at the end of the categorizer check to ensure that all of the message data is available for processing. After the categorizer processes a message, the message is ready for placement in a delivery queue.
A journal rule is responsible for copying messages to a journal destination, which can be as simple as a mailbox on an Exchange server or an SMTP address that points to a third-party archiving solution such as Symantec’s Enterprise Vault or HP’s RISS. Conceptually, a journal rule is simple because it performs one action—it captures copies of messages. A transport rule is more complex because you have much more control over the criteria that Exchange uses to decide whether to apply the rule and what happens if a rule applies. Transport rules run the gamut from simple (e.g., adding a disclaimer) to complex (e.g., applying ethical firewalls). You can create journal and transport rules through the Exchange 2007 Management Console (EMC) or through Exchange Management Shell (EMS) commands. If you’re familiar with Microsoft Office Outlook’s rule wizard, you’ll find the Exchange 2007 rule wizard similar and easy to use.
Rules Storage
Exchange stores journal and transport rule details in the Exchange container in Active Directory’s (AD’s) configuration naming context, so AD replicates rule updates and new rules to all the domain controllers (DCs) in the forest. Assuming that AD replication works, you can quickly deploy rules in an organization. Microsoft recommends a maximum of 1,000 rules. This soft limit is imposed mainly because of the memory required to cache rules and is unlikely to affect most deployments because few companies will use more than 20 rules. However, companies that use Exchange as the basis of a hosted email server for other companies might want to use different rules for each hosted company and therefore exceed this limit.
Exchange 2007 Edge servers also support rules, but these rules are stored in the Active Directory Application Mode (ADAM) instance on the Edge server. Edge servers aren’t part of the Exchange organization, so they don’t share configuration data, including rules, with any other server. If you deploy Edge servers to provide antispam and antivirus protection for your organization, you must configure rules separately on each Edge server.
Adding a Disclaimer
Creating and implementing a transport rule to apply disclaimer text to messages is simple. But before you create a new rule, you should think about what you want the rule to accomplish. Make some notes to yourself that include the name of the rule and what you want it to achieve, users or groups affected by the rule, conditions under which Exchange will apply the rule, actions Exchange will take in applying the rule, and any exceptions that exist. In the case of applying a disclaimer to outgoing messages, you’d note that the rule applies to all of the organization’s outgoing messages, Exchange will append some text to the outgoing messages (which works for all but signed Secure MIME—S/MIME—messages because Exchange can’t change a digitally signed message without invalidating it), and no exceptions exist. Note that you should also check with your legal department, to ensure that the disclaimer text meets the necessary requirements.
All hub transport servers in an organization share and apply rules. To add a disclaimer to outgoing messages, open EMC and select Hub Transport Node under Organization Configuration. Click the New Transport Rule option to launch the New Transport Rule wizard, which Figure 1 shows. Enter a unique name for the rule. Entering details about the rule in the comment section is optional but recommended, to communicate to other administrators when and why you created the rule. The checkbox to enable the rule is selected by default.
Next, define the criteria Exchange applies in examining message properties. Defining criteria for the disclaimer rule is simple because the rule applies to every message sent. As Figure 2 shows, you simply select checkboxes to set criteria for a set of predefined conditions.
You could argue that the wizard limits the power of rules because you must select from a set of conditions that you can’t expand. However, the wizard’s options cover a huge variety of situations in which you might want to create a transport rule. If you can’t create a rule to meet your needs, you can use the Exchange 2007 software development kit (SDK) to write custom code.
To build the conditions for the disclaimer rule, select the criteria for messages sent by people inside the organization going to people outside the organization, as Figure 2 shows. As you select criteria, the wizard builds the rule at the bottom of the screen so that you can see all the conditions you’ve selected. You can click on a condition (i.e., the underlined words in the rule) to refine it. For example, if you click on the criterion from users inside or outside the organization, the wizard displays a dialog box that lets you select Inside or Outside to refine the rule’s scope, as Figure 2 shows. Selecting Outside causes Exchange to process external messages.
The next step is to tell Exchange what to do when a message matches the rule conditions. Again, you can select from a wide range of actions, such as dropping a message silently, bouncing it back to the sender, or appending some disclaimer text to the message. Figure 3 shows entering disclaimer text. Note that you can also specify the typeface, color, and size of characters to use. When you click Next, EMC creates the rule and simultaneously outputs the PowerShell code used to create the rule. You can copy this code to reuse in scripts.
Figure 4 shows EMC displaying a new rule. Each transport rule has a priority that dictates the order in which Exchange applies the rule during message processing. Priorities range from zero (highest) to the number of rules that exist within the organization (minus 1).
After you create a rule, AD replicates it. Depending on your replication speed, the rule will be effective shortly after creation and you’ll see the disclaimer text applied to all outgoing messages, as Figure 5 shows.
Applying an Ethical Firewall
Creating a rule to impose an ethical firewall between two sets of users is slightly more complex than creating a rule to apply a disclaimer. The broad outline for an ethical firewall includes checking for any message that a member of one set of users (usually a group) attempts to send to someone in the other set, the action to take, and no exceptions. Actions to take can include dropping a message silently or sending a copy of a message to a special mailbox that you use to audit attempted communications. For our rule, let’s return the message to the sender and log an entry in the Application event log.
Groups are important to transport rules because they provide an easy way to identify messages from specific sets of users for the rules to process. Exchange loads group membership into a cache for easy access to membership data, which improves the speed at which Exchange can perform checks. For our rule, we can create two groups called Business Analysts and Stock Brokers and assign to the two groups the users we want to stop communicating.
The next step is to create the rule. Give the rule a name and brief description, and outline the conditions for the rule. To prevent message delivery between the Business Analysts and Stock Brokers groups, select the between members of distribution list and distribution list condition, then select the names of the groups to check. Note that this rule controls bidirectional communication between two groups.
Next, select the option to return a Delivery Status Notification to the sender to notify the sender that the rule doesn’t allow messages to be sent to members of the other group. In addition, select the option to log an entry to the Application event log, as Figure 6 shows. (Figure 7 shows the subsequent Application event log entry.) Simply creating an entry in the Application event log doesn’t ensure that an administrator will see the violation. You also need to copy the event message to a dedicated mailbox for administrator review and action.
Exchange Management Shell
If you prefer, you can use EMS to create, edit, and delete transport rules. For example, the Get-TransportRule command lists the two rules we created. You can select a rule to view its complete set of properties.
The problem with using EMS to manage rules is that manipulating properties such as conditions and actions isn’t straightforward. For example, suppose you want to change the disclaimer text for outgoing messages. First, you need to create the context for the action that you want to take, then you need to build the details of the action, and finally you can use the Set-TransportRule command to apply the new disclaimer. You must set properties for the text, font, color, and size of the disclaimer, as the code in Listing 1 shows, before you can apply the disclaimer.
Although using EMC to manage rules is easier than using EMS, shell scripts are useful for applying in a production environment rules that you created and tested in the lab. You need to fully test new messaging rules before you deploy them in a live environment.
Simple Yet Powerful
Exchange 2003’s and Exchange 2000’s message transport systems make secure communications difficult. Exchange 2007 uses a single message path and transport rules to solve this problem. Rather than writing expensive custom code, you can now create and implement rules with an easy-to-use wizard. A few simple steps through this wizard let you use transport rules to solve real business problems. Transport rules are a powerful addition to the Exchange administrator’s toolkit and one of Exchange 2007’s best features.
