Ryan Moore ---------- Perigee.net Corporation 704-849-8355 (sales) 704-849-8017 (tech) www.perigee.net
Matthew Trent wrote:
Sorry to beat a dead horse, but what I thought was a harmless error took down Exim last night. I've posted previously (as have others) about this error in my Exim paniclog:
2004-02-10 01:06:04 1AqTqC-00083u-Rd string_sprintf expansion was longer than 8192
It happened about once per minute. It was caused by installing all these great new rulesets (Tripwire, Chickenpox, etc.). These sets are similar in that they are a large collection of small rules which combine to make an effective set. The problem is that each small rule outputs its own entry in the SA report. After hitting a bazillion little rules, the report swells to a huge size, and when inserted into email headers, generates the above error.
I was just ignoring the errors for the time being, figuring those emails were probably spam anyway. What I didn't know is that every time that error hit, Exiscan didn't clean up that message's directory in the scan dir (/var/spool/exim/scan on my system). Eventually the directory hit the max filesystem limit for number of files/dirs and Exim started rejecting incoming mail with "temporary local error".
I realize that's Exiscan's fault, but I think it drives home my contention that reporting every little hit on these huge rulesets is a Bad Thing(tm). As Chris Santerre said today in another thread, this has been a period of many new rules and and heavy rule development. As these new rules show up, I'm sure we'll see reports get longer still. Surely there is a point at which a reasonable limit must be placed, especially for the "Tripwire"/"Chickenpox"-type rules. Additionally, the output from these types of rules is very verbose, and while interesting, most times I don't really care _exactly_ which strings of random crap it's hit on this particular message. :) I'd just like to know it's doing the job and probably how many total rules and points have been hit for each set.
I'm not sure if SA includes that kind of functionality, but IMHO, it would be a good thing to have. Another nice feature would be a configurable cap on report size.
In the mean time I've altered my report to be smaller. However, I consider that a work-around, not a fix. The error could still happen with my more terse report, if enough rules hit.
PS:
In creating my new report, I'm trying to use _TESTSSCORES()_, but I'd like a newline as the delimiter. I've tried \n and ^M, but \n is just printed and ^M doesn't seem to have an effect at all. Any ideas?
