[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.
Philip Guenther