Just found this looking through GeoCrawler:
=============================
This has come up before a few times (not quite an FAQ though). The
concensus at the end of the discussion ends up being that deciding whether
or not to process mail through SA is best handled upstream of SA -- why
invoke SA at all if you don't want to invoke it? The way you handle the
should-SA-be-invoked thing will depend in practice on how you're planning
to call SA -- if from procmail, then you can check for the presence of a
magic file in $HOME, and invoke SA only if it exists (or doesn't exist).
If you're invoking more directly from your MTA, you might be able to setup
a transport map file or something, which will handle the incoming mail
differently based on recipient.
=============================
The issue is that I'm talking 'closed boxes' here ... I want ppl to be
able to add a value to userpref (SQL) to turn it on ... the scenario is:
postfix->spamcheck.py->lmtp->mail spool
I could add code to spamcheck.py to connect to the database to check that
one value *but* that adds one more complication to spamcheck.py, where
PerMsgStatus.pm already has the checks in place, and the data from the
database ...
I was looking at PerMsgStatus.pm as a possibility, to have some sort of:
if($self->{conf}->{required_hits} == 0) {
return !is_spam;
}
right at the beginning of the subroutine ...
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
