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.
...
: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.
This is another case where procmail's regular expressions aren't quite
that same as egrep's.
Looking at just one condition line as an example:
* $ ^From:[$WS]*SpamCop AutoResponder
If $WS is unset then that will be equivalent to:
* ^From:[]*SpamCop AutoResponder
and if a ']' immediately follows a '[' then it is treated as a literal
square bracket rather than an 'end the character class' metacharacter.
So far so normal. That expression is then a character class equivalent
to []* aACemnoprs] except for the final square bracket that ends the
character class. Most regular expression engines would give you an
error because of a missing closing bracket - procmail treats the
end-of-line as an end-of-character-class and doesn't give an error. I'm
not sure if that is intended behaviour or a bug, but I don't think it is
documented.
So your 'From:' and 'Subject:' conditions are effectively:
* ^From:[]*SpamCop AutoResponder]
* ^Subject:[]*SpamCop has accepted]
both contain spaces in the character classes, and From: and Subject:
will both generally be followed by a space, so both those conditions
will match against most mails.
Hope that helps,
Martin
--
Martin McCarthy /</ PGP key available
`Procmail Companion' \>\ http://www.ancient-scotland.co.uk
Addison Wesley /</ http://www.ehabitat.demon.co.uk
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail