Re: [AMaViS-user] Just let permitted Attachements pass

This is a discussion on Re: [AMaViS-user] Just let permitted Attachements pass within the Amavis User forums, part of the Anti-Spam and Anti-Virus Related Forums category; Ekkehard, > what I might have to do is that I change the Banned File > checks so that I ...


Go Back   Usenet Forums > Anti-Spam and Anti-Virus Related Forums > Amavis User

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 03-11-2005
Mark Martinec
 
Posts: n/a
Default Re: [AMaViS-user] Just let permitted Attachements pass

Ekkehard,

> what I might have to do is that I change the Banned File
> checks so that I just let pass Mails with attachments
> that I know that can pass and can be checked successfully.
>
> It's just as a firewall policy deny all then permit selectively.


As far as $banned_filename_re or $banned_namepath_re
lists are concerned, the 'explicit permit with a default deny' logic
is supported as usual.

> Did anyone out there try this already? Is it easy to get around it?
> I'm just thinking about setting a different MIME Type.


If you don't have too many local users and you receive a good feedback,
it may be doable. I'm not sure about all the implications, could be
a pain for the senders and recipients.

> Second thing in this effort is what do I do if lets say an unpacker
> fails. I'd like to stop the delivery on that too.


See sub decompose_part(), turn an unsuccessful status from eval {...}
into adding an undecipherable attribute to the failed part:
$newpart_obj->attributes_add('U');
and then block mail on the presence of such attribute:

$banned_filename_re = new_RE(
qr'^UNDECIPHERABLE$', # is or contains any undecipherable components
...
);

I never tried it though.

It is likely you will encounter contents which look like some archive
or compressed format to file(1) utility, which later turns out not to be.
The decoders that routinely try some decoding but then report
it is not really their format, are the do_ascii and do_executable
(which attempts to unwrap self-extracting archives).

Mark


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/...fo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 04:50 AM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0