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.

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.