The first step was to update SpamAssasin on both our mailservers. On Sulu (FreeBSD 5.3), this was really easy - we were already running 3.0, so updating to 3.1 was a simple matter of "portupgrade p5-Mail-SpamAssassin" and waiting. Bing, it worked. There are some new heuristics in the latest version, and it gained a bit more accuracy almost immediately. Our backup system was still running SpamAssassin 2.6 (Charizard runs FreeBSD 4.11), and hadn't been updated because of Perl version issues. So, I set out to fix it. Upgrading to Perl 5.8 was painless and fast, but really underlined why moving Perl out of the base distribution was such a good idea in 5.x. Portupgrade then barfed on some dependencies (the package database has been running for years now, and needed some love) but "pkgdb -u" and a manual "make reinstall FORCE_PKG_OVERWRITE=1" of p5-Net-DNS fixed that in no time - and portupgrade did its magic. Adding in SPF took another 2 minutes. And bingo - two updated servers running well.
Detection rates have gone right up, and false positive rates seem to have gone down. SPF (Sender Policy Framework) is helping a lot more than I thought it would.
Finally, I made sure that all our inbound mail servers are performing RBL checks and denying known-spammers. Good thing I checked, I'd missed one when I set it up. The result? A significant drop in spam. :-)
I'm seriously considering switching all inbound SMTP (not from relayed clients, just MX records) to a separate mail installation running Sendmail with ClamAV, SpamAssassin, SPF and RBL milters (and possibly greylisting) - and bouncing anything that IS a virus or has high spam scores at source, rather than inline. That would greatly reduce the number of double bounces in our queues, but would risk legitimate mail being bounced. I'd only block very high (10+) SpamAssasin scores (everything else would be flagged by our normal systems), but I worry about false positives. Hmmm.
Mood: tired
Music: Dio - Along Comes A Spider
No comments:
Post a Comment