LWN.net Logo

Keeping current with SpamAssassin rules

December 6, 2006

This article was contributed by Jake Edge.

Anyone who pays attention to their spam knows that its character changes frequently; spammers are always adding new tricks to try and evade spam filters. There is an arms race of sorts going on; the filters get better at recognizing the latest evasion attempts and so the spammers come up with new ones and the cycle repeats. To reduce the effectiveness of this spam evolution, frequent updates of the filter rulesets are needed. For users of SpamAssassin (SA), the sa-update tool makes it very easy to pick up the latest ruleset and keep that unwanted spam out of the inbox.

Before sa-update, official SA rulesets updates were only available by installing an updated version of SA. Because the release cycle was often lengthy (measured in months), the developers added the ability to easily update the rulesets over the internet. At its core, sa-update communicates with a server or servers picking up rule and score files and installs them in a directory that SA uses for its updates. SA will immediately start using the new rules, though restarting spamd will be required if SA is configured that way.

sa-update is configured by default to use the official 'channel' (updates.spamassassin.org), but that can be altered to tune into other SA rules repositories. The SpamAssassin Rules Emporium (SARE) is one collection of rules and scores that sa-update can use. There are multiple channels available each of which handles a different type of spam and one can mix and match the rulesets to tune the filter for the kinds of spam being seen.

There are some security implications to consider: injecting bad rules or scores could lead to worse spam filtering, for example. More worrisome, however, is the fact that the update mechanism allows for plugins to be distributed, leading to potential arbitrary code execution. SA plugins are arbitrary Perl code that will be run by the filter; because it generally runs as root or another privileged user, that can be quite dangerous. sa-update uses GPG signatures on the updates to reduce this hazard, as long as the signer is really trustworthy (and the recent GPG security problem has been patched). The official channel will not distribute plugins, thereby eliminating that problem.

The rulesets available change frequently and automating the sa-update process via cron can bring the system up to date on a daily or weekly basis. Another tool, rule-get is available which uses the update mechanism and provides a command line syntax based on apt-get.

This is an excellent tool for helping to reduce the ever-evolving spam problem. As long as one is careful about which GPG keys to trust, it should be secure as well. Spammers are, no doubt, taking advantage of this tool to tune their spam to avoid the new rules, but using it can reduce the false negatives from the older evasion schemes or from those who have yet to test their stock scam email with the latest rules.

More information and additional channels are available from the SA wiki, a good starting point is here.


(Log in to post comments)

Keeping current with SpamAssassin rules

Posted Dec 7, 2006 10:28 UTC (Thu) by nix (subscriber, #2304) [Link]

Different channels don't necessarily handle different types of spam: they're just distributed by different people (and hence signed by different GPG keys). (Often they *will* handle different types of spam, of course, but the question `do you trust this channel's operator' should be foremost.)

By the time plugins are executed, spamd is no longer running as root: it should have dropped privileges. (So a hostile ruleset can merely smash all your users' home directories, set up spambots, et seq. Possibly this isn't much of an improvement over wrecking the whole system...)

I've been bitching about this to Red Hat, but there's nothing but deaf ears over there.

Posted Dec 7, 2006 11:25 UTC (Thu) by ronaldcole (guest, #1462) [Link]

SpamAssassin on RHEL3 is version 2.55 and has no sa-update. Bugs I've entered into bugzilla against it and pleas to update it to a version with considerably less bit-rot or remove it completely have been ignored.

I've been bitching about this to Red Hat, but there's nothing but deaf ears over there.

Posted Dec 7, 2006 18:41 UTC (Thu) by smoogen (subscriber, #97) [Link]

It falls on deaf-ears because it violates a promise Red Hat made to the customer. That promise is that the tools it provides are stable (as much as possible) for 7 years. Changes when they happen occur because there is no other way to maintain a code set (mozilla->seamonkey) or when API/ABI was broken in the first place and needed fixing OR when something was listed as being changed in the future (additions to the kernel, glibc, and other core utilities but those changes only occur for the first 24-30 months of the product lifetime.)

Now there are problems with this in the case that some tools people want will 'bit-rot' but for other customers they will want that tool stuck for 7 years even if it means that all the new neat stuff aren't there. The problem is that the majority of the money for people wanting to stay with a release over 36 months are in the second category (don't touch anything). The people who want a stable OS but the latest toys usually upgrade to the next release by 36 months (RHEL_4 in this case).

In your case, this doesnt work as you are sticking with RHEL-3 but need a newer version of spam-assassin.. and so RHEL is not going to be the 'sole' product for you. You could either find another distribution, or you could find a consultant company that has alternatives of needed packages or you could do it yourself.

I've been bitching about this to Red Hat, but there's nothing but deaf ears over there.

Posted Dec 7, 2006 23:41 UTC (Thu) by ronaldcole (guest, #1462) [Link]

Stability my ass. Red Hat has previously lost no sleep in breaking their "promise" and pushing out new features, enabled by default, in their RHEL3 updates (which broke my client's IBM Informix apps)!

"RHEL: it's broken and bitrotted in places, but it's stable. kinda. and that's our promise to you!"

I've been bitching about this to Red Hat, but there's nothing but deaf ears over there.

Posted Dec 8, 2006 4:02 UTC (Fri) by smoogen (subscriber, #97) [Link]

It doesnt matter anymore now that RHEL-3 is in security maintenance mode.

Keeping current with SpamAssassin rules

Posted Dec 7, 2006 12:16 UTC (Thu) by NAR (subscriber, #1313) [Link]

More worrisome, however, is the fact that the update mechanism allows for plugins to be distributed, leading to potential arbitrary code execution.

I guess it's true for all kind automated updating of software from non-trustworthy places, not just SA plugins written in perl. I mean if I'd have an "apt-get update; apt-get upgrade -y" from cron and one of the sites listed in the sources.list file is compromised, I could have a similar problem, a trojan sshd or something like that.

Bye,NAR

Keeping current with SpamAssassin rules

Posted Dec 8, 2006 12:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Indeed, but people seem to have the assumption that spam scanners are 'sort of like virus scanners' and so can be updated safely. Because of the existence of plugins and eval rules (which are moved into plugins in 3.2.x), this is not true, but I can see why people might think it is.

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds