Re: [AMaViS-user] Clamav amavisd-new and optional depackers

This is a discussion on Re: [AMaViS-user] Clamav amavisd-new and optional depackers within the Amavis User forums, part of the Anti-Spam and Anti-Virus Related Forums category; Michael, > For 'all' of the depackers, if we are using Clamav and clamav can do ALL > the unpacking ...


Go Back   Usenet Forums > Anti-Spam and Anti-Virus Related Forums > Amavis User

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 12-04-2006
Mark Martinec
 
Posts: n/a
Default Re: [AMaViS-user] Clamav amavisd-new and optional depackers

Michael,

> For 'all' of the depackers, if we are using Clamav and clamav can do ALL
> the unpacking for us, would it be a memory saving device to undef ALL of
> the unpackers in @decoders?


Yes, there is some memory saving there (about 3 MB of virtual memory),
but is pretty small portion of total memory if SA is also being used.

See:
http://marc.theaimsgroup.com/?l=amav...16370039830493

Perhaps processing savings are more obvious, which of course depends
on mail structure and contents, and user habits.

Drawback of disabling decoding in amavisd is you lose mail bombs protection
for virus scanners (it is often better in amavisd than a similar mechanisms
within a virus scanner), and the ability to block on banned mail components
within archives.

> Are there any here that are needed by amavisd-new given that clamav
> should be able unpack everything?
> (or is clamv missing some things)


> Would an EXTERNAL decoder be 'best for memory, worst for speed'?


Not necessarily, external decoder is often best for speed,
at least for larger archives. Additional benefit of external decoder
is that if something goes badly wrong within the decoder, it does
not bring down the Perl process running amavisd.

> Assuming an external decoder isn't called unless it needed, but would
> require directory lookup, disk access (and then memory used anyway)
>
> I also note 'doc' decoder repole is disabled.. Not needed? Unsafe?


At the time I added support for ripOLE the ripole project was considered
experimental/alpha. It also could not decode several types of OLE documents.
To be on the safe side I let the entry be commented out. I'm not sure
what is the current status of the project.

> Does this mean that amavisd-new won't 'decode' word doc 'spam' and pass
> it to SA?


Decoding is only of concern for viruses and banned checks,
SA does its own decoding the way it likes, and does not benefit
from decoding done by amavisd.

Mark

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?p...rge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/...fo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 12:50 AM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0