Critical Eye on SpamAssassin

ErrorBase writes "In this Infoworld article, Logan G. Harbaugh makes a great deal about an ancient (2.44) version of SpamAssassin comparing it with newer comercial variants. Quote : You get what you pay for. [...] However, it took more than 10 times as long to install and configure SpamAssassin as it did any of the other products. " Why did he not ask Kevin Railsback who had the whole thing working some while ago?)"

Comments

Logan You Better Run

[Anonymous Coward]

Great - compare generation or more older open source to fresh shrinkwrap. Who's zooming (or shilling) for who.

My ISP (souther NH) runs SpamAssassin 2.6 - and I can tell you that at the default settings it catches 90-95% with .01% (yes Bucko, less than 1/1000) false positives. When they implemented it several versions ago it was just as good.

I've got one client where the run NO filter - some folks (the names GOTTA be on the web site) get up to 100 spams a day. IT are basically monkeys with hands. I have no idea what the CEO thinks. They wouldn't even think OS as they're a total MS shop.

Works for me

[perlionex]

I run a mail server at home on a Linux box, with Postfix and Spamassassin 2.60. I have it configured to label mail as spam once it hits 8 points, and to automatically chuck it into /dev/null once it hits 12 (using Postfix's header_checks).

It works pretty well for me -- the mail server's only for my personal use so I don't really have to worry about irate subscribers sueing me for dropping them legit mail =p and the 8-12 point range in the spam marking gives me a chance to vet through those suspicious mails briefly before deleting them.

I've never tried any other spam filters on the server-side, so I can't really compare. I guess I'm also a bit of a Linux hacker so I don't mind tweaking all those config files along the lines of the FAQ and other hints on forums to get it to work the way I want it to.

Re:Works for me

[perlionex]

Inside /etc/postfix/main.cf:

# The header_checks parameter specifies an optional table with patterns
header_checks = regexp:/etc/postfix/header_checks

Inside /etc/postfix/header_checks (note: replace "*" with "[backslash]*"):

/^X-Spam-Level: ************/ REJECT

Inside /etc/mail/spamassassin/local.cf:

rewrite_subject 1
report_header 1
ok_languages en
ok_locales en
required_hits 8
subject_tag [SUSPECTED SPAM]

He already sent an open letter to SAtalk

[damian]

He sent a long open letter to SAtalk. You can find it in the mailing list archive

SA+MailScanner works for me

[cyways]

I've found the easiest way to implement SpamAssassin is to invoke it through MailScanner. MailScanner uses third-party virus scanners and can optionally invoke SpamAssassin as well. With the free ClamAV antivirus product, you can build a powerful open source mail scanner. Even without a virus scanner, MailScanner detects and quarantines executable attachments and other dangerous content which represent the most common types of mail-borne viruses and worms.

RedHat installs the daemonized version of SA as well as the SA Perl scripts. Using the daemon, the easiest implementation is to invoke SA in /etc/procmailrc on the mail delivery host; for mail gateways running sendmail, you need to use the milter interface. I've found the MailScanner+SpamAssassin approach much easier to configure than either of these methods, and you get virus scanning to boot!

I suspect if the reviewer had compared SA 2.60+ to the commercial products, rather than the older 2.44 version used in the review, SA would have shown better results.

I'd agree with the reviewer that one of the things SA lacks is an easy method for users to interact directly with the program. (Part of the issue has to do with security; SA runs as root. As I read the review, I wondered how the other products allow users to interact directly with the scanners without sacrificing security.) It's not easy to maintain per-user Bayesian filtering, for instance, but I generally recommend having the mail client, e.g., Mozilla, handle these tasks.