WinDeveloper IMF Tune

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Real-Time Block Lists in Exchange 2003

Alexander Zammit

Alexander Zammit Photo

Software Development Consultant. Involved in the development of various Enterprise software solutions. Today focused on Blockchain and DLT technologies.

  • Published: Oct 12, 2006
  • Category: Anti-Spam
  • Votes: 5.0 out of 5 - 6 Votes
Cast your Vote
Poor Excellent

Real-Time Block Lists identify hosts from which spam and other unwanted emails are distributed. Our journey will cover understanding how RBLs work, some tips on selecting the list provider, and Exchange 2003 configuration.

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:

DNSstuff

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

Message Delivery Properties

Connection Filtering

Click on Add to subscribe to a new RBL.

RBL configuration

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.

RBL Status Code

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.

Recipient Exceptions

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

User Comments - Page 1 of 1

shawn 7 Jun 2011 11:37
Exchange 2011 Real-time Block Lists
A real-time block list (RBL) is a method of stopping spammers from being able to send out large quantities of distasteful spam. A real-time block list is managed and maintained by an organization (company, non-profit, or volunteers) who track spam activity and create a list of known violators. Violations can include SMTP configurations to being caught sending spam. Once you are on their list, you can typically request removal. Some site will publish email addresses and all messages received to that email address is spam.
When a computer connects to your Exchange server, Exchange will query the specified real-time block list. If the address is on that list, Exchange will generate an error and refuse the message. The server that was trying to send the spam is then responsible to generate a non-delivery report and send it the sender. This will eventually lock up the sending server until their open relay is detected and resolved.
For a list of real-time block lists, please refer to the Wikipedia article:
http://en.wikipedia.org/wiki/Comparison_of_DNS_blacklists
Setup
The process is the same for Exchange 2008 and Exchange 2010.
To setup a RBL, open Exchange Management Console – the GUI, and under Organization Configuration select Hub Transport. Select the Anti-Spam tab and right click IP Block List Providers selecting Properties. You can add lists and set them up here.

www.internetworkconsulting.net


Alexander Zammits 14 Aug 2009 01:27
Please always check the site of the RBL provider for configuration details.

For example changes at spamhaus today recommand the use of:
zen.spamhaus.org

Instead of:
sbl-xbl.spamhaus.org
Copyright © 2005 - 2024 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation