On Fri, 2004-04-16 at 01:00, Jeffrey Goldberg wrote: > But we still haven't clarified (or maybe I missed it) whether there is > a memory leak in clamav or whether the huge file caused the problems > leaklessly.
I don't want to repeat the condition to test again, but I am pretty sure that clamd leaked memory. It did not crash immediately on the first attempts to forward these messages but after some (dozens?) of attempts it would take all of the machine's RAM and eventually swap. Restarting clamd would clear it up. It may be related to the outlook winmail.dat encoding of a zip file as well as the size. Maybe it wouldn't happen with normal MIME. I think if clamd just died at a certain memory consumption level, mimedefang would have handled things correctly and there might be a way to arrange that. > I should note that the example/default mimedefang-filter has > a condition on it to not run spamassassin on very large messages. It > might be safe to do the same with virus scanning. A worm so large that > most mail hubs would reject on size is not really going to propogate very > far. I think that would just beg the virus writers to exploit the hole. > > > Use ftp for larger messages. > > > > I agree. Large files should be transfered using something other than > > email. > > Just to be picky, I always recommend http in the hopes that someday ftp > will just go away. > You make this sound easy when in fact you are talking about huge security issues. My particular instance was just dumb because the file the user was trying to send was already on our public ftp server, but that isn't always the case. How do you suggest moving a big file that should be confidential between two users that don't have write access to a server or a password in common? --- Les Mikesell [EMAIL PROTECTED] _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang