Miha, On Feb 24, 2010, at 10:37 AM, miha vrhovnik @ domenca wrote: > "Michael Scheidell" <[email protected]> wrote on 22.2.2010 16:20:15: > >> On 2/22/10 3:30 AM, miha vrhovnik @ domenca wrote: >>> >>> >> you can already tell clamav not to unzip past (x) number of levels, and > as zip is uncommented in amavis config file in @decoders section and a large > amount (1000)of partX files was in ./parts directory I believe decoding is > already done by amavis.
If you are checking the whole email (email.txt) (with $bypass_decode_parts = false), then you get the whole email and the whole parts combined together, so basically you clamav needs to check your emails (body part + attachments) at least twice. (Check the amavisd.conf settings for deep explanation of bypass_decode_parts and other settings). My recommendation would be to turn off the clamav uncompressing features (ScanArchive no), or tune the limits for uncompressing to be able to scan such emails that your machine could handle (since I believe that your machine is unable to handle the full load of scanning your emails). >> you can already give it a max archive size. >> the tmp dir cleanup can be done with a cronjob and find -mtime options. > How old directories I'm supposed to remove? 1h, half a day? I doubt that this > would help much in a case I had. I had 2 legit! messages one just under 20M > in size (this is the max server would allow) which had a zip file with 20 or > so bmp files zipped in.. uncompressed size was around 120M + message itself > 140M. The other was 8M in size with 5,5M zip file which contained 14 zip > files with total above 1000 files mostly js, html, gif, css.. also around > good 100M of decompressed files. Both of this messages burnt 50G of free > space during the night! If you stop amavisd, the daemon should remove all temporary files that were in use at particular time. For all other directories in $TEMPBASE directory, which are there after stopping amavisd, there is a reason for being there. Usually amavisd retains them for your analysis and you get log line something like "PRESERVING EVIDENCE in ..". If I remember right, Michael already adviced a rule of a thumb a while ago for $TEMPBASE directory retention policy, which is I believe: you can safely delete $TEMPBASE/dirs which are older that one day, if you are not inspecting them, why there weren't processed sucessfully. regards, Jernej ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
