dealing with email from "Mydoom" worm

[Fred Yankowski]

Based on comments from this list I'm now using the attached procmail
recipe to catch likely MyDoom messages.

Per my usual approach, I deliver the matching messages to a special
maildir rather than to /dev/null.  That way I can quickly scan for
false-positives; it's about 3 keystrokes to delete the whole lot from
mutt.  I've tested the rule against my nonspam training archive (about
13,000 messages) and it didn't match anything there.  (OTOH, I just
remembered that I recently pruned the largest messages from that
archive to save space, and those messages almost certainly had
attachments.  Hmmm....)

-- 
Fred Yankowski      fred at ontosys.com           tel: +1.630.879.1312
OntoSys, Inc	    PGP keyID: 7B449345        fax: +1.630.879.1370
www.ontosys.com     38W242 Deerpath Rd, Batavia, IL 60510-9461, USA
-------------- next part --------------
BADNAME="\.(bat|cmd|exe|pif|scr|zip)$"

:0
* ^Content-Type: multipart/
* B ?? ^Content-Type:.*application/octet-stream
* B ?? ^[	 ]+name=\"\/[^\"]*
* $ MATCH ?? $BADNAME
{
    # Message has attachment of type octet-stream and with a bad name
    LOG="[bad attachment name: $MATCH]
"
    :0
    IN/~bogo/bad-attach/
}


# NOTES:  Content-Type headers inside the document body typically have
# their 'name' attribute on the following line.  Since this is not in the
# header of the message, procmail does not fold these lines together,
# and so there is no way to be sure that we are matching the name
# attribute that is associated with a content-type of
# application/octet-stream.  We get a false-positive match on a
# message with multiple attachments, one of type
# application/octet-stream and another with one of the bad names.  Oh
# well.