KFC: the article revers to SpamBayes.

One: Spamassassin includes Bayesian methods these days.

Two: Spamassassin needs regular updating -- its rules are under constant refinement. For this reason, one-time installs of spamassassin, or running SA on systems which don't readily support updating, means you're going to lose a significant amount of the advantage it provides. Score another point for Debian.

SpamAssassin is available and/or proxied for numerous platforms.

I don't care.

Not my problem. Not my email setup.

A few seconds with AlltheWeb or Google will turn up several leads.

You're pulling a Norm.

Apologies -- I was taking the usual cheap shots at Exchange at your expense.

Given that I don't rely on Exchange (though it's what's used at work, I maintain my own email for virtually all my communications needs), I don't have immediate familiarity with what it can do, and (as may have been evident) don't particularly care. I consider it broken by design.

That said, I've followed the SA discussion enough over the past year or two to know that there are some integrations with Exchange possible, though this is largely by reputation. I believe the two most common approaches are a commercial package incoporating SA as a locally-managed filter, and a proxy subscription service which runs your mail through Spamassassin prior to it hitting your Exchange server (or in part of the delivery process). In both cases, you've got the problem of having SA run at a distance from your mailbox, meaning it's harder for the individual user to tune preferences.

My own configuration is fetchmail => exim => procmail (invoking spamassassin) => mutt. The procmail rules incorporate a whitelist / blacklist / spamlist setup, where whitelisted senders are passed straight through, blacklisted senders go to a blacklist box, and spamlist senders are automatically treated as spam (useful for commercial mailing lists / newsletters I never signed up for). While relatively complicated, the advantage is that I control when spamassassin is triggered, and what I do with the trapped spam (it's filtered to a spam mailbox for further evaluation, as well as automatically reported, over a threshold, to spam reporting services). I explicitly don't run spamassassin on mail from whitelisted senders (avoids embarassing accidents), etc. And it's trivial to add addresses to an appropriate list.

My experience in running SA as an MTA-level service for a large userbase (~15k accounts) was that it was useful, and set at a threshold of 10 would eliminate about 85% of spam, with very few false positives. However both accuracy and effectiveness increase as you move the control locus to the user. Unfortunately, so does complexity, and the potential to opportunistically deny spam at the mailserver, or better, tie up spammer resources. Me? I like the power and flexibility (literally: can bounce mail anywhere, run any program, log anywhere, with comparative ease). I can see that others might be overwhelmed. And yes, I've royally fscked up my procmail recipies on occasion....

Of end-user tools, the stuff I've seen regarding Bayesian tools and Mac stuff seems the best thought out and friendliest to Joe and Jane average. While there may be tools that can tie in to Exchange, the interface in general is too limiting to be readily effective.

....some of this would have been evident from Google. But not all. And in fairness to Norm, he can't help himself. I was pulling a Ross, though, and while I'm pretty sure Ross should know better, I'm positive I do.

My bad. Apologies.

....not that I didn't think you could handle it ;-)

Edit Oh, and I wanted to add -- tseliot's writeup is tres good.