Current performance since post-training stats reset: 164 non-spam received, 17 spam received, 0 false positives, 6 false negatives, spam identification 64.7%, overall accuracy 96.685%.
(For reference, the training stats, on a corpus of 5088 messages with approximately a 50% spam ratio: 2558 non-spam, 2530 spam, 3 false positives, 163 false negatives.)
*sigh*
I just had to fix -- or rather, re-fix -- another dspam bug, this one in dspam itself. You see, dspam makes the hardcoded assumption that every possible local delivery agent uses the option -d to designate that the following argument is the address to which a message is to be delivered.
Needless to say, this assumption is not universally true. Specifically, it is not true for Postfix's sendmail replacement, which uses -i for that purpose and does not accept -d.
I reported this bug before, waaaay back in dspam-3.2.0. Clearly, no-one paid any attention. So, if you're trying to use an unpatched dspam with Postfix, the redelivery options in the web client won't work.
The correct fix here, of course, would be to allow specifying not just the local delivery agent, but the delivery agent arguments. I'm starting to think it would be easier to get Wietse Venema to have Postfix's sendmail accept -d interchangeably with -i.
