Summersault Blog

A Realtime Blackhole List (RBL) is a list of computers on the Internet that made it onto the list because they were caught spamming, sending out viruses, or some other unsavory activity that met the list maintainer's standard for being listed. Mail service providers all over the Internet then use these lists to decide whether to accept or reject mail from those listed computers (or, in many cases, just "tag" mail from those computers as suspect). As Summersault has continued to rely more heavily on RBLs for keeping out unwanted junkmail and viruses, we've also increasingly found the need for being able to maintain exceptions to those lists. This post talks about how to setup your own RBL system for listing those exceptions.

In the past, exceptions were difficult to handle. If a contact of one our e-mail account holders couldn't get a message through, we had to advise the sender to contact their ISP to resolve the issue and get off the list, or in the worst cases, stop using that list altogether, which let in a new flood of spam. If we wanted to explicitly blacklist a set of addresses that weren't on any of the RBLs we were using, we had to do it at the firewall level, or otherwise outside of the normal mail infrastructure. By combining a piece of free software specifically meant for easily maintaining RBLs with our existing DNS setup, we now have complete control over what computers are explicitly blocked and which ones are explicitly let through, in addition to (and with authority over) what the maintainers of the third-party RBLs are doing.

The "rbldnsd" program is the critical piece of glue that makes this so easy. Maintaining an RBL-style DNS zone file by hand without would be a nightmare, but it plugs easily into our existing infrastructure with little additional configuration needed.

rbldnsd runs on a local IP address that our existing DNS server (BIND) can query, but it's also possible to run it on a shared IP with its own port, or whatever works best for you. The rbldnsd daemon is invoked when the server starts, and from there it automatically reads the zone files "once in a while" without having to be restarted. This means that managing listings is as easy as editing a text file and saving it.

We run two lists, a blacklist ("bl.summersault.com"), and a whitelist ("wl.summersault.com"). Don't bother querying them, they're closed to outside use. To get DNS queries working for these zones (which don't need any other DNS entries other than DNS lookups), we first create the needed entries in our summersault.com zone file:

Then, we configure BIND to forward any queries for these two zones on to rbldnsd:

where "192.168.1.100" is the IP address that rbldnsd is running on.

The last step is telling our SMTP servers to use these lists in addition to any other third party list we may be using. Since we're using the qmail mail server, we do this via our entries in the tcpserver call to rblsmtpd (if you don't know what I'm talking about here, don't worry about it; the invocation of the lists will be specific to your setup):

Note that the call to the whitelist ("wl") has to come first for it to have any effect. That's it - now all we have to do is put the entries we want to black- or white-list into the appropriate rbldnsd zone file. For example, in our bl.summersault.com list, we have entries like this:

The comment on the right will actually be returned to the "offending" SMTP server as a part of the connection refusal; many ISPs return a URL that explains the rejection in more detail, but since we're just using this for the most egregious offenders, we don't have any thing that elaborate yet.

I hope this is helpful - it sure has made using RBLs a much more "fun" part of controlling our spam problem, and it has helped us continue to reduce the amount of junk our hosting clients have to deal with.

There's a related howto on this topic that covers more specifics related to mirroring an existing zone file locally, but a lot of the configuration will be applicable if you want to run your own.

This entry was posted on Monday, April 25th, 2005 at 1:56 pm and is filed under Sysadmin / Hosting, Internet / Networking. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.