I've been using SpamAssassin for the last three years, and about six months ago I decided to switch to DSPAM. There were several reasons for the switch. First, SpamAssassin has a huge memory footprint, by my standards. My email is processed on a Linode host, and the "machine" only has 128MB to be shared among Apache, OpenSSH, Postfix, and all other services. SpamAssassin hogged memory and forced the machine into swap thrashing. Second, SpamAssassin's traditional detection methods are outdated, and it seems to have incorporated statistical learning methods as an afterthought. DSPAM focuses on the more successful techniques. Third, SpamAssassin has no simple retraining mechanism for incorrect classification, while DSPAM has a web interface and also accepts bounced messages.
Unfortunately, DSPAM is a beast to install. I estimate that it took me about 10 hours to get things basically working. The problem is that DSPAM's configurability is far more advanced than its documentation. Potential users of DSPAM are already using Sendmail, Postfix, Exim, QMail, or some other mail server. They may wish spam filtering to occur at any of a number of stages in the mail delivery process. They may or may not wish to use the web management interface, and they may or may not choose to allow retraining by bouncing or retraining with command-line tools. Each combination of these configuration choices produces a complex system with a variety of challenging subtleties, particularly involving file ownership and permissions.
I installed DSPAM on a CentOS box (almost identical to Redhat Enterprise Linux 4). The MTA is Postfix. Procmail is used for the last stage of delivery. DSPAM's web interface is available, and users can email to "spam@yourdomain.com" to retrain a message as spam (as opposed to DSPAM's default of spam-username@yourdomain.com, which is impractical).
The following notes describe what I had to do to get this working. Most of the details I've included are important. Usually it should be clear why (at least to experienced system administrators). I've tried to be more descriptive when discussing the more esoterical details (like anything involving suexec). If the "why" isn't clear, please send me an email, so I can fix it.
I gathered a lot of information from the DSPAM Wiki. Go there for more information on setting things up if your mail server configuration and requirements are considerably different from mine.
dspam-retrain unix - n n - 10 pipe flags=Ru user=dspam argv=/usr/local/bin/dspam-retrain $nexthop $sender $recipient
While I think the web quarantine is great, I personally prefer to use Mutt for it. I use Procmail rules to separate the wheat from the tares (the ham from the spam). For this to work, DSPAM needs to be told to mark spam messages without quarantining them. Just add "spamAction=deliver" to your personal dspam prefs file.
The following is a simple but incomplete rule for filtering spam. It will put all spam into a mail box (maildir format, in this case, because of the trailing slash) called "spam".
:0 * ^X-DSPAM-Result: Spam spam/
Unfortunately, not all spam is created equal. I personally prefer to dump obvious spam to a separate mail box or to /dev/null. The following rule delivers spam with a DSPAM confidence level of .85 or above to the "superspam" box and sends all other spam to the "spam" box (both in maildir format).
:0
* ^X-DSPAM-Result: Spam
{
:0
* ^X-DSPAM-Confidence: 0\.(9|8[5-9])
superspam/
:0
spam/
}
If you want the cutoff for superspam to be .8 instead of .85, the end of the regex would become "0\.[89]". For .7, it would be "0\.[7-9]". To further customize these rules, I recommend consulting the "procmailrc" and "egrep" man pages.