Previous Section  < Day Day Up >  Next Section

Recipe 21.6. Using DNS Blackhole Lists

21.6.1 Problem

You're going nuts, because it seems like all the mail you receive from a certain service provider, or even an entire country, is nothing but spam. You have good whitelists in place, and you want to discard this garbage while wasting as few system resources as possible.

21.6.2 Solution

Postfix makes it easy. Simply list your selected DNSRBLs (DNS blackhole lists) in main.cf, under the smtpd_recipient_restrictions directive:

smtpd_recipient_restrictions =

.....

     reject_rbl_client  relays.ordb.org,

     reject_rbl_client  list.dsbl.org,

     reject_rbl_client  sbl.spamhaus.org

Make them the very last entries in smtpd_recipient_restrictions, if there are other entries. smtpd_recipient_restrictions entries are processed in order, so you want your whitelists and other checks to operate first, to make sure wanted mail gets through.

21.6.3 Discussion

Selecting a DNSRBL is a process on which you should spend a bit of time. Read their policies, and check out their user forums. Everyone has different criteria for listing and de-listing offenders. The Open Relay Database (http://www.ordb.org) is reliable, though spammers do not exploit open relays now as much as they used to. Spamhaus and Spamcop are fairly conservative; SPEWS (Spam Prevention Early Warning System) is the most hard-core and unforgiving. There are many others; start your research with these three, and do a bit of Googling to find more. You won't block all spam with blocklists, they're just one tool in your kit.

The good part about DNSRBLs is that discarding traffic at the SMTP level places the least load on your server. Spam floods have crashed many a server, or acted as denial-of-service attacks. Heading 'em off at the pass conserves your bandwidth and system resources. The bad part is that it's Draconian—you will lose legitimate mail.

Here's a quick lesson in how DNSRBLs work. Depending on the criteria established by the DNSRBL maintainer, individual IP addresses or entire netblocks are added to the blocklist. The idea is not to simply block traffic from spammers, because it is impossible to block only spammers at the IP level. (It's impossible to block only spammers at any level.) Spammers buy entire blocks of IP addresses, then shift their operations from one netblock to another, leading you in a frustrating game of "whack a mole." There are two goals: to block unwanted traffic, and to put pressure on the service providers to get rid of the spammers. Blocklists are effective in both respects. If it were not for blocklists, spam would be even worse than it is now, if that's conceivable.

Unfortunately, the effectiveness of DNSRBLs has been diluted by the proliferation of compromised Windows PCs. This has created a huge, distributed pool of spam-spewing proxies, so it's harder to block spammers at any level.

If you expect to receive mail from strangers—for example, you have contact information on your web site for potential customers—don't use blocklists. You're better off relying on SpamAssassin (see Recipe 21.9 and Section 21.10).

Spammers and service providers who are affected by DNSRBLs scream bloody murder, calling it an infringement of their free speech rights and all sorts of other nonsense. However, it's your server and your rules, and they have no right to trespass.

21.6.4 See Also

    Previous Section  < Day Day Up >  Next Section