Re: [exim] timeout for av_scanner?

Top Page
Delete this message
Reply to this message
Author: Ruairi Hickey
Date:  
To: exim-users
Subject: Re: [exim] timeout for av_scanner?
On Tuesday 20 March 2007 08:43:27 W B Hacker wrote:
> Heiko Schlittermann wrote:
> > Hello,
> >
> > does anybody know about some timeout for av_scanner? We have some huuge
> > mails sitting in our queue, exim tries to retransmit them, on the
> > receiving side is some exim running too. (Both 4.63). But these messages
> > don't go through.
> >
> >     # global
> >     av_scanner = clamd:/var/run/clamav/clamd.ctl

> >
> >     begin acl
> >     ...
> >     acl_check_data:
> >     deny    malware    = *
> >             message    = This message contains a virus
> > ($malware_name).\r\n\ CONTACT

> >
> > But with huuge messages (42MB) clamav seems to timeout:
> >
> >     07:49:31 [25911] 1HTBay-0006jv-T4 malware acl condition: \
> >                      clamd: unable to read from socket (Connection timed
> > out)

> >
> > Which of exims timeout settings bites me here? (is the
> > local_scan_timeout used?)
> >
> > Thanks in advance.
> >
> >     Viele Grüße aus Dresden
> >     Heiko Schlittermann

>
> One is generally better-off limiting the size to be scanned, rather than
> time allowed, as the evidoers seldom send really big files [1]. Too
> impatient, and even if stolen b/w were an infinite resources, hours in the
> day are less so.
>
> We allow MSG_MAX of 800 MB (one CD+), but SCAN_MAX of only 4 MB, have
> tested with far larger before setting up a secured https for exchanging
> problematic CAD/CAM files that should not really be smtp'ed anyway.
>
> No matter how much you extend smtp timeouts, even when the majority of such
> traffic is between/among servers under your control (pointless to do
> one-end only) and on good backbone b/w, the poor end-user is likely to hit
> the wall much earlier due to limited local tail circuit b/w on submission
> or retrieval.
>
> Result? We had seen typically five copies of a file that actually completed
> 4 times, but did not succeed in exchanging the 250-OK handshake until the
> fifth go-round. Not welcome at the desktop, as it prevents seeing other
> mail for too long a period, not to mention filling up HDD and slowing down
> MUA in indexing, searching, et al. FedEx'ing or motorcycle courier-ing
> removable media can sometimes be faster.
>
> HTH,
>
> Bill
>
> [1] n-recursive Zip/archive bombs aside. Limit the ClamAV recursion depth
> to protect aganst that.



From a security point of view if you are not going to scan large files for
viruses then you should not accept them, ie max message size < max scan size
otherwise a virus / malware has a path into your organization.

Ruairi