Last night I ran a scoring recipe containing 60 lines with no problem
(recipe-wise). It produced a total score that I could use; but overall I
was not happy with the process.
Currently I process each recipe individually. For any action that gets
triggered, I add a description of the recipe to an "X-SPAM" header that
gets inserted into the message after all recipes have been processed. I
also update a counter for that recipe.
The inserted header looks like:
X-SPAM: SPAMMER: bigdls.com **
X-SPAM: RCVD: Last standard Received by raq2.paxp.com
X-SPAM: XFLAG: X-srt:
X-SPAM: XFLAG: X-srk:
X-SPAM: DIGRAPH: zvvffspbfwivatst@ contains unlikely digraph zv
** I have very few spammer domains; but sometimes I get frustrated (or
just don't have time to mess with procmail). :)
The counters look like MSGID-01.ctr.
Each recipe action {} contains the line:
| read var < $PMDIR/counters/MSGID-01.ctr && let var=var+1 && echo $var
$PMDIR/counters/MSGID-01.ctr (unwrapped, of course)
(The counter name is unique to each recipe).
"cat MSGID-01.ctr" reveals the total number of times the recipe has been
triggered (from some start date).
"ls -clt MSGID-01.ctr" provides me with a list of the last date/time each
recipe was triggered (oldest last).
I use a scoring delivery recipe to count the number of X-SPAM header lines
and use the score to sort the spam into SPAM1, SPAM2 ... SPAM5 mail
folders. SPAM1 is where I find most of my "false positives" so I check it
pretty closely.
I'd like to be shown a "procmail" way to maintain my counters. Shelling
out to update the counter for every recipe that gets activated does eat
up resources.
- fleet -
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail