Exchange Server 2003 introduces a new feature: the ability to integrate Real-Time Block Lists (RBLs)—aka DNS block lists—into your Exchange environment. Exchange implements this feature by letting you configure connection-filter rules that incorporate RBLs. Typically, you'll use an external list maintained by a third-party RBL provider such as Distributed Server Boycott List (http://www.dsbl.org), Mail Abuse Prevention System (MAPS—http://www.mail-abuse.org), or Domain Name System Real-time Black List—DNSRBL (http://www.dnsrbl.com). However, you can also create your own RBL. Creating a simple DNS block list can be an excellent means for testing RBLs and getting a feel for how best to use them in your organization. Let's look at how block lists work and step through the process of creating a test list that you can use in your Exchange 2003 environment.
Block List Basics
The standard RBL operates as a DNS zone that filters out the IP addresses of known spam originators according to set criteria (e.g., multiple recipients have reported the address as a spam source, the source is a dial-up subnet of an ISP from which all dial-up subnets are blocked). These criteria can differ from one RBL provider to another, so you'll want to test RBLs before implementing them so that you can find lists that use criteria appropriate to your environment.
To catch spam, the RBL consumer (i.e., Exchange) reverse maps the IP address of an incoming message, then creates a DNS query that contains the address. Exchange passes the query to connection-filter rules that you configure and apply to each SMTP virtual server that deals with external messaging traffic for your organization. Each rule is associated with an RBL, which the rule queries to determine whether the incoming message's IP address belongs to a known spam source. Exchange 2003 lets you use multiple RBLs by associating each list with a separate connection filter.
If the RBL lists the source address as a spam source or another problematic source (e.g., an open relay), the RBL returns a DNS A record (also called a host record) that contains a "status code" IP address. This status code indicates the incoming IP address's source type (e.g., open relay, confirmed spam source). The default code is 127.0.0.1, but RBL providers can use other codes (e.g., 127.0.0.2, 127.0.0.9) to specify the type of source; Table 1 lists some source types. Be aware that status codes vary according to RBL provider (e.g., one provider might use 127.0.0.4 to indicate an open relay, whereas another provider might use that code to indicate a confirmed spam source), and each RBL might assign a different code to the same IP address. You can configure a connection-filter rule to block messages from systems that return specific status codes, or you can configure the rule to match any return code. When the rule encounters a source address that returns a status code from the RBL, the rule instructs Exchange to drop the connection and generate a nondelivery report (NDR).
Setting Up DNS
Creating your own RBL is simple; you just need to set up DNS properly. First, set up an Exchange test server to function as a test spam server and assign it an IP address. I used the address 10.10.2.227 and placed my test spam server in an organization called bottom.tst. Next, use the Microsoft Management Console (MMC) DNS snap-in on a DNS test server to create a new forward lookup zone for your test RBL. As Figure 1 shows, I created a zone called MyBlockList.tst.
Next, you need to configure the RBL to include a node that identifies the test spam server's IP address. (If you use a third-party RBL, the provider supplies you with its DNS zone suffix so you can perform queries against that provider's RBL.) From the DNS snap-in, right-click the MyBlockList.tst object and select New Domain from the context menu. Create a new zone (domain) for the first octet of the IP address. Repeat the domain-creation process to create a subzone for the second octet within the first octet, a subzone for the third octet within the second octet, and a subzone for the fourth octet within the third octet. (Figure 2 shows this process at the third octet.)
Now, you need to create a host (A) record that identifies the IP address as a spam source. When queried, the record will return the status code address 127.0.0.1. Right-click the fourth octet (227) and select New Host from the context menu. Give the host record an IP address of 127.0.0.1, as Figure 3 shows.
The DNS portion of the job is complete. Now, a reverse query of a message coming from the sample spam node (10.10.2.227) will return a positive host record result of 127.0.0.1 and causes an appropriately configured connection filter to drop the connection from the spam server. The next job is to configure an Exchange connection filter to do just that.
Playing by the Rules
To complete RBL integration, you need to create a connection-filter rule. You then need to configure the rule with the DNS suffix of your RBL provider and the return status code that you want the rule to catch. (If you want, you can also specify a custom error message for the rule to return; in this example, I used the default error message.)
To create the rule, open the MMC Exchange System Manager (ESM) snap-in on an Exchange test server (a different server from your test spam server), navigate to the Global Settings folder, and open the Message Delivery Properties dialog box. Go to the Connection Filtering tab and click Add to open the Connection Filtering Rule dialog box, which Figure 4 shows. In the Display Name text box, enter a name for the rule. Use something descriptive; the display name will be included in the default NDR that Exchange returns to the sender. In this example, I named the rule "The TOP's block List (Gotcha!)" because my Exchange test server is in the organization top.tst. In the DNS Suffix of Provider text box, enter the name of your DNS RBL zone (i.e., MyBlockList.tst); if you use a third-party provider, you enter that provider's DNS suffix. If you want the rule to look for a specific status code, click Return Status Code to specify that code. Otherwise, the filter will catch any code by default. Note the Disable this rule check box near the bottom of the dialog box. I explain how to use that check box later when I discuss testing the filter's operation.
Before the filter rule can take effect, you need to apply the filter to your SMTP virtual server. To do so, open the virtual server's Properties dialog box, go to the General tab, and click Advanced. Select the virtual server IP address, click Edit, and select the Apply Connection Filter check box, as Figure 5 shows.
The DNS RBL in Action
Now that you've completed the configuration of your test RBL, does it work? To find out, send a message from the spam server to your Exchange test server while the filter is disabled and again while the filter is enabled.
Open the Connection Filtering Rule dialog box for the rule you created. Select the Disable this rule check box and close the dialog box. Then, send a message from the spam server to your Exchange test server. The message should arrive without a problem. Now, clear the Disable this rule check box to reenable the rule, then send another message from the spam server. Figure 6 shows the desired result—an NDR that includes the name of the filter rule and proves that your test RBL and filter rule are working.
One More Stumbling Block for Spam
Exchange 2003 offers plenty of ways to fight spam—including DNS block lists. Testing the operation of these lists and the connection-filter rules that implement them will help you better understand how you can best use RBLs in a real-world scenario. For more information about Exchange 2003's antispam capabilities, see "Resources."
| RESOURCES |
| You can obtain the following articles from Exchange & Outlook Administrator's Web site at http://www.winnetmag.com/microsoftexchangeoutlook. |
|
DONALD LIVENGOOD "Filtering Messages in Exchange 2003," January 2004, InstantDoc ID 40756 |
|
TONY REDMOND "Suppressing Spam," October 2003, Web Exclusive, InstantDoc ID 40469 "Antispam Support," June 2003, InstantDoc ID 38931 |
|
PAUL ROBICHAUX "Troubleshooter: Using Exchange 2003's RBL Feature," December 2003, InstantDoc ID 40384 Secure cell phones, PDAs, and other handheld devices with Exchange 2003's Exchange ActiveSync and OMA |
