On Sat, 21 Nov 2009, Martin Gregorie wrote:

> On Fri, 2009-11-20 at 15:20 -0800, Mark Hedges wrote:
> > As I've already confirmed by including the debugging log
> > attachment in my first message, the test rule is loaded,
> >
> When run under sendmail and procmail as well?

The debug log that I sent the first time was the output when
running spamc from .procmailrc.

During message scan:

  Fri Nov 20 11:49:32 2009 [26661] dbg: dns: checking RBL spammers.rbl.dmz., 
set cov_spammers

It's apparently aware of the rule, so I don't understand
why the rule is not running.

> I might have missed something, but saw that you confirmed
> the test was loaded and called in your test rig but not
> that this was necessarily true in the other two cases.
>
> > And, it doesn't explain why the rule is correctly
> > loaded, but not run when scanned, and is run when I put
> > the message through the command line.
> >
> That's often a mark of location dependency, hence my
> comment. Is it possible that the sendmail wrapper and/or
> the procmail environment are overriding the siteconfig
> path? Does your site use spamc/spamd in some places and
> spamassassin in others?

We always use spamc from .procmailrc.  I used `spamassassin`
for the test recommended earlier by Benny Pedersen.
`spamassassin` works, but `spamc` does not work.

I verified that spamd is starting with the same siteconfigpath in
both `spamd` and `spamassassin`, by adding a special header only
in that cf file.  So, `spamc` is talking to the correct spamd.

spamd is running like this:

  spamd --max-conn-per-child=15 --timeout-child=1200 --daemonize 
--nouser-config --sql-config --username=defang --listen-ip=192.168.6.100 
--allowed-ips=192.168.0.0/16 --debug  --max-children=8 --port=793 
--siteconfigpath=/etc/mail/spamassassin/digicine/ 
--helper-home-dir=/var/cache/spamassassin/digicine 
--syslog=/var/log/spamassassin/digicine.log 
--pidfile=/var/run/spamassassin/spamd-digicine.pid

That's the same siteconfigpath that I used with `spamassassin`.

The helper home dir is writeable by the process user.  It does
not matter if I run with --paranoid or not.

I also added a header that prints _RELAYSUNTRUSTED_ for info.
The relay I'm trying to block appears in both instances.
_SUBTESTS(,)_ is also the same in both instances.

I am at the point of adding more debugging statements to the
source code.  Thanks very much for your help!

Mark

Reply via email to