Recipe7.22.Using a DNS Block List on Exchange Server 2003

Recipe 7.22. Using a DNS Block List on Exchange Server 2003

Problem

You wish to use a DNS-based block list (DNSBL) to help filter and reject incoming spam.

Solution

Using a graphical user interface

1. Open the Exchange System Manager (Exchange System Manager.msc).

2. Expand Global Settings, right-click Message Delivery, and select Properties. Click the Connection Filtering tab.

3. Click Add. Fill in the display name of the DNSBL you are configuring and put the lookup zone in the DNS Suffix of Provider field.

4. If you wish to use a custom error message, fill it in. The default is <IPAddress> has been blocked by <DNSBL Display Name>.

5. If the DNSBL returns multiple result codes and you wish to configure which ones you will actually block on, click Return Status Code. Select the appropriate option (usually Match Filter Rule to Any of the Following Responses), fill in the corresponding mask or response codes, and click OK.

6. Click OK to return the Connection Filter tab.

7. If you have certain addresses that you want to be able to continue to receive email this DNSBL would otherwise block, click Exception. Click Add and fill in the exempted addresses. Click OK to close the exemption box.

8. Click OK.

Discussion

DNSBL support is a new feature in Exchange Server 2003 that can have tremendous impact on reducing the amount of spam that enters your organization. There are literally hundreds of blocklists being run around the world; before using any of them, do some research to find out their purpose, listing criteria, delisting criteria, and maintenance policies. Some return multiple result codes to allow you to combine queries for multiple lists into one aggregated zone and still know which source list caused the hit. As an example, on such a list a return value of 127.0.0.1 might signify that the host was added to the list by one source, while 127.0.0.2 was from a second source.

DNSBLs can produce a performance hit on busy systems; they are making one DNS query for every configured DNSBL for every incoming SMTP connection, subject to normal DNS caching. If these queries are to servers outside of your network and over your WAN, the delay could add up (as could the bandwidth). It is generally best to use as few DNSBLs as possible.

You should always program an exception for RFC-required role accounts such as postmaster@domain and abuse@domain (see Recipe 7.24 for details) so that external senders who are trying to send mail through to your users can contact you. You might also consider putting up a web site that explains which block lists you use and ways to request whitelisting and referring to that page's URL in a custom error message.

Depending on the number of block lists you query and your traffic volume, you may want to look into the possibility of creating your own DNSBL and feeding by concatenating the data from several block lists together. Doing so has many benefits:

• You can host the zone(s) on a server that is network-close to the Exchange server performing the queries, cutting down the query latency.

• You can prefilter the block list data to remove entries you do not wish to use.

• You can combine multiple lookup zones and block lists into a single zone, thus reducing the number of queries and configured block lists.

Recipe 10.7 has more details on creating a custom DNSBL.

See Also

Recipe 10.7 for creating a custom DNSBL, Chapter 10 of the Exchange Server 2003 Transport and Routing Guide, Chapter 8 of Secure Messaging with Microsoft Exchange Server 2003 (Microsoft Press), and MS KB 823866 (How to configure connection filtering to use Realtime Block Lists and how to configure recipient filtering in Exchange 2003)