On Fri, 06 Jan 2006 16:25:23 -0600 Mr Duck <tld(_at_)codeexamples(_dot_)org>
Michael J Wise wrote:
I think I see the problem.
It's not what you think.
The problem is, the un-negated rule doesn't match the first line it
sees, so the negation matches.
It's ugly, but there it is.
Mr Duck wrote: > Dang you Scuba Steve! > > As you had mentioned in
the previous post, I believe that you > are correct that making this more
"foolproof" would require a > fairly nasty and dirty recipe/regexp that I
am not personally > comfortable, confident, nor considering trying. > >
Again, thanks for the assist. If nothing else, we had a > little
An idea popped into my head on that discourse. One of you more astute
procmail gurus correct me if I'm wrong. No specifics here, it will have to
be fleshed out by others. I probably have something backward in my
logic but this should be something to work with.
INCLUDERC and SWITCHRC
In the main .procmailrc where you want to do these tests at the pont that
you wish them to be initiated:
other rc stuff
the rest of your rc stuff
match_our_received.rc contains the original code to MATCH your own received
headers. Not the negated match.
* H ?? ^From:(_dot_)*(_at_)apid\(_dot_)net
* H ?? ^Received:.*65\.17\.84\.226 <-- Your own firewall/internal machines
If it matches any of your own IP's (meaning it came from inside your
domain) the SWITCHRC will dump out of the included rc file and put you back
in the main rc file where it was originally called so the main rc file can
continue processing from that point.
If NONE of your own IP's are in there it falls to the next recipe which is
a default delivery to your trap folder. That shows as a delivery so
procmail exits and does not continue back to the main rc file.
Is my brain firing on all cylinders tonight?
procmail mailing list Procmail homepage: http://www.procmail.org/