multi-volume RAR archive problem

[Rick Cooper]

If this is causing an issue the fix would be in the unpackrar function to
test if the file is part of a multi-volume archive and not try and extract
the file. But this is the same as allowing multipart emails, I wouldn't do
it because there is no way to virus test a multipart attachment. Of course
there could be a new config option to allow multi-volume rar (or maybe
archives in general?) files that was rule based so you could allow a file
name pattern from your own users and disallow from all else.
 
Testing for the multi-volume is fast and pretty easy. Command line would be
:
    /path/unrar lv FileName
Output would be either 
----------------------------------------------------------------------------
---
    1        185500442 52428702  28%       volume 1
                     ^            ^                           ^        +--
Volume Number
                     |            |                           + -----------
The Word Volume    
                     |            +----------------------------------------
The size of this file
                     +-----------------------------------------------------
Total size of combined volume
or
 
----------------------------------------------------------------------------
---
    0                0 52428702   0%       volume 2
 
The first number is 1 for the first part and zero for the others so if the
file size is known a regex (with all white space truncated to one char, no
leading or trailing)
    /^\d+\s\d+\s$FileSize\s\d+\%\svolume\s+$/, the file size part is just
insurance we don't hit the string somewhere in the listing but really I
think just adding
another \d+ would suffice
If this regex hit (and could probably just change the $FileSize to another
\d+) you would know it was part of a multi-volume set.
To me this is an overly complicated change to accommodate a one off
situation. Can you not just enter pass in one of the file rules sets?
 
I am looking at the unrar code and as I thought the lv is already used to
check for password protection so changing the relevant part to:
 
  foreach $what (@test) {
    #print STDERR "Processing \"$what\"\n";
    # If we haven't hit any ------- lines at all, and we are prompted for
    # a password, then the whole archive is password-protected.
    unless ($BeginInfo || $EndInfo) {
      if ($what =~ /^Encrypted file:/i && !$allowpasswords) {
        MailScanner::Log::WarnLog("Password Protected RAR Found");
        return "password";
      }
      if ($what =~ /^\s+\d+\s+\d+\s+\d+\s+\d+%\s+volume\s{0,}$/i) {
        MailScanner::Log::WarnLog("Multi-Volume RAR Found");
        return "multivolume";
      }

    }

This would prevent MailScanner from attempting to unpack the file and if the
return is multivolume MS could handle it according to a configured setting,
or default to rejecting outright instead of trying until it hits maxfail and
rejects it.
 
Back to Julian
 
Rick


  _____  

From: mailscanner-bounces at lists.mailscanner.info
[mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf Of Curu Wong
Sent: Tuesday, January 25, 2011 12:46 AM
To: MailScanner discussion
Subject: multi-volume RAR archive problem


Strictly speaking, I am not sure if this is a problem.

We can create multi-volume(split volume) RAR archive with the WinRAR, and
send them out one by one via email. When one message arrives at MailScanner,
it will try to unpack that volume(part of the complete archive), which
should definitely fail. and then ms restart itself and try and fail and try
and fail, then give up processing that message, block it.

My question is, what's the better solution? can we tell if a RAR archive is
multi-volumed and just skip processing it? Is it a good policy to restart ms
itself(due to external failure) and do the exact same(should always fail)
action toward the offending message?

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20110125/c5536f1d/attachment.html