<html>
  <head>
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    I apologize if this has been answered in another thread.&nbsp; I did
    spend quite some time poking through the archived mailing list
    articles, the MailScanner docs, and googling around, but we are just
    stumped and are hoping a MailScanner guru could enlighten us about
    this situation.<br>
    <br>
    First, we are running the following (from /usr/sbin/MailScanner -v)
    - <br>
    This is SUSE Linux Enterprise Server 10 (x86_64)<br>
    This is Perl version 5.008008 (5.8.8)<o:p></o:p><br>
    This is MailScanner version 4.78.17<br>
    Using F-Prot for AV scanning<br>
    <br>
    High level overview - We use Barracuda's for our mail gateways that
    hand off to MailScanner before getting routed to the appropriate
    mail server for delivery.&nbsp; This solution has worked great for years,
    but last week something strange happened that we cannot figure out.<br>
    <br>
    On Friday we started receiving emails that contained some kind of
    0-day malware.&nbsp; The Barracudas were blocking some of these email,
    but based on score and not on the emails containing a virus.&nbsp; Later
    in the day Barracuda started recognizing the virus so the problem
    was mitigated at the mail gateway, but some did slip by the first
    line of defense and were passed to MailScanner.&nbsp; <br>
    <br>
    The attachment was a zipped up EXE file, but something was unique
    about these messages.&nbsp; We block ZIP and EXE files to most of our
    users, but our MailScanner instance was not acknowledging these
    emails contained a ZIP file and therefore not doing the "Filename
    Check".&nbsp; What is very interesting is when MailScanner delivered the
    email to an invalid recipient and it was bounced back to the sender,
    MailScanner detected the existence of a ZIP file and blocked it on
    the way out!&nbsp; But not on the way in!&nbsp; This is the heart of the
    issue... how can we determine why these messages were not
    interrogated while other (legit) zip files were being rejected at
    the same time?<br>
    <br>
    We observed these emails were encoded with windows-1251 encoding
    (<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Windows-1251">http://en.wikipedia.org/wiki/Windows-1251</a>) and the content type of
    the attachment was simply "Content Type ;"&nbsp; Other than that, we did
    not see anything out of the ordinary with these emails.&nbsp; <br>
    <br>
    We tried to create a zip file of the same name as the malware and
    send it from gmail and the ZIP file was detected immediately by
    MailScanner, so we were not able to reproduce the problem strictly
    by name.&nbsp; Now that F-prot is detecting this, its getting dropped for
    containing a virus, and we can really cannot test further in our
    production environment.&nbsp; We took this into our lab, but we were not
    testing with the exact same version of MailScanner and we were not
    able to recreate the problem.&nbsp; In our minds, whether MailScanner
    could detect the virus or not, it should have detected the ZIP
    and/or EXE and rejected it for this reason alone.&nbsp; <br>
    <br>
    Any information about this issue would be greatly appreciated.&nbsp;
    Management is now questioning the usefulness of MailScanner versus
    some commercial offering, but I believe in FOSS.&nbsp; Thank you in
    advance for taking the time to read this post!<br>
    <br>
    Regards, <br>
    <br>
    Tony &nbsp; &nbsp; &nbsp; <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>