Filtering Messages in Exchange 2003

In Exchange Server 2003, Microsoft introduces several new features that have become necessary in today's enterprise messaging environment, including a set of filtering capabilities designed to protect Exchange against unsolicited commercial email (UCE—aka spam). Exchange 2003's recipient filtering, sender filtering, restricted groups, and restricted recipients features let you specify which senders and receivers can exchange messages across your Exchange environment. To get the most out of these features, you need to understand how they work, when to apply them, and how to configure them. (Connection filtering, a feature new to Exchange 2003 that uses Real-Time Block Lists—RBLs—to check incoming connections for known spammers, has been discussed elsewhere. For information about RBLs, see The Exchange Server Troubleshooter, "Exploring Exchange Server 2003's Spam-Filtering Capabilities," November 2003, http://www.winnetmag.com/microsoftexchangeoutlook, InstantDoc ID 40067.)

Recipient Filtering
Exchange 2000 Server lets you use Recipient Policies to define the domains for which the server will accept messages. Although these policies work well, they open a hole in the messaging service that a spammer can exploit. For example, if a spammer determines that your organization accepts email for hp.com or compaq.com, the spammer can simply generate email targeting those domains and send unwanted messages into your environment. In most forms, spam is just a nuisance, but it can also transport viruses or malicious information.

Microsoft addresses this hole through various filtering capabilities. One filter new to Exchange 2003 is recipient filtering, which lets an Exchange SMTP Virtual Server block incoming email by turfing, or dropping, an SMTP connection. Specifically, Exchange determines whether the "Rcpt To:" SMTP command contains an address that's in the recipient filter list on the Message Delivery Properties dialog box's Recipient Filtering tab, which Figure 1 shows, in Exchange System Manager (ESM).

Recipient filters apply to email submitted by anonymous clients, which typically means SMTP mailers (e.g., Sendmail). Any client, including any other Exchange servers in the same organization, that authenticates to the SMTP service bypasses the filter. You can configure authentication between Exchange 2000 servers in different organizations so that messages from these servers will bypass the filter as well, which can be useful in a multiforest Exchange 2003 environment.

You can configure recipient filters to apply to specific addresses or to all addresses that don't appear in the Exchange directory. Exchange will drop any messages sent to addresses that you add to the recipient filter list, regardless of whether the addresses exist in the directory. If you select the Filter recipients who are not in the Directory check box in Figure 1, Exchange will drop messages for any recipients not in the directory.

When you configure recipient filtering for an SMTP Virtual Server, the filter applies to every recipient of every message entering the SMTP Virtual Server. Exchange will drop messages to recipient addresses on a filter list and deliver messages to addresses not on the filter list. For example, if you filter the address [email protected] and send a message to this address and to [email protected], you'll receive a delivery receipt from Jack because his address wasn't filtered. However, Exchange will drop the message sent to [email protected] and the sending system will generate a nondelivery report (NDR).

Because Exchange 2003 implements recipient filtering as a transport sink, Microsoft claims that the server's performance doesn't suffer significantly. Furthermore, the sending system, not the filtering system, generates NDRs.

Any addresses that you enter in the recipient filter list must meet the following conditions:

You configure recipient filters at a global level in ESM, but you must apply the filters to specific SMTP Virtual Servers. To apply a filter, right-click the SMTP Virtual Server of interest in ESM, select Properties from the context menu, select the General tab, click Advanced, select the IP address for the SMTP Virtual Server of interest, click Edit, then select the Apply Recipient Filter check box, as Figure 2 shows. You will typically set filters on Internet-facing bridgeheads and not on every SMTP Virtual Server in the organization. The requirement to specifically configure an SMTP Virtual Server to use a filter applies to all message delivery filters (i.e., connection filters, sender filters, and recipient filters).

After you set filtering on an SMTP Virtual Server, you can use any Lightweight Directory Access Protocol (LDAP) browser or directory-aware tool, such as ADSI Edit, to examine the Configuration naming context (NC) and see how recipient filtering manifests itself in Active Directory (AD). By viewing the default message filter object held in AD, you can see the attributes that are set when you create a recipient filter. To view this object and its associated attributes, you need to point your LDAP browser to

CN=Default Message Filter,   CN=Message    Delivery,CN=Global   Settings,CN=Organization   Name,CN=Microsoft   Exchange,CN=Services,cn=configuration,   dc=domain,dc=domain

For my query, I pointed to

CN=Default Message Filter,   CN=Message    Delivery,CN=Global   Settings,CN=QUIDDICH,   CN=Microsoft   Exchange,   CN=Services,  cn=configuration,   dc=quiddich,dc=tst

Note that Exchange stores the filtered recipient addresses in the msExchRecipTurfListNames attribute.

Sender Filtering
Sender filters aren't new to Exchange 2003 (in fact, Microsoft first introduced them with Exchange 2000). Sender filters are almost identical to recipient filters except they process only the "Mail From:" SMTP command. In short, Exchange uses sender filters to drop messages received from a specific set of users or domains. Because the steps for configuring sender filters are so similar to the steps for configuring recipient filters, I focus on a few important points.

As I mentioned previously, you configure filters at a global level and apply those filters to specific SMTP Virtual Servers. Figure 3 shows several check boxes on the Message Delivery Properties dialog box's Sender Filtering tab in ESM. These options modify the behavior of a sender filter.

After you configure the sender filter, if Exchange receives a message from an address on the sender-filtering list, it drops the message according to these settings and, by default, generates an NDR. The default NDR message is The e-mail address could not be found. Perhaps the recipient moved to a different e-mail organization, or there was a mistake in the address. The intent is to give the sender as little information as possible. However, you can create custom NDRs (Microsoft will include detailed instructions about how to do so with the Exchange 2003 software development kit—SDK). Like recipient filters, Exchange stores sender filters in AD's Configuration NC. AD stores sender-filtered addresses in the msExchTurfListNames attribute of the default message filter object.

Restricted Distribution Groups and Recipients
Although Exchange 2000 lets you restrict access to distribution group recipients, it only restricts access based on whether the sender exists in the directory. As a result, Exchange 2000 can't protect you from someone who spoofs a directory address to get around this restriction, and Exchange 2000 can't restrict access to individual recipients. Spoofing lets a message sender use someone else's address in the message's From field to impersonate a valid user. Spoofing is easy to do with many email clients as well as by using SMTP commands directly at a command prompt. To overcome these shortcomings, Microsoft took a different approach with Exchange 2003's restricted groups and restricted recipients features.

Exchange 2003's restricted groups feature works by adding a new, optional attribute, called msExchRequireAuthToSendTo, to the distribution group object. If the attribute isn't set for a particular distribution group, Exchange 2003's authentication behavior and delivery is the same as Exchange 2000's would be for that group. However, if the attribute is set, the messaging system must authenticate the sender as a valid user before delivering the message to the distribution group.

This attribute is also present on user objects, so you can now restrict messages sent to a specific recipient by requiring authentication. When a user connects to the SMTP service, Exchange 2003 processes the message in the standard fashion, with one caveat: The transport appends "AUTH=user@domain" to the Mail From: data, as outlined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2554. This data is retained between Exchange 2003 servers. However, the "AUTH=" data is dropped from the Mail From information when Exchange 2003 transmits the message to a legacy server, including Exchange 2000. Assuming that Exchange 2003 authenticates the connection, the transport retains the "AUTH=" data and sets a new property, a flag, on the message to indicate that the sender is trusted. When the message enters the categorization process (specifically, the Categorizer component of Exchange Routing), one of the following actions takes place:

To set delivery restrictions, right-click the distribution group or user in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, select Properties from the context menu, select the Exchange General tab, and click the Delivery Restrictions button to view the Delivery Restrictions dialog box, which Figure 4 shows. Under Accept messages, choose one of four options: the default setting, From everyone, to accept messages from all senders or From authenticated users only, Only from, or From everyone except to restrict messages.

Tools to Protect Your Environment
Microsoft has tightened up message filtering in Exchange 2003. Using the filtering features included in the base Exchange product, administrators can better protect their environments. These features alone won't eliminate all undesirable messages, so third-party tools will still be needed. Restricted groups and restricted recipients further enhance the capabilities of the base system and can prevent external sources from using internal distribution groups or sending to internal-only addressees.