Spamassassin Upgrade

8 posts / 0 new
Last post
#1 Sat, 11/10/2007 - 08:03

Spamassassin Upgrade

Debian etch (stable) gives us Spamassassin v3.1.7 while Debian lenny (testing) provides v3.2.1

I'm seeing quite a bit more spam sneaking through on my new Virtual Pro box than my prior host which used the newer Spamassassin.

How much pain am I asking for if I upgrade?

Changing apt.sources to point to testing and 'apt-get -s install spamassassin' reports: The following extra packages will be installed: libc6 libc6-i686 libdigest-hmac-perl libnet-dns-perl libnet-ip-perl libsys-hostname-long-perl locales tzdata Suggested packages: glibc-doc razor libnet-ident-perl libio-socket-ssl-perl dcc-client pyzor libmail-dkim-perl Recommended packages: libmail-spf-query-perl re2c libsys-syslog-perl gcc libc6-dev make The following NEW packages will be installed: libdigest-hmac-perl libnet-dns-perl libnet-ip-perl libsys-hostname-long-perl The following packages will be upgraded: libc6 libc6-i686 locales spamassassin tzdata 5 upgraded, 4 newly installed, 0 to remove and 280 not upgraded. Inst tzdata [2007b-1] (2007h-2 Debian:testing) Conf tzdata (2007h-2 Debian:testing) Inst locales [2.3.6.ds1-13etch2] (2.6.1-1 Debian:testing) [] Inst libc6 [2.3.6.ds1-13etch2] (2.6.1-1+b1 Debian:testing) [libc6-i686 on libc6] [libc6-i686 ] Conf libc6 (2.6.1-1+b1 Debian:testing) [libc6-i686 ] Inst libc6-i686 [2.3.6.ds1-13etch2] (2.6.1-1+b1 Debian:testing) Inst libdigest-hmac-perl (1.01-6 Debian:testing) Inst libnet-ip-perl (1.25-2 Debian:testing) Inst libnet-dns-perl (0.60-1 Debian:testing) Inst libsys-hostname-long-perl (1.4-1 Debian:testing) Inst spamassassin [3.1.7-2] (3.2.1-1 Debian:testing) Conf locales (2.6.1-1 Debian:testing) Conf libc6-i686 (2.6.1-1+b1 Debian:testing) Conf libdigest-hmac-perl (1.01-6 Debian:testing) Conf libnet-ip-perl (1.25-2 Debian:testing) Conf libnet-dns-perl (0.60-1 Debian:testing) Conf libsys-hostname-long-perl (1.4-1 Debian:testing) Conf spamassassin (3.2.1-1 Debian:testing)

Anything there look like it will break Webmin? I really need to set up a testing rig . . .

Wed, 12/06/2006 - 12:56
Joe's picture

Hey Dan,

We ordinarily leave everything provided the OS alone...but if the upgrade isn't painful (i.e. incompatible configuration file changes), I'm willing to roll them out when it provides a real benefit for customers. In this case, I suspect the upgrade is quite painful.

I'm even willing to break that rule in some cases...the Dovecot upgrade to 1.0 is going to be painful, but it is necessary to get the features we absolutely must have for everyone to be satisfied. And so we've written a configuration conversion script to, hopefully, remove the pain. But it's taken two weeks, so far, of testing and experimenting and packaging, and it's still not safe enough for the repositories. SA could be even worse (I don't know--it's been so long since I've done an SA upgrade). I'll have to look into it.

Luckily, it would only effect a couple of platforms, if we do bring up SA, since most of our supported systems already have 3.x.

So, in short: It's probably worth doing, and I probably can make it happen. It'll probably be a couple of weeks, however, before I can get the conversion script written and tested. It just depends on how complex the changes are between the various versions we have to upgrade.


Check out the forum guidelines!

Sun, 02/11/2007 - 17:06

This is a moot post as of now as I'm moving everything over to OS 4.4 now :-)

Sat, 11/10/2007 - 10:57

The easy way to do this is to use the Debian "volatile" repository:

Its pretty much as simple as adding the volatile repository to your sources.list, and update/upgrading.

That said, unfortunately spamassassin 3.2.3 is not in the etch repository quite yet, but it will be shortly according to the word on the mailing list (its being tested). Clamav is in there, though, as well as some time-zone things.

The good thing about volatile is that its meant for just these packages that need to be absolutely up-to-date, and its very strict and has security maintenance. Read the site above for a run-down.

Going from spamassassin 3.1.x to 3.2.x, in my experience, is totally smooth. There's some new config files with options you can enable but you can just upgrade and keep on trucking. I would definitely bother to enable sa-update though, as it keeps the rules fresh which makes spamassassin much more effective. You have to run sa-update as root, and change /etc/default/spamassassin to enable a daily check.

sa-compile is worth looking into as well, as it speeds up spamassassin runs, but requires slightly more work. You have to install some additional packages (suggested by the spamassassin package), and then run sa-compile.

Your instinct that 3.2.x is more effective than 3.1.x is spot-on, though.

Sat, 11/10/2007 - 16:10

<b>Thanks markedwards!</b> I had completely forgotten about volatile. Pointing to 'testing' became a habit as Sarge got older and older. The other repository that comes to mind is <a href='' target='_blank'>Backports</a>. They have spamassassin v3.2.1 versus Volatile's v3.2.3 although I would still probably lean towards Volatile even if the numbers were reversed.

How does sa-update compare to <a href=' target='_blank'>RulesDuJour</a>? In other instances I've got RulesDuJour updating a couple of dozen rulesets and it seems fairly effective and solid. Can both be used side by side? Time for some reading I guess.

Sat, 11/10/2007 - 17:52

Looks like sa-update is the preferred and more modern/supported method.

The custom SARE rulesets (I highly recommend these) that RulesDuJour provides can also be picked up and updated via sa-update (See <a href='' target='_blank'></a>)

The Volatile archive is still waiting on releasing spamassassin v3.2.3, so I went ahead and used Backports and can report that v3.2.1 installed fine. It seems to need an edit to /etc/default/spamassassin to set ENABLED=1
(and CRON=1 if you want sa-update).

Sat, 11/10/2007 - 18:01

Next SA question. I am used to adding some weighted scores to /home/YOURDOMAIN/.spamassassin/user_prefs The file is there, but the custom scoring is ignored. Where should these go?

Also, while thinking of this, how about setting a threshold for scores on messages that can just be deleted? In Exim you can have a filter such as:

# Appended to delete all messages scoring 15 or greater in SpamAssassin
$h_X-Spam-Level: contains &quot;***************&quot;
seen finish

Is there a clean way to do this here?

Sun, 06/07/2009 - 07:16

New scoring goes into /etc/spamassassin/

Although individual users can have their own scoring:

As to auto-deleting REALLY bad spam, how about something in Webmin-&gt;Servers-&gt;Procmail like:

# Delete any messages with a spamassissin score of &gt;15
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

Topic locked