3.5 Whitelists and Blacklists

3.5 Whitelists and Blacklists

Although SpamAssassin generally does a good job of avoiding false positives, you may find that some mail that you want to receive contains enough spamlike characteristics that SpamAssassin regularly tags them as spam. You may want to be sure that SpamAssassin will never mistake email from an important user , client, vendor, or other sender for spam. You may even have users who don't like spam-filtering . SpamAssassin allows you to set up systemwide or user-specific lists of senders whose mail should not be considered spam, and (systemwide) lists of users who don't want their email filtered. Such lists are called whitelists .

On the other hand, you may regularly receive unwanted mail from a particular sender that doesn't get tagged reliably by SpamAssassin. You may know ahead of time that you don't want to receive mail from certain organizations or senders. SpamAssassin also allows you to set up system-wide or user-specific lists of senders whose mail should be tagged as spam. Such lists are called blacklists .

This chapter discusses how to set up whitelists and blacklists. It begins by examining the SpamAssassin directives for systemwide whitelisting and blacklisting, and then explores two different ways to manage user-specific lists. A related feature, autowhitelists, is covered in Chapter 4.

3.5.1 Systemwide Whitelists

SpamAssassin whitelists reduce the spam scores of messages when the sender or recipient appears on the whitelist. Whitelists are most commonly used to ensure that messages from important senders are not marked as spam, but they can also be used to change the spam threshold for recipients or enable recipients to effectively opt out of spam-tagging.

3.5.1.1 Whitelisting senders

Use the whitelist_from directive to whitelist a sender's address. The sender's address is the address that appears in the Resent -From header, if that header exists, or in any of the headers: From , Envelope-Sender , Resent-Sender , or X-Envelope-From . If a sender's address matches a whitelist_from address, the spam score of the message is reduced by 100 points, which makes it nearly impossible for the message to be tagged as spam.

For example, if you receive important messages from [e-mail] , you can ensure that they won't be tagged as spam by using this line in the systemwide configuration file:

 whitelist_from [e-mail] 

You can use multiple whitelist_from directives or multiple addresses in a single directive to whitelist several addresses. You can also use an asterisk (*) as a wildcard for zero or more characters and a question mark (?) as a wildcard for zero or one character, much as you would to specify filename patterns in a shell. For example, you could whitelist all mail from mybigclient.com and from all hosts in the example.com domain with these lines:

 whitelist_from *@mybigclient.com whitelist_from example.com *.example.com 

A whitelist entry can be removed with the unwhitelist_from directive. Because SpamAssassin is distributed with several default whitelist entries (in the 60_whitelist.cf file), you may find that you want to remove some of them. The unwhitelist_from directive is also useful in per-user configuration files, to remove one of the systemwide whitelist entries. To remove a whitelist entry, the address in the unwhitelist_from directive must exactly match the one given to whitelist_from .

3.5.1.2 Whitelisting senders by relay

Sometimes whitelisting by the sender's address alone isn't sufficient. For example, the sender's address might be one that's easily guessed or likely to be spoofed by spammers. For example, a spammer might try to ensure that you read his message by forging the sender's address to [e-mail] or [e-mail] .

SpamAssassin offers more control over whitelisted senders with the whitelist_from_rcvd directive. This directive associates a sender's email address with the hostname or domain name of the last trusted relay. SpamAssassin uses DNS to do a reverse-lookup of the IP address of the last trusted relay; the reverse-lookup yields one or more hostnames associated with the IP address. Here's how you would whitelist [e-mail] only if the last trusted relay reverse-resolves to a hostname in the mybigclient.com domain:

 whitelist_from_rcvd [e-mail] mybigclient.com 

Messages that match a whitelist_from_rcvd directive have their spam scores lowered by 100.

In order for SpamAssassin to distinguish trusted and untrusted relays, you may need to set the trusted_networks option, which was described earlier. If your mail topology is relatively simple ‚ you or your ISP control all of the IP addresses in the class B network that includes your mail server's public IP address ‚ SpamAssassin can usually make a reasonable guess.

SpamAssassin is distributed with several, default, relay-based whitelist entries in the 60_whitelist.cf file. These entries are defined with the def_whitelist_from_rcvd directive, which works just like whitelist_from_rcvd but lowers the spam score by only 15 when a message matches.

As you might expect, whitelist entries based on relays can be removed with the unwhitelist_from_rcvd address directive. The address must exactly match the address defined in a whitelist_from_rcvd or def_whitelist_from_rcvd directive. If the whitelist_from_rcvd directive uses wildcards, the unwhitelist_from_rcvd directive must specify those same wildcards.

3.5.1.3 Whitelisting recipients

SpamAssassin provides three levels of whitelisting for message recipients. Whitelisting a recipient lowers the spam score on all messages addressed to the recipient. Use recipient-whitelisting to prevent any spam-checking from being performed on behalf of a recipient. You can also use recipient-whitelisting as a crude mechanism for increasing the spam threshold ‚ lowering the false positive rate at the cost of more false negatives ‚ for a recipient.

A recipient's address may appear in several headers. If Resent-To and/or Resent-Cc headers are present, the address is checked against only those headers. Otherwise, the address may be matched in the last three Received headers or the headers To , Apparently-To , Delivered-To , Envelope-Recipients , Apparently-Resent-To , X-Envelope-To , Envelope-To , X-Delivered-To , X-Original-To , X-Rcpt-To , X-Real-To , or Cc .

The three levels of recipient-whitelisting are configured with the directives whitelist_to (lower spam score by 6), more_spam_to (lower spam score by 20), and all_spam_to (lower spam score by 100). For example, to ensure that no messages to root or postmaster are tagged as spam, you could use the following lines:

 all_spam_to root@* all_spam_to postmaster@* 

No unwhitelist_to directive is provided because whitelisting by recipient is really useful only in systemwide configuration. Individual users can just change their required_hits setting in their .spamassassin/user_prefs file instead.

3.5.2 Systemwide Blacklists

SpamAssassin has only two blacklist directives (and two directives to unblacklist addresses). You can blacklist sender addresses or recipient addresses.

The blacklist_from directive is used to specify a sender's address to blacklist. The sender's address is the address that appears in the Resent-From header, if that header exists, or in any of the headers From , Envelope-Sender , Resent-Sender , or X-Envelope-From . If the sender's address matches a blacklist_from address, the spam score of the message is increased by 100 points, which makes it almost certain that the message will be tagged as spam.

For example, a spammer might send messages from [e-mail] in the hope that you'll think it's an important message from an operating system vendor. If you never expect to receive legitimate messages from [e-mail] , you can ensure that any message from that address will be tagged as spam by using this line in the systemwide configuration file:

 blacklist_from [e-mail] 

You can use multiple blacklist_from directives or multiple addresses in a single directive to blacklist several addresses. You can also use an asterisk (*) as a wildcard for zero or more characters and a question mark (?) as a wildcard for zero or one character, much as you would to specify filename patterns in a shell. For example, you could blacklist all mail from public.com and from all hosts in the example.com domain with these lines:

 blacklist_from *@public.com blacklist_from example.com *.example.com 

You can remove a blacklist entry with the unblacklist_from directive. To remove a blacklist entry, the address in the unblacklist_from directive must exactly match the one given to blacklist_from .

The blacklist_to directive performs blacklisting based on recipient address. As with whitelisting, a recipient's address may appear in several headers. If Resent-To and/or Resent-Cc headers are present, the address is checked only against those headers. Otherwise, the address may be matched in the last three Received headers or the headers To , Apparently-To , Delivered-To , Envelope-Recipients , Apparently-Resent-To , X-Envelope-To , Envelope-To , X-Delivered-To , X-Original-To , X-Rcpt-To , X-Real-To , or Cc . If a recipient address matches a blacklist_to entry, the spam score of the message is increased by 10 points.

Blacklisting by recipient is most useful when spammers use software that sends mail with recognizably forged To headers (specifying the real recipient in the SMTP transaction, of course). For example, it used to be popular to send spam with a To header of [e-mail] . Although SpamAssassin already includes a special test for this address in headers, you could also use the blacklist_to configuration directive to increase the spam score for such messages by 10 points:

 blacklist_to [e-mail] 

No unblacklist_to directive is provided. Simply don't blacklist a recipient who should continue to receive mail.

It's possible, but silly, for the same address to be both blacklisted and whitelisted. In this case, both lists are applied and, if the blacklist adds 100 to the spam score and the whitelist subtracts 100, cancel one another out.

3.5.3 Per-User Whitelists and Blacklists

Email from a given address may be welcomed by one user and shunned by another. Although systemwide whitelists and blacklists are useful antispam tools, in many cases, each user will want her own individual whitelist and blacklist entries.

SpamAssassin provides two mechanisms for per-user whitelists and blacklists. The first mechanism is the simplest: add the appropriate configuration directives to the per-user configuration file for the user's account (typically ~/.spamassassin/user_prefs ). The disadvantage of this approach is that it requires users to have accounts and access to their home directories.The second mechanism is to configure spamd to look up per-user test scores and whitelists and blacklist entries in an SQL or LDAP database, as described earlier in this chapter.

If users want to remove systemwide whitelist or blacklist entries, they can use the unwhitelist_from or unblacklist_from directives described earlier in this chapter.

Whitelists and Blacklists Without SpamAssassin

If SpamAssassin is not run on a systemwide basis on all messages, users can also implement whitelists and blacklists by carefully organizing the filters they use to run SpamAssassin on their messages.

For example, on a Unix system that uses procmail for message delivery, a user could whitelist [e-mail] and blacklist [e-mail] with procmail recipes before the recipe that runs SpamAssassin. The user's .procmailrc might contain:

 :0 * ^From:.*[e-mail] $DEFAULT :0 * ^From:.*[e-mail] /dev/null :0fw * <300 000 /usr/bin/spamassassin