era asked:
... and so on, something like 60-80 lines of addresses. And bang, I
get a core dump in my MAILDIR. (The header above was actually grabbed
out of the core dump with strings(1) ... lots of other interesting
stuff inside that core image, such as something that looks a lot like
users at my host with home directories and preferred shells, but I
digress.)
You get the core dump when you use $MATCH in your logging, and not when
you do the match, yes?
* ^\/Apparently-To..?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?\
.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?.?
but this is +slightly+ too cumbersome to use in every single recipe
that contains a \/ -- which is practically all of them, because I want
to log what happens and on what grounds spam is being identified.
Can anybody come up with something neater? As an aside, it would be
nice to know if indeed nobody else ever runs into core dumps when you
massively exceed LINEBUF. (I believe my mail host is actually running
3.11pre4 but I think I found the same problem in 3.11pre7 on a
completely different architecture.)
I use something (very much) like:
:0
* ! ^To:[ ]+\/[^ ].*
* ! ^Apparently-To:[ ]+\/[^ ].*
* ! ^Resent-To:[ ]+\/[^ ].*
{ Missing to handled here }
:0 E
* MATCH ?? ,[ ]
* MATCH ?? ()\/[^,]+,[ ]+[^ ]+
{ TOO="(trimmed) $MATCH" }
:0 E
{ TOO=$MATCH }
This picks up the first two addresses when there is a comma (ignoring
comments) and the only address otherwise, thus carefully avoiding
instantiation of overlong strings in MATCH. My LINEBUF violations ended
when I implemented this.
--
Rik Kabel Old enough to be an adult
rik(_at_)netcom(_dot_)com