Tom,
 
  I have been looking for a way to fix this for a while, but the code is a bit complicated for my skill and you are the first one that I have found to even make a comment about it.  It is basically any filename with a space in the attachment name that slips through. Example:  Here to.pif  will never get stripped.  The other ones that seem to get passed are double extensions, unless you strip it on the first extension such as test.ext.scr would get passed, but I am more concerned about the spaces. If you find a solution I would like to be notified via email.
 
Thankyou,
Derrik
 
 
 

QUOTED_MESSAGE:
> I'd like to report a not so unimportant problem with
> anomy. It's not  really a bug in anomy, actually it's just
> another case of M$  braindeadness ;-)
>
> Lately we've seem some leakage of Worm mails through to
> our internal  mail system; more specifically, it seems the
> BugBear worm is  accomplishing this.
>
> Our anomy policy is setup to everything ending in .scr
> and .pif etc;  scanning is limited to specific type docs
> (word, etc). That worked fine,  just until recently, as we
> had reports of some worm mails leaking  through. Strangely,
> these mails also contained attachements ending in  .scr,
> which normally should have been blocked.
>
> I've been able to grab hold of one of these messages;
> it seems the worm  is sending the mail with incorrect mime
> headers; it does not put quotes  around the
> filename:
>
> Content-Type: audio/x-midi;
>         name=Fichiers
> AUDIO mr. malpoli CD 1.scr Content-Transfer-Encoding: base64
> Content-ID: <T1HIVTvXb5n1k>
>
> This is the corresponding entry in my anomy logs; anomy
> only 'sees' the  part up to the space.
>
> SanitizeFile (filename="Fichiers",
> mimetype="audio/x-midi"):
>
> Actually, anomy is following the RFC's, which specific
> that values are  either a 'token' or a 'quoted string'.
> 'tokens' cannot contain spaces,  so you're doing the right
> thing here. Unfortunately, I've tested with an MS outlook
> client and it does seem  that it recognizes the incorrect
> header; this is not the case with mozilla.
>
> My question: is there a way that anomy could be adapted
> to handle this  case? This does not seem to be a simple case
> of adapting the regexp ;-)
>
> Tom.