Recipe 21.5. Creating Whitelists

< Day Day Up >

Recipe 21.5. Creating Whitelists

21.5.1 Problem

Because you are setting up all kinds of mail filtering and virus-scanning measures, you are worried about losing wanted mail. How can you make sure wanted messages get through?

21.5.2 Solution

Postfix handles this with map files and the smtpd_sender_restriction directive in /etc/postfix/main.cf.

Put your wanted addresses in a plain text file, one per line, like this:

myfriend@mypal.com                  OK

myotherfriend@thatplace.com         OK

mychum@techies.net                  OK

wanteddomain.com                    OK

.wanteddomain.com                   OK

mychum@                             OK

In this example, the text file is named /etc/postfix/whitelist. Now convert it to a nice fast indexed binary database file:


# postmap /etc/postfix/whitelist

Then add this line to /etc/postfix/main.cf :

smtpd_sender_restriction =

     check_sender_access  hash:/etc/postfix/whitelist

Postfix supports three different database formats. To find out which one your system is using, do the following


$ postconf  grep database_type

default_database_type = hash

21.5.3 Discussion

Postfix's database files can be in one of three formats: hash , btree , or dbm . hash and btree have . db extensions. dbm is split into two files, . pag and . dir . hash is usually the Linux default.

Setting up whitelists of important addresses is the first thing you should do when you're setting up any kind of mail filtering. This is an efficient method for ensuring that mail from people or domains that you want to receive mail from will get through.

The format of your whitelist is based on the /etc/postfix/access file. The check_sender_access directive compares the whitelist to the MAIL FROM command during the SMTP transaction (this command, of course, can be spoofed, but it's still a useful check). The example in this recipe demonstrates three types of address selection:

Everything from one user at one address: myfriend@mypal.com
Everything from a single domain: wanteddomain.com
Everything from a domain, including subdomains (note the leading dot): .wanteddomain.com
Everything from a single user, from any domain: mychum@

OK means accept the message.

21.5.4 See Also

RFC 2821, for a complete description of SMTP commands and codes
Recipe 20.19
Postfix's SMTPD_ACCESS_README and access(5)
Chapter 11 of Postfix: The Definitive Guide

< Day Day Up >

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 Draconianyou 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 strangersfor example, you have contact information on your web site for potential customersdon'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.