David,
> I wanted to stop any JPEG's in my incomings mails. So I put :
> $banned_filename_re = new_RE(
> qr'.\.(jpg|jpeg)$'ix, qr'^image/'i);
> Just fine when amavis stop it.
>
> I was happy so I decided to stop all mails with a MIME-type that is not
> known : qr'^application/octet-stream$'i, I tried and obtained that I want.
>
> Right, *but* sometime jpeg's attachements with another extension pass
> and some well known types like sxw's OOo don't pass.
> This behaviour seems to come from the non-use of file and the second
> behaviour arise only with a MUA, OutLook, that don't put the right MIME
> type on the mail.
>
> It leave me a bit confused about the recognition of MIME type by amavis.
> Is there a option I missed about the use of file ?
For each mail component, the check for banned parts tries all
of the following part's attributes (if available) in that order:
mime type: application/octet-stream
file(1) short type(s): .jpg
.image
declared file name(s): important-picture.foo
some flags: UNDECIPHERABLE
(or if using $banned_namepath_re instead of $banned_filename_re
the follow syntax of attribute/values is used:
P=p002,L=1/2,M=application/octet-stream,T=jpg,T=image,N=important-picture.foo
)
If any of the tried keys (part's attributes) matches an entry in the
$banned_filename_re list, the search stops and the result of the match
determines the outcome, which usually is an implied true, but can
also be a false, e.g.:
an entry in the $banned_filename_re list like:
qr'^image/'i
is the same as:
[qr'^image/'i => 1]
(both resulting in true), unlike the:
[qr'^image/'i => 0]
which returns false when it matches.
There are no options to turn on/off the collection of attributes
like the short type result from file(1), but the $banned_filename_re
list syntax is usually flexible enough that by properly ordering
the rules and perhaps using rules which return false, you can
achieve most of the desired behaviours. In rare cases where the
requirement is more complex, the $banned_namepath_re approach
is somewhat more powerful (and more tricky to do right).
Actually there is one more fact to note: an unpacked mail is
a tree of parts. When checking deeper (nested) parts, the
above described attributes check is repeated for each of the
part's parents, top to bottom. This is important so that a rule
for a parent (e.g. archive.zip) may be able to override rules
for contained parts (e.g. anything withing zip is fine regardless
of archive member names).
Turn on the log level 5 to see how banned checks are evaluated.
Mark
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
