Clamav suggestions

Rick Cooper rcooper at dwford.com
Sat May 5 16:27:52 IST 2007


 

> -----Original Message-----
> From: mailscanner-bounces at lists.mailscanner.info 
> [mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf 
> Of Richard Frovarp
> Sent: Friday, May 04, 2007 12:26 PM
> To: MailScanner discussion
> Subject: Re: Clamav suggestions
> 
> Fabio Pedretti wrote:
> >
> > 3) Support for clamd trough clamdscan is nice, however, 
> best would be 
> > to connect to clamd directly to its socket (or network socket) from 
> > MailScanner, without call clamdscan, and fallback to 
> clamscan if clamd 
> > is not working. 
> 
> Why not just run clamavmodule? From my understanding, the support for 
> clamd was added so that those that didn't want to keep up 
> with the Perl 
> module required for clamavmodule would have something faster than 
> clamscan. Any direct call to clamd from MailScanner would 
> require a Perl 
> module, so at that point you're losing the requirements benefit of 
> running clamd.
[..]

That isn't really accurate. When I remove the clamavmodule scanner from
MailScanner I gain about 78mg of ram (with 3 children) which is certainly a
benefit. Unless the clam team completely revises their clamd protocol (which
hasn't happened as long as I can remember) then there is no concern about
core library changes that break clamavmodule, another benefit. Unless the
team changed the output regarding viruses detected a direct call would just
work. 

I am in the process of incorporating a direct call to ClamD via sockets into
my own MailScanner installs and it wouldn't require additional modules
beyond IO::Socket::UNIX (could be done with just Socket but I prefer the
IO::Socket::UNIX wrapper). Also handles both Unix sockets as well as Inet
sockets. 

The benefit for someone like me is I use clamd with exim, so it's already
running and wouldn't require additional resources and it's very fast (faster
than calling clamdscan). It wouldn't require MailScanner to watch the clam
data files as the freshclam process already notifies clamd as to changes.
Anyone who is using clamdscan would certainly benefit by calling clamd
directly rather than via any of the wrappers.

As far as fallback is concerned I am inclined to add an options for a
restart script if clamd is found to be down, or doesn't respond (properly)
to PING. I have been very busy the last few months so I haven't gotten past
a stand alone proof of concept perl program, but I am hoping to have it
integrated in the next week or so time permitting. If Julian is interested I
would certainly send patches to the list when I am satisfied.

Rick


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the MailScanner mailing list