ANNOUNCE: Stable 4.29.7 released

[Denis Beauchemin]

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 checked and my zip files all start with PK\003\004.

My conf file has:
File Command = #/usr/bin/file

I made sure to stop/start (not just reload) MS between tests.

Denis
-- 
  _
 °v°   Denis Beauchemin, analyste
/(_)\  Université de Sherbrooke, S.T.I.
 ^ ^   T: 819.821.8000x2252 F: 819.821.8045