OSBlues

I’ve been noticing increased traffic from Google for searches for DSPAM vs ASSP, so I guess you think I know about both 🙂 I do indeed have experience of both and recommend them both as excellent SPAM tools. I will write a full comparison and thoughts on both very shortly. Stay tuned.

This seems like a pretty comprehensive guide for configuring the various parts of Postfix that can help the fight against spam.

Security Sage Postfix Anti-Spam Guide

This one is very useful too –

Postfix Anti-UCE Cheat Sheet

Enjoy 🙂

As mentioned in my previous DSPAM post, I replaced the horrible symlinks necessary to get the CGI working when following the appliance instructions (localStore pref) with a CGI hack, which appeared to do the trick. After trying to setup a new user on the appliance I noticed that this hack only seems to work for users who are admins (appear in the admins text file) and for the life of me I couldn’t figure out why this was. After much more hair pulling I decided to see if a ‘better’ fix had been applied in the latest development version of DSPAM and luckily for me one has! It’s very simple to apply the bits that need changing for this, I would provide a patch but I’m not really sure how to do that 😉 So here goes in kinda patch notation –

Block 1
use Time::Local;
use vars qw { %CONFIG %DATA %FORM $MAILBOX $CURRENT_USER $USER $TMPFILE};
+use vars qw { $CURRENT_STORE };
require "ctime.pl";

Block 2
$CONFIG{'DSPAM_ARGS'} =~ s/%CURRENT_USER%/$CURRENT_USER/g;

-$USER = GetPath($CURRENT_USER);
+$USER = GetPath($CURRENT_STORE);
$MAILBOX = $USER . ".mbox";
$TMPFILE = $USER . ".tmp";

Block 3
_END
close(FILE);
}
}

$DATA{"SEDATION_$PREFS{'statisticalSedation'}"} = "CHECKED";
$DATA{"S_".$PREFS{'trainingMode'}} = "CHECKED";

Block 4
&error("Unable to determine filesystem scale");
}

+sub GetPrefs {
+ my(%PREFS);
+
+ my($FILE) = "$USER.prefs";
+
+ if ($CONFIG{'PREFERENCES_EXTENSION'} == 1) {
+ open(PIPE, "$CONFIG{'DSPAM_BIN'}/dspam_admin l pref " . quotemeta($CURRENT_USER) . "|");
+ while() {
+ chomp;
+ my($directive, $value) = split(/\=/);
+ $PREFS{$directive} = $value;
+ }
+ close(PIPE);
+ }
+
+ if (keys(%PREFS) eq "0" || $CONFIG{'PREFERENCES_EXTENSION'} != 1) {
+ if (! -e $FILE) {
+ $FILE = "./default.prefs";
+ }
+
+ if (! -e $FILE) {
+ &error("Unable to load default preferences");
+ }
+
+ open(FILE, "< $FILE");
+ while() {
+ chomp;
+ my($directive, $value) = split(/\=/);
+ $PREFS{$directive} = $value;
+ }
+ close(FILE);
+ }
+
+ return %PREFS
+}


That seemed to do the trick for me (YMMV).. Basically in each block above, find the first bit and then straight after that add or remove lines as denoted by the +/- symbols.

I’ve had DSPAM up and running as a test on domains I use for personal mail now for nearly a week. I’m pretty impressed with the CGI interface and how easy it is to use from that respect. As for accuracy, I’m a little annoyed that it took a few days to even start to get any real accuracy but I have the feeling that may have been my fault! I automatically turned on Bayesian Noise Reduction from the CGI interface as it thought that sounded good, only to find out your not supposed to use it until you are getting 95-99% accuracy! I’m not sure whether turning that off or just letting it see a bit more mail has pushed it’s accuracy in the right direction but it is better now. I’m sure it’ll take a bit longer for me to see any real accuracy, but I’ll keep you posted.

I had my first false positive caught in DSPAM over the weekend and have been tearing my hair out over the last couple of days trying to work out why it wouldn’t deliver the mail when I corrected it as not spam. Basically I would clicked the ‘as innocent’ link in the history page only to be presented by this –

An Error Has Occured
The following error occured while trying to process your request:

sendmail: invalid option — d
sendmail: fatal: usage: sendmail [options]
2191: [7/2/2005 18:30:54] Delivery agent returned error, exit code: 64, command line: /usr/sbin/sendmail -d me@mydomain.com

For the life of me I couldn’t work out where the -d was coming from, finally I found the answer here which has now fixed it 🙂

I hope that one saves a few people a headache or two.

Oh, and the LMTP stuff appears to be working now.. not sure what I did to fix that though.

I’ve also got rid of the symlinks that I had to add to connect the virtual_uids with the login names. They were added to get various bits of the CGI interface to work, but this is a better fix, I actually just examined the patch and made the changes manually as the CGI has changed a bit since then.