Robert, > Running amavisd-new version 2.6.2 > > RIM routinely sends mails to Blackberry users containing a file named > ETP.DAT. This file must not be banned, so I added an exception to > $banned_filename_re: > > $banned_filename_re = new_RE( > ### BLOCKED ANYWHERE > # qr'^UNDECIPHERABLE$', # is or contains any undecipherable components > [ qr'^etp\.dat$'i => 0 ], # allow RIM Blackberry messages > qr'^\.(exe-ms|dll)$', # banned file(1) types, rudimentary > qr'^\.(exe|cab|dll)$', # banned file(1) types > ... > > This works better now most of the time, but sometimes one of these mails > get banned nonetheless. Here is a logfile excerpt: > > [...] > > p003 1 Content-Type: multipart/mixed > p001 1/1 Content-Type: text/plain, size: 931 B, name: > p002 1/2 Content-Type: application/octet-stream, size: 528 B, name: ETP.DAT > > p.path BANNED:1 $recipient@$mydomain: "P=p003,L=1,M=multipart/mixed | > P=p001,L=1/1,M=text/plain,T=asc | P=p004,L=1/1/1,T=exe,N=UNKNOWN.001", > matching_key="(?-xism:^\\.(exe|cab|dll)$)" > > [...] > It looks like amavis did not ban the ETP.DAT itself (p002) but something > else instead.
The "P=p004,L=1/1/1,T=exe,N=UNKNOWN.001" was derived from "P=p001,L=1/1" as indicated in the L path, i.e. from the first text/plain MIME part of the message. Seems like the Convert::UUlib attempted the decoding of BEGINETP...ENDETP, which resulted in something considered executable by file(1). Log level 4 or 5 could demonstrate more clearly what happened. Btw, which version of the file(1) utility was that? Are you using a non-default setting of @decoders ? I believe its entries to call do_ascii were disabled in 2.6.2, but possibly you kept an older explicit configuration. > The first part (Content-Type: TEXT/plain) contains a base64-encoded file > without a name (UNKNOWN.001) which seems to be the problem: file(1) > considers this: > UNKNOWN.001: amd 29k coff noprebar executable > > The part with "executable" seems to trigger the problem. > > Has anyone an idea how I can convince amavis to let these pass? I'm > reluctant to allow the filename UNKNOWN.001 in general, this would > probably permit any file without a name. Perhaps a combination of sender > "*.blackberry.net" and file name "UNKNOWN.001". Try disabling the do_ascii in @decoders first, if you still have it. Next suggestion is perhaps to remove the 'exe' from the second of your rules: > qr'^\.(exe-ms|dll)$', # banned file(1) types, rudimentary > qr'^\.(exe|cab|dll)$', # banned file(1) types i.e. changed to: qr'^\.(cab|dll)$', # banned file(1) types This would avoid blocking the non-windows executables (like Unix, VMS, ...). The true Windows executables are classified as both 'exe-ms' *and* 'exe'. Similarly a dll is both an 'exe' and a 'dll', so these would remain to be blocked. The last suggestion is to check if more recent version of file(1) still considers your file an 'amd 29k coff noprebar executable', and if it does, send a problem report to the maintainer of this utility. Mark ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user Please visit http://www.ijs.si/software/amavisd/ regularly For administrativa requests please send email to rainer at openantivirus dot org
