The Friday 2004-07-02 at 23:16 +0200, Theo v. Werkhoven wrote:

...

I have some rules in "/etc/postfix/header_checks" to reject windows executables; but they are not working, they are being handled by amavis_new. How do I restore header_checks to scan before amavis_new?

The Postfis header- and bodychecks will always be done before piping the mail to the content-filter. If they're not working there's something wrong with these checks.

The file is the same one I had before upgrading... hold on, it is dissabled in /etc/postfix/main.cf: #header_checks = regexp:/etc/postfix/header_checks Thanks, you pointed me to look again :-)

To disable the amavis checks read amavis.conf

That is a goog bedside reading: as soon as I start reading it, my head starts nodding strangely to the sides :-p

# * leave $banned_filename_re undefined to disable these checks # (giving an empty list to new_RE() will also always return # false)

$banned_filename_re = new_RE( qr'\.[a-zA-Z][a-zA-Z0-9]{0,3}\.(vbs|pif|scr|bat|com|exe|dll)$'i,

However, there is no .zip there, and it seems to be rejecting zip files. For example, I see in a report bounced to me: |The message WAS NOT delivered to: |: | 550 5.7.1 Message content rejected, id=09888-09 - BANNED: .exe | |The message has been quarantined as: | /var/spool/amavis/virusmails/virus-20040705-115345-09888-09 I look at the quarantined file, and I see: |X-Amavis-Alert: BANNED FILENAME, message contains part named: .exe ... |Content-Type: application/octet-stream; | name="Bill.zip" I'm sure that zip archive contains a virus, but that is not the point. As far as file ataches, it must pass; then, if it a virus, it must be reported and rejected as a virus, not as a banned file name. Then, I find it is trying to send back bounces to external addresses, when it should _never_ do so: |nimrodel:/etc/postfix # mailq |-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- |22FE7DF675 5459 Mon Jul 5 11:59:10 MAILER-DAEMON |(Host or domain name not found. Name service error for |name=copamericaperu.com.org type=MX: Host not found, try again) | ipinasco at copamericaperu.com.org Looking at the contens of that mail, I find: |From: amavisd-new |To: <ipinasco at copamericaperu.com.org> ... |BANNED CONTENTS ALERT | |Our content checker found | banned name: .exe |in email presumably from you (<ipinasco at copamericaperu.com.org>), to the |following recipient: |-> cer@localhost.nimrodel.valinor | |Delivery of the email was stopped! ¡I don't want amavis-new to send _any_ report, bounce, reject message or anything to any body whatsoever outside of my machine! I want it to report only to ME. I'm modifying the from addresses amavis uses: $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 "'; Then I close them in the access file: amavis_new.virusalert@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor amavis_new.spam.police@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor amavis-new.postmaster@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor Let us see if that works :-) -- Cheers, Carlos Robinson

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" '; and then, in "/etc/postfix/access" I explicitly dissable those addresses from bein able to send: amavis_new.virusalert@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor amavis_new.spam.police@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor amavis_new.postmaster@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor Both things, the warnvirussender=0 and the redirect clauses ensure they don't get sent outside. -- Cheers, Carlos Robinson

On Thursday 08 July 2004 05:04, Michael W.Cocke wrote:

On Thu, 8 Jul 2004 01:26:05 +0200 (CEST), you wrote:

...

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

That's a good thing.

...

and 2) not trusting filename extensions but instead using the output of the command "file".

And so is that.

...

This behaviour can be dissabled, and I have done so:

But that really isn't. At least not if you want amavisd to be as effective as possible...

...

...

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" ';

and then, in "/etc/postfix/access" I explicitly dissable those addresses from bein able to send:

amavis_new.virusalert@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor amavis_new.spam.police@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor amavis_new.postmaster@nimrodel.valinor REDIRECT virusalert@nimrodel.valinor

Both things, the warnvirussender=0 and the redirect clauses ensure they don't get sent outside.

Why are you going to such lengths to disable a large part of your system security? There's an excellent reason why amavis "is overly clever".

My thoughts exactly... -- Jarod C. Wilson, RHCE jcw@wilsonet.com