Choosing a Good DNSBL

stry_cat submitted a story about selecting a good DNSBL. It talks about some of the problems with DNS blacklists and the sorts of things that you should be looking for. Things like Speed, Selection Criteria, and Goals make the list. And of course not requiring payment to be removed from the blacklist.

Comments

Al Iverson is your FRIEND.

[seebs]

http://stats.dnsbl.com/

Or, for commentary:

http://www.dnsbl.com/

Absolutely the best resource on the topic.

These work well for me

[SCHecklerX]

@rbl = relay_is_blacklisted_multi_list($ip, 8, 0,
                [
                'zen.spamhaus.org',
                'combined-HIB.dnsiplists.completewhois.com',
                'list.dsbl.org'
                ]
        );

I reject on these in mimedefang's filter_sender routine, since they provide straightforward methods for removal. For other lists, spamassassin will raise score accordingly, and will raise score based on any blacklisted stuff in the headers (not just the server handing off to you) which is nice.

Greylisting kills a lot of stuff too.

Requiring payment for delisting

[dbolger]

I used to work in the abuse department of an ISP which had been blacklisted by SORBS. SORBS require a "donation" to get your IP range off their list, and since we refused to hand over extortion money to these gangsters, there was no way for us to deal with them. Despite our best efforts, we also found that there was no way to get in contact with them, and as such no way to help our customers.

Doing a Google search for information about this lot brought up so many horror stories that I can't fathom how so many people ended up using their "service". It got to the stage where if we had a customer having trouble with SORBS blocking their mail, the only advice we could give was to contact their recipient via other means and ask them to stop using these thugs to filter mail.

Local Whitelisting!

[HitekHobo]

Choosing a good DNSBL (or three!) is definitely important, but IMHO, you should NEVER run DNSBL's without building a local override into the system. We run our own DNSWL (dns whitelist) which is consulted before hitting on BLs... if a customer has had problems with one of their contacts being blacklisted, we can selectively add their IP to the list.

Unrelated to the above, I would also recommend looking at ironport systems if this is a commercial project with a decent sized budget. (I am not affiliated, just a happy customer).

NEVER use a DNSBL as an absolute block...

[HitekHobo]

...unless you have to.

There is a lot of truth to the OP's statements. However, unless you have the budget for a commercial spam filtering application, there are not a lot of good solutions.

Spamassassin is great for what it does, but in high volume environments, you will be throwing so much hardware, bandwidth and electricity at the problem that you'll either give up on filtering at all or break down and buy a commercial solution.

DNSBL's give you a bit of breathing room between the two extremes. Our environment has about a 98% spam catch rate currently with commercial solutions. We have about 150 connections per second AVERAGE.

Our infrastructure could just barely keep up with this load when we were using DNSBL's only. Had we tried to use a spamassassin style tool, we'd have needed quite a bit more infrastructure to handle all of the increased filtering. DNS lookups are pretty cheap compared to the amount of CPU required for context / content filtering.

DNSBL's definitely generate too many false positives, but when the alternative is buying 10x the hardware or having mail take 1-2 hours to be delivered during peak times, I'll take the false positives.

Re:Dynamic IPs / Zombies

[Jeffrey Baker]

Except the blacklists which are supposedly dynamic IPs contain tons of other shit. There is one which contains any IP which reverses to a name containing the letters "dsl". This is pretty stupid since a lot of business DSL lines have static IPs and because Speakeasy business T1 lines also reverse to whatever.city.dsl.speakeasy.net. Other ISPs have the same scheme, and they don't all delegate reverse DNS. I have a business MX hosted on a T1 line that's blocked by some blacklist that Earthlink uses. So I can't send mail from that business to anyone at Earthlink. It's a really stupid policy.

Re:DNSBL for comment spammers?

[wytcld]

Had a bunch of robot spam going through a home-grown PHP comment form - all of it from Russia. So I got the the Russia CIDR list from here and added this:

$testip = $_SERVER['REMOTE_ADDR'];
function ipCheck ($IP, $CIDR) {
  list ($net, $mask) = split ("/", $CIDR);
  $ip_net = ip2long ($net);
  $ip_mask = ~((1 << (32 - $mask)) - 1);
  $ip_ip = ip2long ($IP);
  $ip_ip_net = $ip_ip & $ip_mask;
  return ($ip_ip_net == $ip_net);
}
$CIDRs = file ("/path/to/ru.zone.file");
foreach ($CIDRs as $CIDR) {
  if (ipCheck ($testip, $CIDR)) {
    $act = "view"; // switches to viewing old comments rather than posting new one
    break;
  }
}

It's fast, and when comment spam shows up from other countries I don't care about, I'll block them too.

DNSBLs to feed other tools

[billstewart]

Most DNSBLs have problems, and there are few that I'd trust absolutely, though Spamhaus runs a tight enough shop that I'd trust it. But DNSBLs can be used effectively to augment other tools:

• SpamAssassin weights - most of the DNSBLs are worth a couple of points of SpamAssassin weight; even rabid ones like SORBS can give you some information, and the country-specific ones are also useful here (e.g. mail from China had better not look spammy at all.)
  
• Greylist Augmentation - The big value of DNSBLs is that you can reject mail from the SMTP headers without needing to receive the message body and grind it through CPU-instensive content filtering. But Greylists also do this, and some people have been using DNSBLs to tune their greylists (e.g. if it's on the DNSBL, then tell the sender to call back in an hour instead of 5 minutes.) Among other things, that gives you a way to use the lists of Dynamic-Address broadband users - the home Linux servers will call you back, the zombies won't, so the list gives you information which you might otherwise have to ignore. And country-code DNSBLs can also get forced to wait an extra hour for spammy places that you don't get much mail from.
  
• 
  TMDA Autoresponders - One of the most annoying and effective anti-spam tools is autoresponders that say "I don't recognize your address - respond to this mail and prove you're a human". You could integrate this with a DNSBL - if the mail's not whitelisted, and it's on some DNSBLs, then maybe it gets a TMDA test instead of bit-bucket. It's lower CPU than SpamAssassin.
  
• DNSBL integration with DNS Servers? - One of my pet projects for when I get some copious spare time is to munge a DNS server to check blacklists/whitelists. Trusted or non-blacklisted sites get the MX record for the good mailserver, non-blacklisted sites get the MX record for the heavily-filtered mailserver that occasionally overloads the CPU, blacklisted sites get the MX record for the teergrube or 127.0.0.1. It's certainly not foolproof - many systems are likely to check their ISP's DNS cache before hitting your DNS directly, and if spammers want to do a set of DNS queries from a clean server they could - but at least at the corporate-email level (i.e. where you can afford multiple mail servers) it gives you a way to avoid having your mail server lose mail from legitimate sources because it's overloaded with SpamAssassin CPU load.
  

  
  I originally thought of this back when Open Relays were the popular spam threat - if you get a DNS MX request from an open relay, tell them that the IP address for spambait.yourdomain.com is some other open relay's address. That would let them spend their time sending mail to each other. But spammers moved on to open proxies and then zombies, so that opportunity went away.
  

• You can think of other things.
  

Re:Project Honey Pot's Http:BL

[porneL]

Project Honeypot's http:BL isn't handling dynamic IPs in any special way, so you have to be careful about these (combine with SORBS DUL and take into account age/threat that http:BL reports).

To truly make blacklists useful...

[IGnatius T Foobar]

To truly make blacklists useful, you've got to filter not only mail coming from IP addresses listed within them, but also mail containing URL's that resolve to IP addresses listed within them. Once you implement this, you will see a *dramatic* drop in spam. Spammers can move their delivery systems from place to place, but at some point they've got to advertise a web site. Yes, the stock spam will still get through, as well as some others, but over the years I've spent administering (and developing) email systems, this was the single most effective thing I've ever seen.

Happily, these tests are already present in SpamAssassin; they're just not scored highly enough. Here's a nice easy way to fix that. Edit your /etc/mail/spamassassin/local.cf and add these lines:

# High score for URL's whose IP addresses are in rbl
score URIBL_AB_SURBL 10
score URIBL_JP_SURBL 10
score URIBL_OB_SURBL 10
score URIBL_PH_SURBL 10
score URIBL_SBL 10
score URIBL_SC_SURBL 10
score URIBL_WS_SURBL 10

Restart spamd, and you will immediately see a large drop in spam.