On 04/24/2014 04:28 PM, John Hardin wrote:
On Thu, 24 Apr 2014, Axb wrote:
On 04/24/2014 04:16 PM, John Hardin wrote:
On Thu, 24 Apr 2014, Nick I wrote:
> Finally i found message caused high load.
> > It looks like one message sent all the time from ticket system.
> Message size is ~4M. We scan messages with this size in amavis.
> > Content of message is complex and has multiple items
> Content-Type: image/gif
> Content-Transfer-Encoding: base64
> Content-Type: application/pdf
> > Results from debug, with % > 1:
> dbg: rules: timing: Total time: 131.6748 s
> dbg: rules: [...] rulename ovl(s) max(s) #run %tot
> dbg: rules: [...] __FILL_THIS_FORM_LONG2 26.3811 26.3811 1 20.04%
> dbg: rules: [...] __FILL_THIS_FORM_SHORT2 26.3050 26.3050 1 19.98%
> dbg: rules: [...] __FILL_THIS_FORM_FRAUD_PHISH1 10.0878 10.0878 1
7.66%
> dbg: rules: [...] __FILL_THIS_FORM_LOAN1 7.2766 7.2766 1 5.53%
> dbg: rules: [...] __FILL_THIS_FORM_SHORT1 2.3360 2.3360 1 1.77%
> dbg: rules: [...] __FILL_THIS_FORM_LONG1 2.3051 2.3051 1 1.75%
That's not too surprising if the content is 4MB.
Would you be willing to share it with me so that I can try to find the
problem with the FILLFORM rules?
Alternatively, you might want to configure your system to not scan
mails
from the ticket system (which I assume is internal and trusted).
Why does this smell like replace_tag noise? (I hate that stuff :)
The FILLFORM rules are complex and inherently repetitive - there's
really no other way to detect a form.
They've had some minor problems with boundedness in the past, but I
thought I had fixed them. Apparently here's another bad case.
seems like a LOT of work going on for the results :)
score FILL_THIS_FORM 1.456 0.001 1.456 0.001
I'd +1 to start from scratch with simpler conditions
