Dallman Ross replied to me:
<> > :0
<> > * ^To:\/.*
<> > * -1^0
<> > * 1^1 MATCH ?? @server
<> > * -1^1 MATCH ?? myname(_at_)server
<>
<> A kind of fun -- because it combines two separate nuances in one
<> condition -- thing I like to do sometimes ina case like this is
<> to combine your first and second conditions:
<>
<> :0
<> * -1^0 ^To:\/.*
<> * 1^1 MATCH ?? @server
<> * -1^1 MATCH ?? myname(_at_)server
<>
<> If there's no To: header, match will be empty (we should unset it,
<> though, because if there's no To:, $MATCH could still be left over
<> from something above); and the $MATCHes in these conditions won't
<> find anything.
Nice. I like it. /me sticks this in the arsenal
Professional Software Engineering also replied:
<> >I think Sean expected $TO to be set by some previous recipe.
<>
<> No, it was a hasty draft and I neglected to use MATCH instead of TO (note
<> the first condition assigns MATCH). However, I _do_ have a TO extraction
<> (among other things) in my standard sandbox, so this variable is available
<> in my case (though I don't use it often outside of spam checks).
Same here. It took a few minutes of reading Andreas' post to realize
what the problem was because the recipe looked so right <g>
R
--
R A Lichtensteiger rali(_at_)tifosi(_dot_)com
"Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we." -- George W. Bush
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail