On Sun, 19 Jan 2003, Bart Schaefer wrote:
However, I think it's more likely he meant [^>], but I don't think he
wants .*[^>] -- that'll consume the entire line after the @ if the address
happens not to be enclosed in < >.
That's exactly what I meant - get rid of the final >. I haven't noticed
any addresses not enclosed in <>; but even if I get "empty", "empty" will
match "empty" won't it?
:0
* From:[ ].*\/\(_at_)(_dot_)*[^\>]
* $MATCH ?? Message-Id:[ ].*\/\(_at_)(_dot_)*[^\>]
foundit
I'm really not sure WHAT he's checking there. The syntax for checking
the value of $MATCH against another expression would normally be
* MATCH ?? Message-Id:[ ].*\/\(_at_)(_dot_)*[^\>]
This is exactly what I had in mind and in my tests the danged "$" wasn't
in front of MATCH. Not sure why it showed up in my message. (And for
what it's worth, it doesn't work without the "$" either.)
The use of \/ to extract into MATCH is extraneous there. Is there some
reason you want to know what the domains are? Perhaps you're trying to
find out whether the Message-Id contains the same domain as the From?
That would be something like this:
:0:
* ^From:[ ](_dot_)*\(_at_)\/[^> ,]*
* $ ^Message-ID:[ ](_dot_)*\(_at_)[^@]*$\MATCH>
Where $\MATCH means the value of MATCH as a quoted regex, so that e.g.
the '.' character matches only a literal '.' rather than any character,
and the leading $ means to expand variables like $\MATCH within the
rest of the condition line.
I also considered this, but I haven't yet found an example of assigning
MATCH to a variable. I suppose it's something difficult like
VAR1 = $MATCH ?
Yes. But not in a condition line. Like so, usually:
:0
* ^From:[ ](_dot_)*\(_at_)\/[^> ,]*
{ DOMAIN = "$MATCH" }
Hmmmm. I *have* seen this. Just didn't realize what was going on.
:0:
* $ ^Message-ID:[ ](_dot_)*\(_at_)[^@]*$\DOMAIN>
foundit
Ok. The [^(_at_)]* is "zero or more anything as long as it's not another @"?
The $\VARIABLE is obviously the solution to what I'm looking for, and I
believe I just noticed something about it toward the back of McCarthy's
book. (And it's probably in the man pages too.)
This would also eliminate the problem of dealing with a situation where
Message-Id appeared before From: I suppose
There is no such problem. Each condition line line (the ones that begin
with '*') starts the search over at the beginning of the header, so it
doesn't matter whether the order of the header fields matches the order of
the conditions. In fact, you have to do a lot of extra work to make it
matter, if that's important for some reason.
No. It's much more important that it doesn't matter. Thanks for this
explanation.
And, fwiw, I am trying to determine if the domain used in the ^From: line
and in the ^Message-Ed: line are different. (And if they're different,
the message goes to the spam box.) Like another participant here, I'm
trying to reach the point where I don't spend all that much time
maintaining a "black list." The difference is that he seems to have a
good grasp of the software whereas I'm approaching it from the perspective
of a Neanderthal. Was it Clarke that said "any technology sufficiently
advanced is indistinguishable from magic?"
- fleet -
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail