ANNOUNCE: Stable 4.29.7 released

[Julian Field]

At 21:19 06/04/2004, you wrote:
>Le jeu 01/04/2004 à 10:45, Julian Field a écrit :
> > At 16:44 01/04/2004, you wrote:
> > >Le jeu 01/04/2004 à 10:19, Julian Field a écrit :
> > > > At 15:14 01/04/2004, you wrote:
> > > > >Julian,
> > > > >
> > > > >Le jeu 01/04/2004 à 08:53, Julian Field a écrit :
> > > > > > At 14:49 01/04/2004, you wrote:
> > > > > > >Hello Julian,
> > > > > > >
> > > > > > >Le jeu 01/04/2004 à 04:15, Julian Field a écrit :
> > > > > > > > I have just released stable 4.29.7.
> > > > > > > >
> > > > > > > > - Zip archives detection improved to work by content rather 
> than
> > > > > filename.
> > > > > > >
> > > > > > >Does that mean that a zip archive will be detected and ist 
> contents
> > > > > > >scanned even if its name doesn't end in .zip?
> > > > > >
> > > > > > Yes.
> > > > > >
> > > > > > >I hope not because I've been telling people to rename their zip
> > > file to
> > > > > > >something else to avoid the contents checks.  And since I 
> don't use
> > > > > > >filetype checks it works just fine.
> > > > > >
> > > > > > And one of the virus writers started writing zip files but 
> ending their
> > > > > > names in ".rar" in the knowledge that Winzip would still open 
> them.
> > > So it
> > > > > > had to go content-based, sorry.
> > > > >
> > > > >Bummer!  I was already blocking rar files...
> > > > >
> > > > >Could it be modified to use the File Command setting (that I have 
> set to
> > > > >blank) to decide if it reacts that way?
> > > >
> > > > I need to test lots of files and I can detect zip files by just 
> looking at
> > > > the first 4 bytes, which is *way* faster than running the file 
> command and
> > > > parsing all its output.
> > >
> > >I understand but could you omit this test if the file command setting is
> > >set to blank (indicating that we don't want to do that sort of test)?
> >
> > 1-line patch to Message.pm:
> > -----SNIP-----
> > --- Message.pm.old      2004-04-01 16:47:00.000000000 +0100
> > +++ Message.pm  2004-04-01 16:49:24.000000000 +0100
> > @@ -1246,6 +1246,7 @@
> >
> >         # Find all the zip files
> >         #print STDERR "Looking at $explodeinto/$part\n";
> > +      next if MailScanner::Config::Value('filecommand', $this) eq "";
> >         next unless $file->open("$explodeinto/$part");
> >         #print STDERR "About to read 4 bytes\n";
> >         #$file->open("$explodeinto/$part") or next; # Skip if it can't 
> be read
> > -----SNIP-----
> >
> > That should do it. I'll put it in the next release, as it's not a bad 
> idea :-)
>
>Julian,
>
>I just had some time to test this and it seems broken...
>
>Without the patch if I send a zip file named file.zip with an exe
>inside, it is blocked as expected.  If I send the same zip file renamed
>as file.zip.txt it gets through.  Not sure this is expected... but this
>is the behaviour I am looking for.
>
>With the patch, my file.zip file containing an exe gets delivered as
>is.  Same thing for a renamed zip file containing the same exe.

I have already abandoned that configuration tweak and added a switch to 
find zip files by name or by content, as that is really what we mean anyway.
-- 
Julian Field
www.MailScanner.info
Professional Support Services at www.MailScanner.biz
MailScanner thanks transtec Computers for their support
PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654