Stop Spam With Exchange 2003
How to defend your users against unwanted e-mail using the Realtime Blackhole List.
by Scott Schnoll

Posted February 23, 2004

About This Article
This article is adapted from the forthcoming book Microsoft Exchange Server 2003 Distilled by Scott Schnoll. Copyright © 2004 by Addison-Wesley. Reproduced by permission. All rights reserved.

The best way to prevent spam from being delivered is a defense-in-depth approach, which includes the new filtering mechanisms in Exchange 2003, as well as third-party software and its filtering/blocking mechanisms. The multiple scanning and filtering layers often include firewalls, dedicated SMTP gateways for scanning, and other perimeter defenses. In addition, they also include filtering at the Exchange server level. We start with connection filtering, move on to recipient filtering, and conclude with sender filtering. All three are new Exchange 2003 filtering mechanisms.

As its name implies, connection filtering blocks connections from one or more computers. Previous versions of Exchange included mechanisms for blocking connections based on IP addresses, but there were some downsides, including the fact that you had to enter the information on each individual virtual server running on each separate physical server. In Exchange 2003, you still need to enable filtering on each IP address used by all of your SMTP servers, but you only need to do this once; with the new Connection Filtering feature, the IP deny list is global. Connection Filtering enables you to deny SMTP connectivity based on the IP address of the server attempting to deliver a message to your server. You can manually block a single IP address or a group of them. Connection Filtering also enables you to use third-party blocking services or your own internal blocking service. But this feature is not as clear-cut as it sounds. Before implementing this feature, you should have a solid understanding of how it works and what its limits are.

Note that Connection Filtering rules apply only to anonymous connections and not to authenticated users and computers (such as other Exchange servers in your organization).

First, you'll see the acronym RBL used often. RBL stands for Realtime Blackhole List, and it''s a registered service mark of Mail Abuse Prevention System (MAPS), LLC. These are the folks who started the first block list project, which is now a service they provide. You may also hear and see people, especially other block list providers, use the acronym RBL for realtime block list, relay block list, relay blackhole list, or some other similar variation, in part to avoid stepping on the intellectual property rights of MAPS. Nonetheless, they are all basically the same thing: databases that contain addresses of systems that should be prevented from making connections to your SMTP server.

When a foreign SMTP server connects to an Exchange 2003 SMTP virtual server, the IP address of the foreign SMTP is forwarded in the form of a DNS query to a block list service provider's DNS server to check for the presence of a special resource record. If the resource record is found, the provider returns a return status code, which is a special IP address that translates to a specific meaning, as shown in Table 1. If the foreign SMTP server's IP address is not on the list, the provider returns "host not found."

You can use multiple service providers and configure the order in which they are queried. This provides a kind of fault tolerance in the event that one of them is offline or otherwise unreachable. The service providers are queried one at a time in the order you configured. Because the query process ends as soon as something other than "host not found" is received by a provider, no unnecessary traffic is sent.

Configuring Connection Filtering
After you have subscribed to one or more block list service providers, you can configure Connection Filtering rules. These rules are used to check block lists for IP addresses that should not be allowed to transmit SMTP messages to your Exchange server. To configure Connection Filtering rules, follow these steps: Launch ESM. Select Global Settings in the Scope pane. In the Results pane, right-click on Message Delivery and select Properties. Select the Connection Filtering tab. Click the Add button. The Connection Filtering Rule dialog will appear.

In the "Display Name" field, enter the name you want for this rule. Because this name is used for display purposes in the Block List Service Configuration area of the Connection Filtering tab, you should use a display name that is meaningful, such as the name of the service (however, before you do this, see the note that appears after this list of steps).

In the "DNS Suffix of Provider" field, enter the DNS suffix that your provider appends to the IP address. This typically corresponds to the DNS namespace of the provider. Your provider can give you this information.

In the "Custom Error Message to Return" field, enter an optional custom message that will be returned to the sender when the connection is denied. If you leave this field blank, the following default message will be used: "<Sender's IP address> has been blocked by <Connection Filtering Rule Name>." The default message will also include the following SMTP return code: 550 5.7.1. If you prefer to use a custom message, there are three environment variables you can use in this field, as shown in Table 2. Note, however, that even when using a custom message, the SMTP return code will also be included.

Click the Return Status Code button. The Return Status Code dialog will be displayed. You can choose one of three options for handling return status codes.

Match Filter Rule to Any Return Code: This is the default setting for all newly created rules. Choosing this option triggers the rule for all return status codes. If the sender's IP address is found on an RBL, the service provider responds with one of the return status codes listed in Table 1, and the rule blocks the IP address.

Match Filter Rule to the Following Mask: Use this option to configure a mask that can be used to interpret the return status codes. As you can see in Table 1, the return status codes are generally in the form of 127.0.0.X, with X being the significant value, or in this case, the mask. Although masks provide additional flexibility, there is no standard for using masks, and both the mask and its meaning are unique to each individual service provider's RBL implementation.

Match Filter Rule to Any of the Following Responses: Use this option to configure the rule to match any of multiple return status codes. You'll need to manually add each return status code you want the rule to match. Once again, because the return status codes vary among providers, you'll want to check with your provider(s) before entering a specific return status code. Click the Add button to enter a specific return status code. If you need to change an entry, select it and click the Edit button. To delete an entry, select it and click the Remove button.

Click OK to save your changes on the Return Status Code dialog and return to the Connection Filtering Rule dialog. Note that there is a checkbox on the Connection Filtering Rule dialog that enables you to disable the rule if desired. Click OK to save your settings for the Connection Filtering rule and return to the Connection Filtering tab.

Using Your Own RBL Services
If you don't want to subscribe to a third-party block list service provider, you can create your own custom RBL service using the DNS server that comes with Windows 2000 and Windows 2003. Technically, any DNS server will do, so you can use whatever DNS infrastructure is being used to support Active Directory. To do this properly, you'll need to have a good understanding of how this process typically works. A dissection of how the MAPS RBL system works will help you acquire this understanding.

The MAPS RBL method is simple yet effective, and you can duplicate this method using your own DNS servers. A DNS host record—for example, an (A) resource record—is added to a forward look-up zone in DNS. The host record is entered in the form of a dotted IP address; it uses 127.0.0.X, where X is a mask or value that corresponds to a return status code. The 127.0.0.X code takes the form of an address type typically used for a host's pointer (PTR) record in a reverse look-up zone. The IP address of the unwanted SMTP server is entered in a reversed format. For example, if the IP address of the unwanted SMTP server is 1.2.3.4, the PTR record would be 4.3.2.1. The IP address for this PTR record is then assigned the appropriate return status code (i.e., 127.0.0.X).

To create your own internal service, follow these steps:

Create a new DNS zone that is separate from your Active Directory DNS namespace. Be careful to make sure that the zone does not overlap any zones you're using for Active Directory, or you could end up blocking your own e-mail. That said, you might find it useful to simply create a new child domain from an existing DNS domain. For example, if you have a domain called companyname.com, you can create a DNS zone for rbl.companyname.com.

Next enter host (A) records for each host you want to block. For example, if you want to block an SMTP server whose IP address is 1.2.3.4, you would create an (A) record for 4.3.2.1.rbl.companyname.com and assign it an IP that corresponds to its categorization (e.g., 127.0.0.4 for a confirmed spam source).

You might find that adding a host record each time you have a new address to block is more trouble than it is worth. Unless you find a way to automate the process (and there are ways to do this), you might be better off subscribing to one of the service provider DNS zones. There are some providers, including MAPS, that allow DNS zone transfers of their block lists to your company's private DNS server.

Overriding Connection Filtering Rules
In addition to configuring Connection Filtering rules, you can also configure two different types of exceptions to your rules, both of which are also configured on the Connection Filtering tab: exceptions to block list service rules, and global accept and deny lists.

The Exception option is used to add one or more recipient SMTP addresses you want excluded from the Connection Filtering rules, that is, addresses from which you want to receive messages even if their servers' IP addresses are on one or more RBLs. You're probably thinking right now, "Why would I subscribe to an RBL service that lets me block e-mail and then allow mail from servers on an RBL to be delivered?" In a perfect world, you probably wouldn't do this. But because there are no RBL standards and, more importantly, because there is no guarantee of the accuracy of the entries on the RBL, you may need to add one or more exceptions to the Connection Filtering rules.

Consider the sources of IP addresses stored in an RBL. Typically, each IP address falls into one of three categories: known spammers, dial-up user IP addresses, or open relays.

Known spammers are entries compiled from the headers of known spam, which include the IP address of the server used to send the spam.

Dial-up user IP addresses are entries often obtained directly from ISPs. An ISP interested in helping to stem the tide of spam will give an RBL provider the list of all IP addresses that it assigns (statically or dynamically) to its dial-up users. These addresses are added to block lists because none of them should ever be used to directly send SMTP messages to any server other than the mail server belonging to the dial-up user's ISP. Dial-up users who receive Internet e-mail as part of their Internet service subscriptions receive their e-mail server configuration settings from their ISPs. Unless you have authorized your own dial-up users to do otherwise, dial-up users' systems should send e-mail only through their ISPs' SMTP servers. They should not communicate directly with any SMTP server that services the recipient's domain (unless of course the recipient happens to also be in the same domain as the sender and therefore uses the same e-mail servers).

An open relay is an SMTP server that allows anonymous computers to relay e-mail through it. When you send a message to someone on the Internet, a DNS look-up is performed to locate the MX record for the recipient's domain. The MX record points to an SMTP server, which can be configured to accept and deliver the message (because the SMTP server services that domain), or it can be configured to relay the message to a different SMTP server that is responsible for delivering messages to the recipient's domain. By default, in Exchange 2003, only authenticated users are allowed to relay messages through an SMTP virtual server. This is considered an authenticated relay. If you can authenticate to the SMTP server, it will allow you to relay. If you can't authenticate to the server (because you don't have the proper credentials or because Anonymous Access is allowed, which disables authentication), you won't be allowed to relay, and you will receive a nondelivery report stating that the SMTP server could not relay the message for you.

It is the third type of address—the open relay lists—that provides some justification for configuring one or more exceptions. With limited exceptions, most open relays on the Internet are open because of misconfiguration. Either an administrator configured the server in such a way that he or she inadvertently created an open relay or an organization is using a messaging solution whose out-of-the-box configuration allows anonymous relaying. In either case, using the exception feature is a handy way to temporarily allow e-mail to be delivered to one or more addresses in your organization while the sender's administrator works to close the open relay. In other words, legitimate, nonspam, business e-mail could be blocked by an RBL because the sender's misconfigured mail server has been identified as an open relay and blacklisted.

If you do create exceptions, the best practice recommendation is to use a single address and share that address only with legitimate senders whose e-mail you suspect is being blocked. Once you add this address to the exception list, it will receive messages even if the sender's SMTP server is listed on one or more RBLs. One commonly used address is the Postmaster address for your organization, and another is a standard abuse address (e.g., abuse@somecompany.com); however, I recommend using an address that is not well known or easily discovered through a dictionary attack. Excluding a well-known address from filtering means that you'll end up with a lot of unwanted e-mail in that mailbox.

To configure exceptions, follow these steps. On the Connection Filtering tab, click the Exception button. The Block List Service Configuration Settings dialog will appear. Click the Add button. The Add Recipient dialog will appear. In the "Recipient" field, enter the internal SMTP address you want excluded from the Connection Filtering rules. Click OK to save the entry. You can't edit entries on this list; if you add an incorrect entry, you must delete it and then add the correct entry. To delete an entry, select it and click the Remove button on the Block List Service Configuration Settings dialog. After you have entered your exception(s), click OK to save your changes and return to the Connection Filtering tab.

Global Accept and Deny List Configuration
The global accept and deny lists are completely separate from (and can be used independently of) Connection Filtering rules. You might find, for example, that using the global lists alone obviates the need to subscribe to an RBL service. Before sending any queries to any block list service providers you have configured, Exchange first checks the global accept and deny lists. If the IP address is found on either of the lists, Connection Filtering rules are not processed for messages from that IP address.

If the IP address is found on the accept list, Exchange accepts the message without checking the Connection Filtering rules. If the IP address is found on the deny list, Exchange severs the SMTP connection after the MAIL FROM command is received.

As I mentioned earlier, previous versions of Exchange, including Exchange 2000, contained mechanisms for accepting and rejecting messages based on the IP address of the sending SMTP server. Although this worked well, it meant that you had to enter the IP addresses separately for each SMTP virtual server to which you wanted the list to apply. Every time you wanted to add or remove an entry from the list, you had to either manipulate the list programmatically or modify the list on each SMTP server using ESM. In Exchange 2003, the accept and deny lists have been globalized. You still need to enable filtering on each individual SMTP virtual server, but that is a one-time task, not a repeated task. More importantly, there is just one global accept list and one global deny list that need to be managed. Instead of adding or removing entries from each SMTP server, you now add and remove them once, and they are globally applied to all SMTP virtual servers that have filtering enabled.

Configuring an accept list or a deny list is done the same way. The only difference is they have opposite effects. To configure an accept or deny list, follow these steps: In the Global Accept and Deny List Configuration area on the Connection Filtering tab, click the Accept or Deny button to add an entry to the accept or deny lists, respectively. Depending on which button you clicked, either the Accept List or the Deny List dialog will appear. Click the Add button. The IP Address (Mask) dialog will appear. You can enter a single IP address by selecting the "Single IP Address" radio button and entering the address in the "IP address" field, or you can choose to enter a range of addresses by selecting the "Group of IP Addresses" radio button and then entering a subnet address and subnet mask for the range you want to add.

Click OK to save your changes and return to the Accept List or Deny List dialog. If you want to make additional entries, click Add and repeat the process. Here again you can't edit entries, so if you make a mistake, you must first select the incorrect entry and click the Remove button to delete and then use the Add button to enter the correct entry.

When you have finished adding entries, click the OK button to return to the Connection Filtering Rules dialog.

After you click OK to save your changes and exit the Connection Filtering Rules dialog, you'll receive the following message: "Connection, Recipient, and Sender Filtering must manually be enabled on specific SMTP virtual server IP address assignments as they are not enabled by default. For more information on how to enable any of the above filtering types, read their associated help." Click OK to acknowledge this message.

After configuring Connection Filtering, the next step is to enable Connection Filtering on the desired SMTP virtual servers (typically the edge or border servers, e.g., the ones that accept Internet e-mail). To do this, follow these steps.

1. Launch ESM.
2. Expand Servers, and then expand the Exchange server that contains the SMTP virtual server you want to configure. If you have Administrative Groups displayed, you will first expand Administrative Groups, then the Exchange Site, and then Servers.
3. Expand Protocols, and then expand SMTP.
4. Right-click on the SMTP virtual server you want to configure and select Properties. The Default SMTP Virtual Server Properties dialog will appear.
5. On the General tab, click the Advanced button. The Advanced dialog will appear.
6. You must enable filtering separately for each IP address listed in the "IP Address" column of the "Address" field. Select one of the addresses or, if configured, select "(All Unassigned)," and click the Edit button.
7. The Identification dialog will appear. Check the box that says "Apply Connection Filter," and then click OK to save the change.

Repeat steps 6 and 7 as necessary, and then click OK to save the changes on the Advanced dialog. Click OK to close the SMTP Virtual Server Properties dialog.

Recipient Filtering
As its name implies, Recipient Filtering is used to filter (block) messages sent to a specific address. In Exchange 2003, Recipient Policies control incoming messages by accepting messages for specific SMTP domains only (e.g., yourcompany.com). This prevents you from receiving messages destined for someothercompany.com, but it won't prevent Exchange from accepting messages for bogusaddress@yourcompany.com. This is where Recipient Filtering helps. This new feature enables you to filter recipients two ways.

You can block all recipients that are not in your Active Directory. This feature is useful because it eliminates not only messages sent to bogus addresses in your organization's SMTP namespace but also messages sent to former employees (e.g., addresses that used to be valid but no longer are). For example, how many of you are getting mailing list messages from lists that former users subscribed to but did not unsubscribe from? In the absence of filtering, each time Exchange receives one of these messages, it accepts it, determines that the recipient is not in Active Directory, and blocks the message.

You can also block any properly formatted SMTP address, whether real or not, even if it is in your directory. Like Connection Filtering, Recipient Filtering doesn't apply to authenticated users and computers in your organization. Therefore, this feature enables you to block external e-mail without affecting internal e-mail. Even if you don't have a spam problem, you can use this feature to block incoming Internet e-mail for one or more users.

Recipient Filtering is implemented as an SMTP protocol event sink called the Turf List Transport Sink. The Turf List Transport Sink uses the information in the SMTP RCPT TO: command. If Recipient Filtering is enabled, each time an SMTP virtual server receives the RCPT TO: command, the data transmitted in that command (e.g., the recipient address) is compared to a list of addresses that should be filtered. If the address is on the filter list, the SMTP virtual server will return "550 5.7.1 Requested action not taken: mailbox not available."

The process is only slightly different if you use this feature just to filter addresses that are not in your Active Directory. Filtering of addresses that are not in Active Directory is done by performing a directory look-up for each address listed in the RCPT TO: command. If a match is found, the address is cached in Exchange's DSAccess cache. In this cache are results from recent directory look-ups. Because internal Exchange components that perform recipient resolution, such as the Message Categorizer, look to the DSAccess cache before performing the directory look-up, the amount of overhead introduced by using this feature is minimized.

Configuring Recipient Filtering is very similar to configuring Connection Filtering. First, you configure the global setting (i.e., the filter), and then you enable the filter on the desired SMTP virtual servers. To do this, follow these steps: Launch ESM. Select Global Settings in the Scope pane. In the Results pane, right-click Message Delivery and select Properties. Select the Recipient Filtering tab.

If you want to block messages addressed to recipients who are not in your Active Directory, check the box that says "Filter recipients who are not in the Directory." If you want to block messages addressed to one or more recipients, start by clicking the Add button. The Add Recipient dialog will appear. You can enter recipients using any of the following formats:

Properly formatted SMTP addresses (whether valid or not): For example, you can enter someone@somewhere.com, me@you.local, no@one.here, and so on. The key here is the presence of the @ symbol. Anything@anything will work in this dialog.

Wildcard addresses (again, whether valid or not): You can use this format to block an entire domain (e.g., *@buymorejunkrightnow.com or *@*.knownspammer.com).

Quoted display names: Some spammers have figured out how to strip off the SMTP from the address portion of the message headers, leaving you with just a display name. You can add this display name to the Recipient Filter list.

Click OK to add the address to the recipient filter list. To enter an additional address, click the Add button and enter the address. To change an entry, select it and click the Edit button. To delete an entry, select it and click the Remove button.

Click OK to save your changes. You'll receive the following message: "Connection, Recipient, and Sender Filtering must manually be enabled on specific SMTP virtual server IP address assignments as they are not enabled by default. For more information on how to enable any of the above filtering types, read their associated help." Click OK to acknowledge this message.

After configuring Recipient Filtering, you must enable filtering on the desired SMTP virtual servers by following these steps.

1. Launch ESM.
2. Expand Servers, and then expand the Exchange server that contains the SMTP virtual server you want to configure. If you have Administrative Groups displayed, you will first expand Administrative Groups, then the Exchange Site, and then Servers.
3. Expand Protocols, and then expand SMTP.
4. Right-click on the SMTP virtual server you want to configure and select Properties. The SMTP Virtual Server Properties dialog will appear.
5. On the General tab, click the Advanced button. The Advanced dialog will appear.
6. You must enable filtering separately for each IP address listed in the "IP Address" column of the "Address" field. Select one of the addresses or, if configured, select "(All Unassigned)," and click the Edit button.
7. The Identification dialog will appear. Check the box that says "Apply Recipient Filter," and then click OK to save the change.

Repeat steps 6 and 7 on other SMTP virtual servers as necessary, and then click OK to save the changes on the Advanced dialog. Click OK to close the SMTP Virtual Server Properties dialog.

Sender Filtering
The last filtering feature built into Exchange 2003 is Sender Filtering, which enables you to block messages from specific senders. This option is almost identical to the Sender Filtering feature in Exchange 2000. The only difference is one change: Exchange 2003 includes a new option that enables you to terminate the SMTP connection when a match is found.

You configure Sender Filtering the same way it was configured in Exchange 2000. You create the list of blocked senders, choose filtering options, and then enable the filter on the desired SMTP virtual servers. To do this, follow these steps: Launch ESM. Select Global Settings in the Scope pane. In the Results pane, right-click on Message Delivery and select Properties. Select the Sender Filtering tab. Click the Add button. The Add Sender dialog will appear. You can enter sender addresses using the formats used for Recipient Filtering: properly formatted SMTP addresses, wildcard addresses, and quoted display names. Click OK to add the address to the sender filter list. To enter an additional address, click the Add button and enter the address. To change an entry, select it and click the Edit button. To delete an entry, select it and click the Remove button. Next, put a check in the checkbox for each desired option.

Archive filtered messages: This option will archive a copy of each filtered message to the file system. Archived messages by default will be stored in \Program Files\Exchsrvr\Mailroot\<Virtual Server>\Filter. This folder won't exist unless this feature is enabled. In addition, Exchange doesn't perform any management of this folder. Unless you delete items, this folder will continuously grow and consume disk space. Very bad things can happen to Exchange servers that run out of disk space, so if you enable this feature, you should proactively manage this folder.

Filter messages with blank sender: Obviously, you can block a specific address only if an address is present that can be matched to an entry on the list. In the case of messages with blank FROM lines, there is no address to filter. You can use this option to block messages that meet this condition (which, by the way, is a common practice by spammers).

Drop connection if address matches filter: This option, which is new to Exchange 2003, is used to immediately terminate an SMTP connection being used to send a message that is to or from a blocked address or from a blocked connection. If a match for the recipient in the MAIL FROM: command is found, the sending SMTP server immediately receives "554 5.1.0 Sender Denied," and the SMTP session and connection are terminated.

Accept messages without notifying sender of filtering: If you use the option to terminate connections when a match is found, senders will know they are being blocked because they receive the "Sender Denied" message. Therefore, if you use that feature, the option to accept messages without notifying the sender of filtering will be grayed out and unavailable. If you are not using the option to drop the connection, you can use this option to silently block messages. When this option is selected, messages are accepted and then deleted. Because the messages are not refused, the sender never receives a nondelivery report (which saves resources and bandwidth) and, more importantly, never knows that you did not get the message. That said, with this option you are still accepting messages, which may or may not be a good thing, depending on the size of the message.

Click OK to save your changes. You'll receive the following message: "Connection, Recipient, and Sender Filtering must manually be enabled on specific SMTP virtual server IP address assignments as they are not enabled by default. For more information on how to enable any of the above filtering types, read their associated help." Click OK to acknowledge this message.

After configuring Sender Filtering, you must enable filtering on the desired SMTP virtual servers by following these steps.

1. Launch ESM.
2. Expand Servers, and then expand the Exchange server that contains the SMTP virtual server you want to configure. If you have Administrative Groups displayed, you will first expand Administrative Groups, then the Exchange Site, and then Servers.
3. Expand Protocols, and then expand SMTP.
4. Right-click on the SMTP virtual server you want to configure, and select Properties. The SMTP Virtual Server Properties dialog will appear.
5. On the General tab, click the Advanced button. The Advanced dialog will appear.
6. You must enable filtering separately for each IP address listed in the "IP Address" column of the "Address" field. Select one of the addresses or, if configured, select "(All Unassigned)," and click the Edit button.
7. The Identification dialog will appear. Check the box that says "Apply Sender Filter," and then click OK to save the change.

Repeat steps 6 and 7 on other SMTP virtual servers as necessary, and then click OK to save the changes on the Advanced dialog. Click OK to close the SMTP Virtual Server Properties dialog.

Before implementing connection, recipient, and sender filtering, it's important to understand exactly how they work so that you can avoid false positives. A false positive is a message that was blocked when you wanted it delivered. If you archive filtered messages, this will help you recover false positives and get the message to its intended destination. However, if you receive a large amount of junk mail, you may wish to not archive filtered messages because of the issues of management and disk space consumption. If you don't use archiving, you'll want to double-check all of your configuration settings and changes to make sure you are not blocking wanted mail.

About the Author
Scott Schnoll is the product support manager for TNT Software, a Microsoft Gold Certified Partner in Vancouver, Wash., that specializes in Windows system and network management applications. Scott is an MCSE, an MCT, an MCSA, and a long-time Microsoft MVP. He is a coauthor of the upcoming Exchange 2003 Resource Kit from Microsoft Press, and the lead author for Exchange 2000 Server: The Complete Reference. He also has written numerous articles for Exchange & Outlook Magazine.