Oliver,

> > You can add a catchall rule to the end of the $banned_filename_re list
> > to block everything else which isn't explicitly allowed by rules
> > earlier in this list. (but you may not like the result)
>
> I tried this with: qr'.*' at the end, but then i found out, that not
> only mime-type is looked up in this list, but also the FILENAME of
> the attachment. This will make a default-block-rule impossible,
> because it would match those names at least.

The $banned_namepath_re mechanism is much more flexible
that the older and simpler $banned_filename_re - but is also
more tricky to do right (understanding regexps is a must),
which is why I'm not pushing people to use it for more
common needs.

With $banned_namepath_re you get a complete path to each
mail component as a single string, with attributes for each
parent node, like M for mime-type, T for short file(1) type,
N for file name, P for internal part name and L for its placement
in the mail message tree, and A for some additional attributes
like C for (en)crypted and U for undecipherable.

At log level 5 (less detailed at levels 4 and 3) you can see
how each mail part is characterized. I's sorry that this is
currently poorly documented. See also README.banned for some
collected examples, and amavisd.conf-sample for some sample rules.

> The things i complaing about are:
> - If decompression fails, all action done is to log a message.

Depends. If a decompressor encounters an unexpected error (like
disk full, internal error etc), the mail will tempfail and stay
in the MTA queue, and the problem is logged. You have a couple
of days to fix the problem, while the message is staying
in the MTA queue.

If an error is expected (like corrupted archive for certain
archive types, most often for ascii files which may or may not have
some internal structure), only a warning is logged. There is still
a virus checker there in the food chain, with its bag of decoding tricks.

For executables, a couple of decoders are used just in case to see
if it turns out the file is an self-extracting archive.
Failures in this case are normal and expected, they only
indicate an executable is not a self-extracting archive.

> The mail could not be sorted out for "human" handling.

If a mail contains an non-decodable part (e.g. a password protected archive),
it is flagged as such. You can uncomment a rule qr'^UNDECIPHERABLE$' in 
$banned_filename_re (or equivalent in $banned_namepath_re) and such mail
will follow the setup for banned files. A header field:  X-Amavis-Alert: 
BANNED, message contains... is inserted, if banned mail is allowed to pass.

Search for 'undecipherable' in RELEASE_NOTES for details.

> Also all remaining parts will not be decompressed.

This is not true.

> The worst thing is that virus-checking for such malicious files will be 
skipped, so there is a good chance that viruses pass through !

This is again not true, virus checking is not skipped
even if some parts are not decoded by amavisd-new. There is
a good chance the virus checker will still be able to recognize
a virus, if the mail is infected.

The only case where virus checking is skipped is when a mail bomb
is encountered (deeply recursively nested archives which expand to huge size). 
If such mail is passed it gets '***UNCHECKED*** ' inserted in the subject 
(configurable), and X-Amavis-Hold: ... header field is inserted.
MTA may treat such mail differently (with the use of header_checks).

Also the mail contents in this case is wrapped in an additional MIME layer
(poor-man's defanging). 'Defanging' can also be requested for other types
of mail contents:
  $defang_virus  = 1;  # default is false: don't modify mail body
  $defang_banned = 1;  # default is false: don't modify mail body
  $defang_bad_header     = 1;  # default is false: don't modify mail body
  $defang_undecipherable = 1;  # default is false: don't modify mail body
  $defang_spam = 1;  # default is false: don't modify mail body

Mark


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to