Hi Sean. I am included to agree with you. The point is that because of
the fragile way Outlook handles headers, (by considering a message
MIME encoded, whether it should or sometimes shouldn't,) one has to
search the body of the message to see if Outlook *_COULD_* consider
the message MIME encoded-as a general solution to detect any potential
malicious content.
John
BTW, the reason this came up is that I was going to hack the sources
to metamail(1)-the MIME reference code-to remove those sections of a
MIME message that could contain potential malicious content, and add
it to http://www.johncon.com/john/QuarantineAttachments/ to speed it
up a bit-and remove the necessity of quarantine operations. I tested
it on BadTrans.B, and it went in one end and out the other-metamail(1)
claiming it was not a MIME encode message-but an EOF error. (Which I
guess has some possibility/potential.)
Professional Software Engineering writes:
At 22:31 2001-11-30 +0000, John Conover wrote:
Unfortunately, there is a problem with the way Microsoft Outlook
parses e-mail headers. For example, in BadTrans.B:
Correction: don't you mean, "unfortunatley, there's a problem with how MS
OutBreak (or at least the virus) _sends_ messages? Being more lenient with
interpreting something isn't inherently a problem -- failing to adhere to
the spec when writing it is quite another (and is something microsoft will
always be guilty of).
MIME-Version: 1.0
Content-Type: multipart/related;
type="multipart/alternative";
boundary="====_ABC1234567890DEF_===="
Why don't you use this to your advantage? If the malformed headers are
characteristic of only viral messages, you're good to go:
:0H
* ^type="mutipart/alternative";
flakey.mime.header
Otherwise, if you were interested in _fixing_ them (so that other tools and
rules could deal with the messages properly), you could detect and fix
messages with:
# save the value in another variable
savemetas=$SHELLMETAS
# disconnected variable name unsets it
SHELLMETAS
:0Hhf
* ^Content-Type:
* ^(type|boundary)=
|sed -e 's/^\(type\|boundary\)\(="\)/ \1\2/'
# restore original value and clear the save copy
SHELLMETAS=$savemetas
savemetas
(one could of course copy the SHELLMETAS near the top of your procmailrc,
then it'd be a matter of disabling them and reseting them around individual
rules which might contain metas) The SHELLMETAs stuff is entirely optional
here - it merely makes the invocation of sed less costly by removing a
shell which would otherwise be wrapped around it.
THEN, following rules and tools would interpret it properly.
BTW, NAI WebShield SMTP for NT parses the BadTrans.B headers,
correctly, and determines that the message is not a MIME message,
allowing it, incorrectly, to pass.
My heart bleeds for the NT users. They're better off setting up a *nix box
and routing email through there seeing as NT mail solutions are some
combination of overpriced, non-compliant, and lacking in features.
But that's just my opinion.
--
John Conover Tel. 408.370.2688 conover(_at_)rahul(_dot_)net
631 Lamont Ct. Fax. 408.379.9602 http://www.johncon.com/
Campbell, CA 95008 Cel. 408.772.7733
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail