Re: [exim] timeout for av_scanner?

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] timeout for av_scanner?
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.