David F. Skoll wrote:
> Hello,
> 
> A client of ours had a bunch of machines whose CPUs were maxed out
> at 100% because of clam.  Changing PhishingScanURLs to "no" from the
> default "yes" dropped the load average from 70+ to about 3, and the
> CPU usage from 100% to under 50%.  This is under Linux, so it's not
> the broken Solaris regex library at fault.
> 
> I have two questions, a practical one and a philosophical one:
> 
> The practical one: Do others observe the very poor behaviour
> of PhishingScanURLs?  Is it perhaps hitting pathological cases of regex
> evaluation?
> 
> The philosophical one: Do heuristics like PhishingScanURLs belong in a
> virus scanner?  I realize that once the engine is in place, it's
> tempting to add features, but I'm not convinced such things belong in
> a virus scanner.  I think they are more in the domain of anti-spam
> software, especially since it's good for security to keep your
> virus-scanner small, fast and secure and do more complex text analysis
> in a language other than C.  I guess I would vote for PhishingScanURLs
> to be "no" by default rather than "yes".

I'm having a similar problem here.  Except I can't turn it off (I'm 
calling clamav via perl Mail::ClamAV).  But I can reliably take a 
message that was clogging my mail server, scan it with clamscan, and 
either have it completely hang without any arguments ... or have it 
finish almost instantly if I turn that off with a CLI argument.

I would be happy to either have it off by default ... or to have the 
option for turning it off added to Mail::ClamAV (tried to email the 
maintainer, but haven't had a response).

However, I _am_ experiencing this on Solaris (10, x86, on Sun Opteron 
boxes).

I can produce 2 examples of messages that cause the problem, in RFC822 
format, for anyone who wants to experiment with them.

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html

Reply via email to