I searched through the archives here and found a few close hits, but
none could quite help, so here goes.
My email is hosted on a shared hosting site (bluehost). I have set up
dspam (3.6.8) to to be called by procmail for incoming mail, and that
seems to be working good. I can see the numbers increasing in the
dspam_stats database, and I am even catching a lot of spam. The problem
is, I want to set up some IMAP folders for retraining missed spam for
which I can simply drag said spam message into, and periodically have
dspam look in that folder for those messages. So I have set up a cron
job to call this script:
#!/bin/sh
#~/.dspam/errorfeed.sh
echo Starting Cron Job>>~/.dspam/cronlog
date>>~/.dspam/cronlog
echo User is ${USER}>>~/.dspam/cronlog
for file in `find $HOME/mail/pelorus.org/skip/.DSPAM-unblocked-spam/cur
-type f -name "*"`
do
echo Processing $file>>~/.dspam/cronlog
cat $file | dspam --debug --mode=teft --source=error --class=spam
--user ${USER}
done
#mv $HOME/mail/pelorus.org/skip/.DSPAM-unblocked-spam/cur/*
$HOME/mail/pelorus.org/skip/.DSPAM-Spam/cur/
you can see the extra "debugging" lines that I have put in, and they are
working. Now here's where it gets funny. dspam.debug is unchanged (no
new entry) when this is called by cron, but if I run the script from the
command line, it runs just fine and the new entry in dspam.debug and
sql.errors are there as expected.
Since this is a shared hosting site, ${USER} will always be the same,
which is fine b/c I am the only person using this right now. Therefore,
${USER} is the only username/acct that I have on the site.
One other puzzling thing is if I add that account name to the Trusted
Users in dspam.conf, then a lot of things that currently do work, will
stop working such as the incoming mail processing.
My money is on something misconfigured, dealing with these last two
sentences. Someone want to prove me correct?
