The Tuesday 2004-07-06 at 10:59 -0700, Jarod Wilson wrote:
|Content-Type: application/octet-stream; | name="Bill.zip"
Perhaps the file is actually called Bill.zip.exe, or maybe there are multiple attachments. But amavisd appears to be functioning correctly.
No, that was not the problem. The "problem" is that amavis-new tries to be overtly clever by: 1) looking inside zip files for exe files and 2) not trusting filename extensions but instead using the output of the command "file". This behaviour can be dissabled, and I have done so: # set $bypass_decode_parts to true if you only do spam scanning, or if you # have a good virus scanner that can deal with compression and recursively # unpacking archives by itself, and save amavisd the trouble. # Disabling decoding also causes banned_files checking to only see # MIME names and MIME content types, not the content classification types # as provided by the file(1) utility. # It is a double-edged sword, make sure you know what you are doing! # #Cer $bypass_decode_parts = 1; # (defaults to false) ...
Double-check your amavisd.conf, there's a place in there to configure that behavior.
Unfortunately, that program should have a man page at least. Better, a documentation directory with samples. ...
Look for $warnvirussender and disable it.
It was already dissabled, by the default settings:
#$warnvirussender = 1; # (defaults to false (undef))
I have explicitly dissabled it now - I can not trust the default being
"false":
$warnvirussender = 0; # (defaults to false (undef))
An that seems to work, but only with the help of the next trick:
$mailfrom_notify_admin = "amavis_new.virusalert\@$mydomain";
$mailfrom_notify_recip = "amavis_new.virusalert\@$mydomain";
$mailfrom_notify_spamadmin = "amavis_new.spam.police\@$mydomain";
$hdrfrom_notify_sender = '"amavisd_new.postmaster"