procmail
[Top] [All Lists]

Re: A tool for refining regex

2002-02-04 21:03:20
At 19:17 2002-02-04 -0800, Harry Putnam wrote:
Sorry about my bad manners...  But you might get a little laugh out of
the reason for my delay in response.. at least the biggest one.

Stupidity is nothing to laugh at. <g>

In all seriousness though, it's a bummer you wrote a script that purged on you.

  maildir=spool
   TESTDIR=$testbase/$spool

Some of you will have noted the misspelled variable in the command.

Two of them actually: $TEST_DIR (should be $TESTDIR) and $spool (apparently should have been $maildir).

Yeah, something like that I have a script in `logrotate.conf' that
checks for certain size.  When reached or surpassed it it gziped and
rotated ... I keep 10 rotations of files that before gzipping are
close to 1.5 mb.

Not that it applies to _rotating_ logs, but you can incrementally add to a .gz file:

        gzip -9fc < new_content > cumulative_file.gz

The entire cumulative contents of the gz will be extracted when you extract the gz, but they're not _recompressed_ as you add to it (each addition is a separate compressed stream).

> I call it a sandbox.  I redefine some things such as $SENDMAIL too, so
> as to take the bite out of "!" and message creation functions.

I had never got into needing to redifine sendmail.. my usage as you've
seen is pretty primative.

What I meant by redefining $SENDMAIL is that I actually define it to a _script_ which emits it's parms and the passed message. In this way, forwards and other invocations of sendmail DO NOT actually invoke sendmail, but you get the information about how it would have been invoked and with what data.

OK, I'm in the dark here to some degree.  I was under the impression
that some kind of locking happens even without the extra `:'.  I
sometimes see a message while running tests...
          `unable to lock some.file'  Which led me to thing some kind
of lock locking happens by default.

I'd check where that message is being emitted from. Locking doesn't "just happen".

And having run thousand of messages into spools that are later scarfed
by gnus, I must have hit the circumstance where the event you describe
has occured.... no?

I would guess. In day-to-day email you might not have two messages arrive for processing at nearly the same time (though it's still a possibility), but lets say that your mailhost is off the net for a short while (a router glitch, whaever), and so your MX accumulates your host's mail - then sometime later relays them all to your mailhost(as per SMTP). Now, kick back and watch as a flood of messages arrive nearly simultanious to one another.

>>If I had the line that matched, I think it would be fairly easy to
>>tell what did it even with all those or things.
>
> I'd suggest you TRY what I recommend, within a sandbox, and see
> first-hand how it operates.

OK.. having done that... I don't get the matched line into the log
yet.  Probably something here set wrong but I don't see it so posting
the test setup.  So far I learned nothing more than what I already
knew about what matched the messages but still no actual line content
snagged from the message.  I guess it narrowed it down a little more
to the 62 66 numbers but again, I already knew that at a glance.

Is there some syntactical error or should I be seeing the actual
header line that matched, printed into my log?

I commented out X-Loop to get the original result...



        * 1^1 ^\/To:(_dot_)*(_at_)pop\(_dot_)newsguy\(_dot_)com
        * 1^1 ^\/Received:.*\/(\.tw |\.kr|[^0-9.]202\.|[^0-9.]211\.|\
         [^0-9.]6[1-6]\.|bogota\.supernet\.com\.co)

WTF with the TWO match expressions on the one line? Lose the one before the parenthesis after Recieved. See how there's only ONE "\/" on the To line? That starts the MATCH construct, which you see below:

procmail: Assigning "MATCH="
procmail: Matched "(66."
procmail: Assigning "MATCH="
procmail: Matched "[62."

There's your two matches, which just glancing at your regexp, match:

 [^0-9.]6[1-6]\.

(which happens to be the beginning of the continued line in the regexp above)

You're not getting it from the beginning of the line because you have a second MATCH construct on the line, which limits the match to the immediate text instead of the line from the beginning (re-read my post if you want the full line, though I think just fixing this immediate error on your part should give you something infinitely more useable).

procmail: Score: 2 2 "^\/Received:.*\/(\.tw |\.kr|[^0-9.]202\.|[^0-9.]211\.|[^0-9.]6[1-6]\.|bogota\.supernet\.com\.co)"

Note that tells you that there were TWO scoring matches, and (combined with the previous total of 0), a total of 2 overall.

---
 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

<Prev in Thread] Current Thread [Next in Thread>