IMO neither of those ways of working ORs into the procmail recipe
syntax are worth much :-)
Once you start trying to provide even modest flow control facilities
in a language, you really need it to be a language, and the more it
looks like a programming langauge, the further you can push it without
turning it into a monstrosity.
The procmail recipe syntax was not designed as a programming language,
beyond the crudest features of programming (crude if/else, variables,
ANDs). Yes, I know you can do everything with a handful of NAND gates,
but that doesn't mean you have to! Yes, you could argue with all this
and claim that it is so a programming language (I wouldn't disagree
btw) and nyah nyah nyah.
The main point is that it's already awkward as hell, and pushing it
another step towards complete syntax obscurity isn't my idea of the
best direction to move in.
My preference would be to simplify procmail, and let it (or use it to)
do the things it is good at (file locking, mail delivery, mail
forwarding, mail filtering, regexp header matching, etc.). If you want
to do more advanced stuff, use a real programming language.
This is not an advertisement, but, you can do arbitrarily complex
processing with the spamometer perl script I wrote last week. The
functions it calls to decide whether mail is interesting have access
to all the headers of the incoming message in an associative array,
and they have access to the body (which is not even read unless you
ask for it). You can do any amount of ANDing and ORing, you have
arrays, variables, great regular expressions, flow of control control,
subroutines, and anything else perl provides (one hell of a lot). All
this in a very well-known and widespread programming language (which,
I could add, is far more widely understood than the procmail recipe
"language").
You could do this for example:
:0i
* ? spamometer -i your-perl-file
mail/XXX
:0i
* ? spamometer -i your-other-perl-file
mail/ZZZ
without having to modify procmail, and without having to write some
horrible bizarre expression. I realize now that "spamometer" is a
misnomer. It's just a script that understands mail messages and gives
you a chance to run arbitrary perl functions on them in an environment
that makes mail processing simple.
Instead of 20 lines of indecipherable procmail recipe, you can have
elegant recipes exactly like the above, and 20 lines of indecipherable
perl! At least when you use perl you'll be using a real language, and
you wont have to EVER worry about hacking the source of procmail (or
perl) to add some basic piece of programming language functionality.
PLEASE note, I am not advocating replacing procmail's ability to
process mail and act on headers etc., with repeated calls to perl. Use
procmail for simple things and if you have some complicated work to
do, use a real programming language. It's easier for everyone to learn
(don't tell me you have to be a programmer to understand a bit of
perl, or that it's harder to understand some nice perl than some of
the obscure procmail recipes that float around here), and no-one needs
to strap on another layer of syntax to procmail.
ALSO, I'm not trying to get people to use my code. I just happen to
use it. If you want to too, that's great. If not, that's great too.
Well that's just my opinion. I may change it tomorrow, so don't take
it too seriously. And I was kidding, I would like to see procmail
completely replaced by something done in perl.
Then we could get really bizarre.
Terry.