Well Filtered

Checking and Ensuring Performance

The topic of performance tuning is a perennial favorite for all critical infrastructure components. SpamAssassin also provides various approaches. In principle, avoid rulesets that are larger than 100-150KB. The more rules SpamAssassin needs to process, the slower the environment will be.

The blacklist and blacklist-uri rules in particular are considered real performance brakes. Therefore, you are best off removing these rules and replacing them with URIBL_WS_SURBL. Also make sure the implementation of network tests is enabled. To this end, you need to edit either the Spamd startup script or startup options, where you will find the -L (--local) option. Remove it. The SpamAssassin team also recommends the use of sa_compile.

If you think your rules might be acting as a bottleneck, you can easily find out. Download the SpamAssassin rule timing plugin HitFreqsRuleTiming [3] and copy it to ~/.spamassassin. Add the following line in the file ~/.spamassassin/user_prefs:

loadplugin !HitFreqsRuleTiming !HitFreqsRuleTiming.pm

Now run a spam check. In the logfile timing.log you will find out how long it took to process the rules. If you find relatively high values here, the rule affecting performance is identified. Note that this test slows the environment – possibly even a lot.

Formulating Filtering Rules

SpamAssassin already has a solid basic configuration of rules, but they only cover the best known advertising email. It is not usually imperative to become acquainted with this area, but if, for example, you are faced with an above average number of false positives, it might be useful to create your own custom rules.

Before you get down to writing your own rules, you should be aware that it is explicitly discouraged to add rules to the *.cf configuration files in the /usr/share/spamassassin directory. The reason is simple: When you upgrade the filter, all existing rules are overwritten in this folder – including your changes.

The right place for site-wide application of rules is therefore /etc/mail/spamassassin/local.cf. The rules you set here are used independently of the executing user. If rules are only supposed to apply to a specific user, you can specify this in ~/.spamassassin/user_prefs. An example of a very simple rule is shown in Listing 2.

01 body DEMONSTRATIONS_RULE ** ** ** ** ** /sue/
02 score DEMONSTRATIONS_RULE ** ** ** ** ** 0.1
03 describe DEMONSTRATIONS_RULE ** ** ** ** ** This is a simple example rule

The above example performs a search in the message body for "sue" and adds the value 0.1 to the spam rating. However, the search is very rudimentary because email would also be assessed 0.1 with the terms "suede" and "ensue." You can refine the search using regular expressions such as the word break parameter \b. With the following configuration, email with the search term embedded do not match the search:

body DEMONSTRATIONS_RULE/\bsue\b/

Adding the i parameter disregards case, so the following configuration would assess email with "Sue" a value of 0.1 as well:

body DEMONSTRATIONS_RULE/\bsue\b/i

Using the header parameter at the beginning of a rule line searches for terms in the header instead of the body:

header DEMONSTRATIONS_RULE /\bsue\b/i

To search for URIs in email, use the uri parameter. SpamAssassin also allows you to create metarules, which are sets of rules linked to each other by a Boolean or arithmetic operation [4].

Checking Rule Syntax

The process of creating SpamAssassin rules is very error prone. Even a small typo can cause the filter mechanism to miss tons of unsolicited advertising email. Experience shows that it takes a long time before the problem is linked to faulty rule configuration. Fortunately, Spam-Assassin provides a lint feature that checks the syntax of your rules:

spamassassin --lint

The output should provide enough information for you to find and correct any syntax errors. If the lint option does not provide any useful information, you can also check the debugging output:

spamassassin --lint -D

The spam filter update mechanism sa-update makes sure SpamAssassin always uses the most current rules and updates. New rules can be transferred promptly to SpamAssassin installations using this tool. The updates are copied to the subdirectory /share/program_version/updates_ spamassassin.org by default. Sa-update can be performed with different parameters:

sa-update && service spamassassin restart

This command checks whether any new updates are available, performs a download, and if necessary starts the lint test. If any problems occur during the update process, sa-update returns the value 0 and restarts the SpamAssassin service.