I wrote this a while ago, for dspam v. 2.10, and things have changed a bit since then. In particular, the ./configure options --enable-delivery-to-stdout --enable-spam-delivery no longer exist, and you need to change --deliver-spam to --deliver=innocent,spam when invoking it. I'm still getting well over 99.9% accuracy with my current setup which is why I'm loathe to change it. When I do I'll rewrite this. In the meantime, email me if you have any trouble following this. -- Dickon Hood, 20041114. dspam for SpamAssassin users ============================ All responsibility for this document belongs to me, Dickon Hood . Please see the latest version of this file at . dspam is all well and good, but the way it's written is aimed rather heavily at the server owner, and systems administrator. I'm both, but I didn't want my users to be forced into it either way, and I prefer to keep things simple. Plus I'm not root on my desktop at work, and wanted to run it and fallback to SA if it didn't work for whatever reason. Until recently I've been using SpamAssassin, but that's become less and less useful as the Baysian filtering it contains has been broken for some time now (certainly on the Solaris machines I own and use). So, dspam appeared to be the answer, and, so far, so very good. To compile it, use: ./configure --enable-delivery-to-stdout --enable-spam-delivery with any other choices you have (in my case, some quibbles with the the whitelisting, and various ownership issues, and I like compiling things as 64-bit). If you're keeping it on localhost, you may want --enable-signature-headers so you can simply pipe the email back through dspam on an error, and so it doesn't add the dspam tags to the body. make && make install; see the other documentation for that. Feed it a corpus of email and spam as detailed in the docs, but note that SpamAssassin will have added its markup, and you don't want to train dspam on that. Take your spam mailbox, and: formail -s spamassassin -d < spam.inbox > cleaned.spam.inbox dspam_corpus --addspam ... cleaned.spam.inbox There are many, many better ways of dealing with SpamAssassin's markup, particularly with the later versions which encapsulate the original spam in a message/rfc822 attachment, but this is by far the easiest. I chose all the spam I'd received since New Year's day (I tend to rotate mailboxes on the first of January) -- about 4000 -- and just left the machine to it overnight. 'formail' comes with procmail. I've always been wary of bolting things like this into production mail servers, so I've chosen the procmail route, as I did with SpamAssassin. Put the following rules into your .procmailrc where you currently have a pipe to SpamAssassin: # dspam spam filtering: :0fw | /usr/local/bin/dspam --stdout --deliver-spam :0: * ^X-DSPAM-Result: spam /home/dickon/Mail/dickon-spam.inbox # End spam treatment. (with the appropriate values for you). All your spam should end up in your -spam mailbox, and bypasses the quarantine, which isn't too useful on a personal machine. On an error, simply pipe the offending email to dspam with one of --addspam or --falsepositive, as appropriate. mutt handles this quite nicely with the '|' command. And there you go. dspam, setup similarly to how most people I know use SpamAssassin. Simple. I'm getting much *much* better results with dspam than I was with SA, and I've noticed several non-spams that would have been caught by SA that dspam left alone. On the whole, I'm very pleased with its performace; I'm only getting three or four per day slip through the net, which is about a tenth of what I was getting from SpamAssassin.