DSPAM: Single aliases for spam/ham reporting, opt-in/out-flags in the database
My mail server uses DSPAM (http://sourceforge.net/projects/dspam/) to filter incoming mail. I use the following set-up:
- spam@xxxxx for retraining false negatives.
- ham@xxxxx for retraining false positives.
- Virtual users in the dspam database.
- Opt-in/out flags from the database.
- User IDs in the X-DSPAM-Signature header.
This set-up means that any of my mail users can forward an incorrectly classified message using any of their aliases as the ‘From’ address and DSPAM will work out the correct user from the X-DSPAM-Signature header. I was pretty sure this set-up was working, until I upgraded to version 3.9.0 and the detection efficacy dropped off.
Poking around in the logs, it looked like DSPAM had decided to ignore the opt-in/out flags in the database and reverted to looking in disk files. With the logs reporting:
Loading opt-in from /var/spool/dspam/opt-in/<domain>/<user>.dspam
Loading opt-out from /var/spool/dspam/opt-in/<domain>/<user>.nodspam
This meant that while incoming mail was being filtered, I couldn’t retrain incorrectly classified mail. My retraining command looked like this:
/usr/bin/dspam --user ${from_user} --class=${next_hop} --source=error
Then I found this post about a DSPAM set-up very similar to my own. That post suggests the following for retraining to work:
/usr/bin/dspam --user <user> --class=${nexthop} --source=error
Where:
- <user> must be listed in your database.
- If you're running in opt-in mode (like me), <user> must have opted in.
So I changed my retraining command to:
/usr/bin/dspam --user dspam --class=${nexthop} --source=error
and:
- Added a row to the dspam_virtual_uids database table for a user called 'dspam'.
- Added an opt-in file for the 'dspam' user: created /var/spool/dspam/opt-in/local/dspam.dspam.
- Added OptIn:on and OptOut:off preferences to the database for the 'dspam' user.
- Deleted the other 'opt-in' files for the other users I'd added while trying to fix/investigate the issue.
It looks like if users are opted out by default, setting OptIn to 'on' isn't enough you have set OptOut for that user to 'off'.
Now my retraining addresses are working again. Once a decent amount of spam/non-spam has be processed and re-classified, all those banking scams should end up where they belong: in the spam folder.
No Comments »
RSS feed for comments on this post. TrackBack URL