I've yet to receive any responses to my mail (below); do any of the (main) developers have any preference/input on my ideas, or should I just go ahead and come up with a patch?
On Wed, Jun 09, 2004 at 10:59:06AM +1000, Rudolph Pereira wrote: > Hello, > we are currently using clamav (clamd) in conjunction with mimedefang to > scan mail items. Our scanning policy, and what we'd like to continue > doing, is to mark items that we can't scan as suspicious. This includes > items that exceed the limits we have in place for archives, maxfiles, > etc. > > At the moment, we're using an older version of clamav with local > patches, one of which passes back errors due to limits > (e.g CL_EMAXSIZE, CL_EMAXFILES) rather than ignoring them > and passing back ok - this allows us to do what I've described above. > > Although the changes are minimal, previously when posting the patch to > the clamav lists, it encountered resistance, as some do like the > existing behaviour. > > As part of an upgrade, I am currently reworking the > patch to apply to the latest clamav versions. I would very much like to > redo the patch so that it is applicable generally and more likely to get > applied into the official clamav source. So, my question is: what > recommendations do people have so that this is most likely? > > My plan is to make this into a configurable option (in clamav.conf to > cover clamd, and as an option to clamscan) - would this be sufficient? > And in that case, would people be happy to have this option only return > if a limit is reached, whereas we continue where it makes sense (e.g > continue if we had a handler/decompressor error, in cases such as > clamscan where we might want to try external decompressors). Or, would it > be better to come up with a scheme where only errors below a certain > configurable value (but above 0) cause a return, otherwise we continue > (and if so, are the error values stable enough to do this?) > > I would also like to extend this scheme to encrypted files; rather than > return them as "infected", it makes more sense to us to mark them as > suspicious and handle them differently. This again could possibly be > handled via a similar option as above. > > Any thoughts would be appreciated. ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Clamav-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-devel
