spamass-milt-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New question about interaction between spamass-milter and clamav.


From: Andrew Daviel
Subject: Re: New question about interaction between spamass-milter and clamav.
Date: Tue, 7 Jul 2009 19:06:00 -0700 (PDT)

On Tue, 7 Jul 2009, Steven W. Orr wrote:

INPUT_MAIL_FILTER(`spamassassin',
   `S=local:/var/run/spamass-milter/spamass-milter.sock, F=,
T=C:15m;S:4m;R:4m;E:10m')dnl


But now I'm also seeing retries when clamav is deciding that the status is
unknown. Somehow, spamass-milter is returning a 4.5.1

I wondered if you had a timeout. But with F='' (not F=T) it is supposed to fail "safe", i.e. accept the mail. At one point I had a config where it delayed mail when clamd was not running. That might have given a symtom of retries if clamd took too long to parse some big message (or if spamd/clamd had a bug that made it take excessive CPU time for certain input).


On which subject, I was going crazy a while ago with ridiculous CPU times for certain Perl regex.
Given
$_ = "Jun 19 11:17:59 foobar mountd[4321]: authenticated unmount request from 
radon.example.com\n" ;

/(.*[\d]+).*mount.*radon/ took 11us in Perl 5.8.8, but 2ms in Perl 5.10.0 (or maybe the other way round). That's a factor of 180. /(.*[\d]+).*radon/i took 13us in Perl 5.10.0 cf. the 2ms for the previous regex.

These regex times were also strongly dependant on the input string.

Spamassassin is full of this kind of check, but typically uses limited ranges like \d{1,9} rather than \d+, I believe to avoid over-greedy body checks. I've not tried benchmarking spamd with different Perl and different messages, though.

--
Andrew Daviel, TRIUMF, Canada
Tel. +1 (604) 222-7376  (Pacific Time)
Network Security Manager




reply via email to

[Prev in Thread] Current Thread [Next in Thread]