We delete encrypted zip files if we can't decrypt them. Zip encryption isn't (typically) very strong, and in some cases we can decrypt the file and scan it.
However, if we can't scan it, we don't let it through. In part this is because of regulatory requirements for handling of confidential data -- zip encryption isn't strong enough, and this stops users, both inside and outside Citigroup, from sending possibly sensitive data using a mechanism that is not appropriate. > A third option is to list the zip file directory and reject it if it > contains either another zip file or any banned extensions. Zip > encryption encrypts the file contents, but it doesn't seem to encrypt > the directory listing -- I tested an "unzip -l" on a captured > encrypted virus, and it listed the .exe just fine. > > We're going to look at integrating Archive::Zip into mimedefang, because this > is becoming an issue for our CanIt customers also. Just started doing this here (well, I'll be testing it next week). I might be able to send you proof of concept code if I can get the necessary sign off. One of the things I've discovered from a simple test script is that Archive::Zip on Solaris (or one of its dependencies) has memory leaks. Take a look at http://people.freebsd.org/42/42.pl. This should (safely) process 42.zip, at the same location. Don't try and extract 42.zip yourself -- it recursively unextracts to 4.5 petabytes. On FreeBSD, Linux, and a bunch of other operating systems, perl 42.pl 42.zip uses a steady 8 - 10MB of RAM. On Solaris (at least, Solaris 2.8 plus whatever patches we have here) it's RSS grows without bounds until it eventually reaches the per-process memory allocation limit and gets killed. N _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
