Philip,
You're the first to put things in their proper syntax and to be polite about it.
But, to the others: enough, enough... enough!!!!! Everyone is so quick with a
rebuttal
that they forgot to notice the pattern frequently occurring on this mailing
list of
criticism going out with every reply. I'm not going to give details, but it is
like
saying to another you walk to fast, you forgot to tie your shoes, you didn't
brush
your teeth, and on and on and on! This is the first mailing list that I've
discovered
with nit picking at its all time high. Granted, you get an occasional
disgruntled
person on other mailing lists but not every other message.
First you get several people who lay down the law and they are so insistent
about
their rules as if it is the law. So, I used a guess estimate and started
following
their rules, and below is what it led me to. Not one man page said macros
_must_ be
used in a specific syntax manner, because you have others eluding to the fact
that it
can be used in another manner; ie: ^(FROM_DAEMON). Also, the man pages were only
laying down an example of what the macros can do. _Not_, this is it and only
this is
it in the way of syntax. Otherwise, the latitude for syntax should of had a more
narrow scope in the use of coding in the program.
Obviously, everyone that takes a fancy in pointing their fingers will want to
respond
to this message and give their two bits, but don't forget to take a look at the
three
fingers pointing back at yourselves while you're pointing at me.
If any of you are going to give some advice, then be consistent with the way
things
s-h-o-u-l-d be. Last of all, if you believe that I'm breaking my own rules by
criticizing all of you that made the mistakes... y-o-u-r mistaken. You invited
me with
your manners by the way you replied to every other posting.
After I've had some time to cool down, then maybe you can try other attempts.
But
please, no more jumping on everyone's case and ramming it down their throats.
*************************************************************************
Signed,
Concerned
_____________________________Reply_Separator_____________________________
Date: Mon, 01 Mar 1999 00:50:36 -0600
From: Philip Guenther <guenther(_at_)gac(_dot_)edu>
To: deedsmis(_at_)ris(_dot_)net
CC: "Procmail (procmail-request)"
<procmail(_at_)informatik(_dot_)rwth-aachen(_dot_)de>
[Can you keep your line length down below 72 or so? Thanks!]
deedsmis(_at_)ris(_dot_)net writes:
Below, I'll show validity that proves '^FROM_DAEMON' and '^FROM_MAILER' in
procmail-3.11-1.i386.rpm are definitely buggy. And in addition to that, I'll
show
'^TO_' is also buggy.
In the following is a very simple script. Nothing unusual about the way it is
constructed or in anyway out of line with the proper syntax. The following
script
can be rearranged in any format that is in line with the recipe rules and it
w
ill
still filter the mail:
:0:
* ^(From.*|TO)redhat.com
"Technical Support.sbd/linux.sbd/Red Hat"
Okay here's your problem: ^TO, ^TO_, ^FROM_DAEMON, and ^FROM_MAILER
have to appear exactly as written for them to work. If you split them
up, such as by 'factoring out' the ^, then they won't be expanded by
procmail. Let's go through your recipes below and see which follow
that rule and which don't.
# Switching the carrot:
:0:
* (^From.*|^TO)redhat.com
"Technical Support.sbd/linux.sbd/Red Hat"
That should work.
# Removing the period after '^From':
:0:
* (^From*|^TO)redhat.com
"Technical Support.sbd/linux.sbd/Red Hat"
That'll match recipient headers (from the ^TO), but not the From: header
or "From " pseudo-header. It would match a "Frommmmmredhatzcom:" header
("Fro", zero or more 'm's, "redhat", any character, "com")
...
deal with where e-mail is coming from. '^TO_' is only just a extra step
larger
than
'^TO', which represents (again, including my script) where things are going.
^TO_ is _more_ restrictive about what it matches than ^TO. That last
character class ([....]) is negated.
:0:
* ^(FROM_MAILER|TO_)redhat.com
"Technical Support.sbd/linux.sbd/Red Hat"
You broke both of them by splitting off the ^
:0:
* ^(FROM_DAEMON|TO_)redhat.com
"Technical Support.sbd/linux.sbd/Red Hat"
Ditto.
None of these work, because my 'DEFAULT=$MAILDIR/Inbox' in conjunction with
'MAILDIR=$HOME/nsmail' is exactly where the mail ends up after the filtering
process is complete. And, none of them disrupt each other (their working
independently of each other), because the logical vertical line 'or'
separates
the processing.
The 'magic' behind ^TO, ^TO_, ^FROM_MAILER, and ^FROM_DAEMON is not in
the regular expression compiler or engine, but in the condition
parser. It would be just short of impossible to put the 'magic' there,
and impossible to do so without slowing it down _alot_ and introducing
a slew of bugs.
Just use them as they were written and they work fine.