FAQ

• Add the paths to your LD_LIBRARY path
• Add the paths to ld.so.conf (in Linux)
• Copy them to /usr/lib or /lib
• Use the --with-[driver]-includes and --with-[driver]-libraries configure options

# cd /usr/local/mysql/lib
# mv libmysqlclient.a libmysqlclient.a.original
# mkdir /tmp/mysql
# cd /tmp/mysql
# ar x /usr/local/mysql/lib/libmysqlclient.a.original
# ld -r -d my_error.o
# mv a.out my_error.o
# ld -r -d charset.o
# mv a.out charset.o
# libtool -o /usr/local/mysql/lib/libmysqlclient.a *.o

• Turn off the training buffer ("Feature tb=5" in dspam.conf) if it is turned on, or lower the buffering level. You'll want to use a value lower than 5, as this is DSPAM's default. A value of 0 will disable this protection entirely. Find a value that gives you the best spam filtering without allowing for too many false positives.
• The better solution may be to feed DSPAM enough nonspam to exceed the training threshold (2500 messages). This will not only disengage the statistical sedation feature, but will allow other algorithms to kick in, such as Bayesian Noise Reduction, which only engage after training.
• Try deleting your database and retraining using the dspam_train tool, instead of dspam_corpus. dspam_corpus isn't really designed for building highly accurate pretrained databases.

• If you don't check your quarantine very often, you might consider using TOE-mode training. This is the only training mode that won't automatically learn based on the assumption that if you didn't correct a problem, that DSPAM was right in the first place, and it will give you the ability to neglect your filter without degrading its efficiency too much.
• If you've changed your training mode periodically, you may consider reraining from an empty corpus. The different training modes function optimally when you've been using them exclusively.
• If you receive a very large amount of spam, you may consider using dspam_train to train a small corpus of nonspam. This may initially decrease your filter's spam-catching efficiency, but in the end should help prevent false positives.
• If you've experimented with whacky configurations such as Markovian Discrimination, playing with algorithms or features, you may wish to restore your configuration back to its original and try retraining. The default settings in dspam.conf are typically optimal for a good balance between efficiency and accuracy.
• With that said, disabling the 'graham' algorithm and using the 'burton' algorithm exclusively has shown to decrease false positives, however this also increases the number of missed spam. You can change the line "Algorithm graham burton" to "Algorithm burton" in dspam.conf and see if that helps.
• If you receive very little legitimate mail, you may experience some false positives based mostly on the time of day or day of week mail has arrived. You can add "IgnoreHeader Date" to dspam.conf to ignore the date field. This has shown in many tests to decrease false positives, but also increases the number of missed spam.
• If you are using blacklists, other spam filters, or any other form of training guides, you may be doing more harm than good. If the tool is less accurate than DSPAM is, then you will be training DSPAM to be just as inaccurate
• *LOOK* at the X-DSPAM-Factor header and see why it is judging your messages incorrectly. If it looks like there are a lot of tokens that should otherwise be considered nonspam, your retraining may not be working or you may have missed many false positives you did not realize.