Yet Another Broken RBL

with the latest spam surge in progress, admins seem hell-bent on using non-functional methods to fight this. So our legitimate mails get blocked, since we are on particular ISPs. This is nuts.

Ok, I am going to lay into the RBLs here. Unless you have evidence that our IPs have been spamming, you should not try to stop mail. Evidence of spamming is, curiously enough, spam traced back to our IP addresses. Since IP addresses are fungable/forgable in email headers, it is not possible to use IP address ranges as blocks. Hell, I get tons of spam from “legitimate” sources. Its all in how you handle it. RBLs block IP ranges. Remember, since there is no way to ascertain whether or not a particular IP address actually sourced you this mail, this winds up being an arbitrary process. That is, RBLs block particular IP ranges regardless of whether or not they ever sent spam. Those of us, with legitimate servers/businesses which send/receive mail, which happen to fall within one of these arbitrary blocks, are SOL. We are collateral damage. Worse, the purveyors (and for the most part, the users) of RBLs simply don’t care. They (misguidedly) believe that they are fixing a problem. They are wrong. They are substituting one enormous problem for another. If a legitimate user/business has their mail blocked, then you have a false positive in your algorithm. RBLs have a significant false positive rate. Contrast this to greylisting which simply leverages the protocol (doesn’t break it as RBLs do) to force unknown senders to resend. First: Greylisting increases the cost per email sent by the spammer. This is one of the only legitimate counters to spammers, to make the cost of sending much higher that they have an economic disincentive to continue. Second: Greylisting works with all IPs regardless of whether they have or have not spammed. If one IP address appears in the mail system logs as continuously sending spam, you can block that IP address. Finally, RBLs do not address the source of the problem. Windows computers taken over by bot-nets. Arguably, the only way to prevent a windows machine from being remotely exploitable is to never connect it to a network. Another way, which we strongly encourage, is to run the windows system as a virtual machine above Linux where Linux firewalls off all but a few ports, and explicitly denies access to ports from non-legitimate IP addresses. This would make bot-net formation much harder. Alas, the licensing of Vista expressly forbids running it in a VM. Which means you are stuck with Microsoft’s “security.” But that is another post for another day. Not that greylisting helps solve that last point either, but it significantly reduces the effectiveness of a botnet if the botnets success rate at first try connections is close to zero. We can instrument the mailer and message scanner to feed back to the greylist to indicate machines caught trying to send spam. Those can be made to work harder to send real messages (with 450 return codes). The point is that greylisting is a scalpel and RBLs are small thermonuclear devices. Which of these would you prefer to use to extract your mail from the inbound flow? FWIW: We were DDoSed a few months ago. Someone decided to see if they could push us over and sent 2-3 spams per second from a botnet. I was amused to see this. Had we been using RBLs, we would have been pounding the DNS server that RBLs use, which would have appeared as a secondary DDoS. Since we were using greylisting, we easily deflected more than 350,000 spams in 2 days, with no loss of legitimate mail (in or out). No RBLs were used or needed. Please, if your mail systems are still using RBLs, change to greylisting. Your end users will thank you. So will all the people legitimately trying to email you whom have not been able to do so. And the spammers will have to pay more/work harder to get the same distribution levels.