On 20 Dec, David W. Tamkin pointed out that my suggestion to parv_ could
be simplified:
| [...]
| So that's what the `E' flag is for.
|
|| :0
|| * condition
|| * condition
|| { VARIABLE = "something" }
||
|| :0
|| * ! VARIABLE ?? something
|| * condition
|| * condition
|| { VARIABLE = "something" }
||
|| :0
|| * VARIABLE ?? something
|| action here
|
| becomes
|
| :0
| * condition
| * condition
| { VARIABLE = "something" }
|
| :0E
| * condition
| * condition
| { VARIABLE = "something" }
|
| :0
| * VARIABLE ?? something
| action here
|
| or for that matter,
|
| :0
| * condition
| * condition
| action
|
| :0E # or no E if previous recipe was delivering
| * condition
| * condition
| action
|
And, of course, he is right, although the last case basically puts us
right back to where parv_ started. I made an assumption that the simple
example that parv_ gave might be just that -- a simple example -- and
was thinking of something that could be extended to more complex and
related sets of recipes. I hinted at that, but not clearly, by pointing
out it was unnecessary and arguably not even a simplification in this
case, but that, *if* there was a good reason for stringing them
together in that fashion, it would work in that case.
With more complex sets of related recipes, I find a construct along
those lines useful. Instead of trying to describe the possible
circumstances, which could take me 'til next Tuesday and still not be
successful, here's an example. (N.B. for those who blindly cut/paste
code w/o knowing what it does, then follow-up with personal attacks
because this "help desk" hasn't performed as *you* unrealistically
expect it *must*, this won't work. It depends on variables set and
headers inserted prior to this, and an INCLUDERC not shown. This is a
work in progress anyway, about which there are no representations of
effectiveness, let alone value for others.)
The 8 bit chars in the char classes below contain the actual characters
not their octal codes as shown here. Sorry if there's a couple of long
lines below.
# Recipe 1
:0
* < 65536
* B ?? Content-Type: text/plain
* $ B ?? charset=$dq?$wsneg*k$wsneg*[-_][0-9]+
* B ?? Content-Transfer-Encoding
{ unreadable = "foreign encoded attachment" }
# Recipe 2 - don't bother if #1 matched
(This one won't identify a message as unreadable here. It mostly lowers
the threshold for #3 by raising the exponent. It still might effectively
tag a message if and after #3 fails, but only under certain failure
conditions there.)
:0
* unreadable ?? ^^^^
* $ 50000^0 charset=$dq?$wsneg*k$wsneg*[-_][0-9]+
* $ 50000^0 ()=\?$wsneg*k$wsneg*[-_][0-9]+$wsneg+\?=
* 25^0 ^Content-Type: text/html
* -1^0
* $ 1^0 ^Subject:$wsstar\/$wsneg.*
* 1^1 MATCH ?? [?\200-\377]
* 1^1 MATCH ?? =[0-9A-F][0-9A-F]
* -1^1 MATCH ?? [^?\200-\377]
{ exp=1.05 carry=$=000 xSUBJ="${MATCH:-Subject: unknown}" }
# Recipe 3
:0
* unreadable ?? ^^^^
* < 65536
* $ ! B ?? charset=$dq?iso-8859-1\>
* $ ${carry:-0}^0
* 50000000^0 B ?? ()<html>
* -50000000^0 ! B ?? [?\200-\377][?\200-\377][?\200-\377][?\200-\377]
* $ 10000000^0 B ?? [?\200-\377][?\200-\277][?\200-\377][?\200-\377]
* $ 1^${exp:-1.02} B ?? [?\200-\377]
* $ 1^${exp:-1.02} B ?? =[0-9A-F][0-9A-F]
* -1^1.02 B ?? [^?\200-\377]
{ unreadable="body $=" exp }
:0 E
* unreadable ?? ^^^^
* > 65535
* $ ${carry:-0}^0
{
SUBSTR="$xSUBJ" maxSUBSTR=42 INCLUDERC=$RCSUBSTR
xSUBJ = "$SUBSTR"
unreadable="$xSUBJ $carry" exp maxSUBSTR SUBSTR
}
# Final action for all 3 related recipes
MATCH
:0
* ! unreadable ?? ^^^^
* 1^0
* $ 1^0 ^X-No-Spam: list$wsstar\/$wsneg+($wsstar[^ +]+)?
{
LOGFILE = $LOGFILEREG.kill
xLIST = "${MATCH:-list unknown}"
LOG="$LOGPFX JUNK [unreadable ($xLIST)($unreadable)]$NL"
LOGABSTRACT=no
:0:$NWMT.dbg.gz.lock
| gzip -c >>$NWMT.dbg.gz
}
These could still be strung together using the E flag, but because
Recipe 3 has it's own E "clause" it would need to be nested in another
pair of braces. When the related recipes have their own E and/or A
clauses, the braces required to join them all together at the top level
with the E flag can get cumbersome -- even more so with more recipes
and/or more complex ones. To my eye, this is a little easier and still
fairly evident that they're all related. YMMV. I'm also not precluding
the possibility that I've completely missed some more sensible way to
do it, but this is more what I had in mind when offering the original
suggestion. However for the simple example that started this, I have no
quarrel that the E flag is clearly preferable.
--
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