On the weekend, I cockily wrote and implemented a new
recipe that trashes some mail. The "cocky" part comes
because I didn't test it adequately, or set up a
"safety net"; then went to sleep. I woke up to find
some mail trashed that I didn't want to lose. :-(
But that isn't my question. I found and fixed the
goof. But I still don't understand why procmail did
what it did.
The scenario is, I implemented a variable
that I thought was defined, but that was not.
I use "$WHITESPACE" in that .procmailrc as a
predefined variable (well, constant, I suppose
it might better be called). But I forgot and
wrote in the recipe "$WS" instead. (I'm migrating
to the shorter version in my new .procmailrc-in-
progress.) Okay, so I screwed up. But I don't
understand why the recipe matched mail it shouldn't
have anyway. What, exactly, happens inside procmail
when it butts up against an unset variable?
Here is the recipe:
# collect spamcop.net report URLs for daily complaint activity
:0 hi:
* $ ^From:[$WS]*SpamCop AutoResponder
* $ ^Subject:[$WS]*SpamCop has accepted
* B ?? ()\/http:.*
| echo $MATCH >> reports
Okay, so with $WS undefined, the recipe was matching on,
for example, all procmail list mail. It seemed to be
matching on any mail with a URL in the body, which would
mean that it passed the first two (header) conditions.
I don't understand why it would pass conditions containing
an unset variable. Procmail apparently ignored the strings
following the unset variable, dropping to the body-grep
condition as if the first two conditions had matched.
Why would it do that?
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail