Current anti-spam measures

For the sake of documentation, I list the enhancements I configured for SpamAssassin since February:

• I use SA’s internal sa-update script nightly to update the standard rules that are changed between the releases of new versions. The standard channel is updates.spamassassin.org. The files automatically go into /var/lib/spamassassin/$VERSION and Debian automatically finds it, as can be seen from a call of spamassassin -D --lint.
• In addition to the previous, I call sa-compile to compile the body rulesets into binary form. This makes checking of body rules more efficient. To enable SA using these binary rules in /var/lib/spamassassin/compiled/$VERSION, I have to activate the Rule2XSBody plugin in /etc/spamassassin/v320.pre.
• I don’t update the SARE rules against stock spam manually anymore, but also use the provided sa-update channel for it.

Recently, PDF spam has become “popular”. Therefore I enabled some more things to accomplish this:

• The ClamAV virus scanner provides inofficial databases by Sanesecurity to catch various sorts of spam. So there’s actually some kind of redundancy, as the virus scanner and the anti-spam filter are now sharing some responsibility. As not a single virus occured at my site in the recent months, this has now changed in some way.
• I installed the PDFInfo plugin from SARE and enabled it in /etc/spamassassin/init.pre.

Sure, as soon as we catch enough of that new PDF spam, spammers might change to some other document file format, such as DOC or RTF or even ODF, and we are forced to scan those attached documents for spam text or even for contained images that contain spam text, what we are already considering with FuzzyOCR. There must be some better way, actually.

However, I had to reduce the score of the Botnet plugin, as the default value of 5 points is way too high. Maybe I should add the plugin that checks the operating system such that only botnet clients using that Windows crap get high scores.

The fight continues.