Ruairi Hickey wrote:
> 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.
>
Indeed, you should maybe not accept huge files without scanning them.
However, what is the purpose of a virus if it needs a 10MB+ file to be
propagated to other systems? What I mean is that virus generally don't
take more than 1MB because if they were, they wouldn't spread fast
enough or efficiently enough to do what they are designed to do. So as a
general rule of thumb, it is probably quite pointless to scan emails of
more than 1Mb for viruses. It is probably also pointless to scan them
against spam.
