On 20 Nov, heddy Boubaker wrote:
| [...]
|
| Yes I must admit my message was not clear enough ... What I wanted to
| replace was these too many
| {
| SPAMREASON="misc rule 1 match ${MATCH}"
| LOG="${SPAMKILLERTAG}: ${SPAMREASON}
| "
| :0 fwh
| | ${FORMAIL} -i "${XSPAMKILLERHEADER}: ${SPAMREASON}"
| :0
| ${SPAMFOLDER}
| }
| after my filtering rules by a kind of procmail function. I've 10 rules
| that help me remove spams and if the conditions are slightly differents
| all the 10 have the same action part (see above), what I wanted to do is
| to define a kind of function/macro that I'll use in the action part of my
| 10 rules. [...]
You can create a seprate rcfile, say rc.spamprocess. In that file, you
could have something like:
LOG="${SPAMKILLERTAG:-unknown}: ${SPAMREASON:-unknown}
"
:0fhw
| formail -i ${XSPAMKILLERHEADER:-unknown}: ${SPAMREASON:-unknown}"
:0:
$SPAMFOLDER
Note, the trailing ":" on second recipe to add a lockfile. I've also
taken the liberty of adding the default value "unkown" to each variable
in case they get here inadvertently without a value assigned.
Then each recipe would look like:
(Note: I'm assuming from your example that SPAMKILLERTAG and
XSPAMKILLERHEADER are set elsewhere. If not, they'd be included below.)
:0
* spam condition(s)
{
SPAMREASON="misc rule 1 match ${MATCH}"
INCLUDERC=rc.spamprocess # may need path to file, depending on setup
}
This provides even more flexibilty beyond elimnating duplicate code.
With minor tweaks you could, if you choose, process all the spam recipes
and INCLUDERC=rc.spamprocess once at the end. I do something similar,
where each match is assigned a score, and a cumulative score is tested
at the end. By weighting the spam fingerprints and keeping a cumulative
score I hope to identify some messages as spam (because of their
multiple fingerprints) that might not be as clear with any one match
alone. I also choose the slight inefficiency of processing additional
recipes that might not be necessary to hopefully generate more usable
information about spam characteristics. But even with that setup, there
are one or two recipes that so clearly indicate guilt that I short
circuit additional processing and immediately skip to the rcfiles that
do final processing. It's easy to set up so you have the flexibility to
do either. That's more than you asked for, but I hope it helps.
BTW, I'm still using an older version of procmail so have no first hand
experience with SWITCHRC. That may be more appropriate than INCLUDERC,
but the principle should be the same.
--
Reply to list please, or append "6" to "procmail" in address if you must.
Spammers' unrelenting address harvesting forces me to this...reluctantly.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail