Exchange 2003 supports blocking spam through RBLs out of the box. Today we take a closer look at this filtering service. We see how RBLs work and how to configure these in Exchange.

In the Exchange 2003 documentation you will see RBL standing for Real-time Black List. However this acronym also stands for other similar definitions. The Mail Abuse Prevention System (MAPS) was the first providing such a service and defined RBL as Real-time Blackhole List.

Apart for RBL you may also meet other acronyms such as XBL and SBL. Different naming may indicate differing list generation processes or listing criteria. However all have a common goal, identifying hosts used for the delivery of spam and other unwanted emails.

RBL Basics

RBL providers identify hosts to be listed by proactively scanning the internet or through reporting from ISPs and users. Misconfigured machines acting as open relays or open proxies are quickly discovered by both spammers and list providers. Zombie machines are netted either through their open backdoors or on starting spam distribution. Cooperative ISPs may also contribute to RBLs. These supply their range of dynamically allocated IPs forcing such hosts to only submit emails through their servers.

Setting up an RBL is not that difficult. The challenging part is maintenance. Tracking hosts under spammer control is a continuous chase. New machines get infected, unknowingly joining the army of zombies. Misconfigured servers provide new open relays whilst other configurations are corrected. The ability to handle such a dynamic landscape is what makes all the difference between RBLs. A well maintained RBL should have a fast and reliable mechanism for verifying, adding and removing host listing.

It is worth underlining the last point. RBLs are not all the same. Trusting an RBL that is not properly managed generates false positives and loss of legitimate emails. For example RBLs that rely heavily on user reporting, without adequate verification, may be easily abused.

How RBLs Work

A good starting point for anyone interested in RBLs is the DNSstuff site. Using their Spam Database Lookup tool allows to quickly submit an IP to various RBL providers. Apart for seeing RBLs in action, we may also verify our own servers. Here is an example:

The list of RBL providers is long. Some well known names include SpamHaus, SpamCop and MAPS (today part of TrendMicro).

RBLs are hosted within DNS servers. Thus an RBL lookup boils down to a DNS query. The DNS is populated with A (host) records for each IP to be blocked. Constructing a query requires combining the list provider DNS suffix with the IP to be verified as follows:
<Reversed IP>.<RBL DNS suffix>

As an example, to query SpamHaus we could use the suffix:
sbl-xbl.spamhaus.org

To verify the IP 12.34.56.78, we would then query for:
78.56.34.12.sbl-xbl.spamhaus.org

If the IP is not listed, the query fails and the email is allowed to go through, as far as RBL filtering is concerned. Otherwise the DNS server returns a result of the type:
127.0.0.x

The last digit may provide additional information on the type of RBL match. The possible values and their meaning are defined by the RBL provider. For example SpamHaus defines 127.0.0.2 to identify hosts listed on their SBL and describes this as "Direct UBE sources, verified spam services and ROKSO spammers". On the other hand 127.0.0.4 to 127.0.0.6, identify hosts on their XBL listing exploited machines.

Configuring RBLs in Exchange 2003

In Exchange 2003 RBL configuration starts from:
Global Settings | Message Delivery | Connection Filtering

Click on Add to subscribe to a new RBL.

In the Connection Filtering Rule dialog that opens we need to fill in the Display Name and Provider DNS Suffix fields. The Display Name could be anything, but I would suggest entering the name of the RBL provider. The DNS suffix is specific to the list provider, for example SpamCop uses bl.spamcop.net, SpamHaus sbl-xbl.spamhaus.org etc.

On matching an RBL, the default rejection says:
<IP address> has been blocked by <Display Name>

This is a good response. It provides blocked legitimate senders with relevant information, allowing them to rectify the problem.

In the Connection Filtering Rule dialog click on the Return Status Code button.

From here we can customize RBL matching based on the 127.0.0.x code returned for a successful lookup. This customization is provider specific. In general we would keep the default settings i.e. emails are rejected whenever matching the RBL independently of the return code.

The option 'Match Filter Rule to the Following Mask' could be used to match multiple status codes with one setting. For example entering 127.0.0.3 would allow matches against status codes 127.0.0.1 and 127.0.0.2. Any other status code would not be matched and the email is allowed to go through.

The 'Match Filter Rule to Any of the Following Responses' option is more intuitive. Here the specific status codes to be matched are entered one by one through the list interface.

This completes the basic RBL configuration. If necessary you can repeat the same steps to subscribe to additional RBL services.

RBL Exceptions

Getting back to the main Connection Filtering property page we can configure Recipient and IP base exceptions. Clicking the Exception button brings the recipient exception list dialog. Here enter the recipient addresses whose emails are to skip RBL filtering. This can be useful for mailboxes receiving highly critical emails, where false positives cannot be tolerated.

The IP Accept and Deny lists also work in combination with RBLs. The lists identify hosts whose emails are to be always accepted or rejected. Emails originating from hosts on the IP Accept list skip RBL processing. Configuring these lists was discussed in depth in an earlier article, Connection Filtering IP Accept List in Exchange SP2.

Enabling Connection Filtering and RBLs

Once connection filtering is configured, it is necessary to enable it on each of the SMTP Virtual servers. Again Connection Filtering IP Accept List in Exchange SP2 goes through the necessary steps.

Applying RBLs behind the Network Perimeter

As long as Exchange is directly handling internet originating email, the IP to be looked up at the RBL is readily available. Otherwise when sitting behind some other SMTP host, the necessary IP must be extracted from the email headers. For this to work the range of local IPs must be configured within Exchange under:
Global Settings | Message Delivery | General

Once again Connection Filtering IP Accept List in Exchange SP2 goes through the configuration details.

References

TechNet: Exchange Server 2003 Real-Time Block Lists

Connection Filtering IP Accept List in Exchange SP2