At 01:09 2001-12-02 -0600, listuser(_at_)neo(_dot_)pittstate(_dot_)edu wrote:
In the past I've always relied on resending mail to test a recipe rather
than parsing an existing spool. I don't suppose there's much difference
either way.
'cept that if you parse an existing mailbox file by using a sandbox
configuration, rather than putting the filter into your live .procmailrc,
you can extensively test a filter BEFORE making it operate on your active
mail spool. You can quickly and easily stuff the exact same messages at
the filter over and over and over again as you make individual alterations
to the rules (as well as make slight tweaks to the messages and their
headers to text the extents of the filter). Also, if you consistently use
$SENDMAIL for the sendmail invocation, you can redefine it to run a shell
script that simply dumps the message to a file prefixing it with the passed
arguments or somesuch, so autoreply reciped for instance don't actually
SEND the autoreply (that's not what you're doing here, but it's quite
common). Since a sandbox isn't operating on your live mail spool, you can
safely discard messages which aren't of interest by defining $DEFAULT to
/dev/null (you're piping test messages into it after all) - if your test
filter is in your live mail spool, every time one of those messages fails
to be caught by your filter, it ends up either being filed away in another
folder, or probably tripping some other rule you'd just as soon that it
didn't. Who really wants scores of test messages in their inbox?
There's a lot in favour of using a sandbox.
For the time being, I'm wanting to clone the messages that I match and add
the X-Loop and X-Spam headers to.
As I pointed out previously, you're adding these headers to the _copy_ of
the message, not to the original - so there's a copy of the message that
passes from the first recipe to the second, and it doesn't contain this
header which I presume you may think has been added.
My advertising.com is working as expected now. My broadwing.net one has
ceased to function.
Please provide the received: headers from the message you expect is
supposed to be being matched here.
The Received: lines above for matching broadwing.net and not netzero.net
don't make any matches. I've reverted back this for now.
* ? formail -x"Received:" | egrep -is "broadwing.net"
* ! ? formail -x"Received:" | egrep -is "netzero.net"
As has already been pointed out, it is really inefficient to screw around
with extracting the headers using formail and piping them to egrep (I
didn't point this out the first time around because there seemed to be more
critical things wrong with your recipe). I also note that you don't
include the VERBOSE log from the message being processed with the
recommended procmail-native expressions -- just the formail|egrep ones
which you were advised to not bother with.
Here's a really basic recipe (which I run in a sandbox - see my .sig) that
just matches on the conditions you say you're having problems with:
:0:
* Received:.*\<broadwing\.net\>
* ! Received:.*\<netzero\.net\>
test.ok
I passed a message to the test filter which contained a received line with
a broadwing.net host, but no netzero.net host in any received line. This
resulted in:
procmail: Assigning "INCLUDERC=test_filter.rc"
procmail: Match on "Received:.*\<broadwing\.net\>"
procmail: Match on ! "Received:.*\<netzero\.net\>"
procmail: Locking "test.ok.lock"
I tweaked the message to contain a netzero.net host in a received line and
re-ran the filter, which resulted in:
procmail: Assigning "INCLUDERC=test_filter.rc"
procmail: Match on "Received:.*\<broadwing\.net\>"
procmail: No match on ! "Received:.*\<netzero\.net\>"
I respectfully offer that you should doublecheck what you're passing to the
filter in question, because the proffered procmail expressions should have
no trouble catching them.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail