Author: Phil Pennock Date: To: John Horne CC: Exim users Subject: Re: [exim] malware_name not reporting correct name?
On 2010-08-27 at 14:41 +0100, John Horne wrote: > On Fri, 2010-08-27 at 14:28 +0100, John Horne wrote:
> > Hello,
> >
> > Using exim 4.72 I have been trying to track down a problem where mail
> > with some form of detected malware has been rejected. We tend to reject
> > anything detected by ClamAV's own signatures, but mark those which are
> > 'UNOFFICIAL'. This has worked fine, but we are now seeing some mail
> > rejected and the reported malware name - from the malware_name variable
> > is (e.g.): 457)
> >
> > This is the actual name being reported by 'malware_name' - '457)'.
> > Our logs show that other messages have been rejected, with the number in
> > the message varying.
> >
> > It seems that the InetMsg spamdomain third-party signatures are being
> > reported by ClamAV as (e.g.):
> > INetMsg.SpamDomain-2m.engduates_com.UNOFFICIAL(924747f3c8e4b999eb887c755839021b:457)
> > Our clamd log file shows the same name as being detected.
> >
> A bit more info:
>
> We are using ClamAV 0.96.2 and have enabled the 'ExtendedDetectionInfo
> yes' option. this is where the '(...:457)' comes from. We have now
> disabled the 'ExtendedDetectionInfo' option and the malware_name is
> reporting the names correctly.
This is very plausible. The expected results from ClamAV are:
infected: -> "<filename>: <virusname> FOUND"
not-infected: -> "<filename>: OK"
error: -> "<filename>: <errcode> ERROR
and the code does a strrchr() to find the colon. FWIW, this parsing has
not (yet) changed with the 4.73 ClamAV re-working, so an upgrade won't
help you.
The documentation for ClamAV only documents the FOUND and OK cases and
states that "When a virus is found its name is printed between the
filename: and FOUND strings."
Clearly the parse logic in Exim needs to be a little more careful. I'm
apparently in the middle of developing a head-cold which is messing up
my ability to think clearly, so don't feel that any code I wrote now
would be worth the electrons used to encode it. So, patches welcome.
:)
