Re: hotmail password request tool (intranet usage)

[ Followups redirected to somewhere this is on topic. ]

In comp.lang.lisp Charles Newman <charlesnewman1_at_comcast.net.spammers.will.be.shot.on.sight> wrote:
> "Leythos" <void_at_nowhere.lan> wrote in message
> news:Qkb9e.6157$0V2.5188_at_tornado.ohiordc.rr.com...

>> It's very common, and a good method, to delete Zip files that are
>> passworded or can't be opened and the contents scanned for malicious code
>> by the email av or firewall software. We always delete unscannable zip
>> file.

We do not delete ZIP attachments (or -ever- alter message bodies) but it is relatively trivial to detect the real file type of an attachment, even if it is maliciously renamed to conceal it.

Email attachments are encoded using Base-64, which is deterministic -- so the "magic numbers" at the beginning of a binary data file will always come out to a given pattern of Base-64 encoding. Thus, a simple regular-expression matcher (as is built in to the Postfix MTA and many others) will suffice to detect and reject messages with attachments of a given type, even renamed.

It was in response to anti-virus software that can scan into ZIP files that some email viruses started sending themselves as passworded files. They'd include the password in the message body and instruct the user to open the attachment using it. Nobody should be surprised that this worked -- indeed, telling the user that the attached document is so important that it had to be passworded is a good bit of social engineering.

I personally consider it bad practice for a mail server to alter the contents of a message, as by deleting an attachment. Doing so creates the (correct!) impression that "the computer people are fooling with my email" and damages users' trust. It also fails to inform the *sender* that the message was not transmitted successfully -- and the SMTP language has no way to express 'partial delivery'.

What's more, it's not terribly effective at reducing the fuss and bother associated with viruses. Email viruses do not attach themselves to 'real' messages -- they send messages of their own, which serve no purpose but to pass the virus. Stripping the attachment off such a message and delivering it tells the user, "I know this message was junk meant to harm you. I killed it. Here, have its corpse!" Except to the sort of user who *likes* it when the cat delivers dead birds and mice, this is silly behavior. Users have enough clutter in their mailboxes without the corpses of viruses added to the mix.

When a message comes in that the security rules say must not be delivered, the sensible thing for the mail server to do is to simply reject it. SMTP rejection means the recipient's mail server doesn't even accept the message for delivery -- it says "no, thank you" and leaves it up to the sender's mail server to report the failure. In the case of a virus, the sender usually just goes away and harasses someone else. In the case of real mail erroneously intercepted, the rejection can come with an informative error message ("Sorry, we don't allow ZIP files in email. Please use a file transfer protocol when you want to transfer files!") that the sender will then receive and can handle appropriately.

-- 
Karl A. Krueger <kkrueger_at_example.edu> { s/example/whoi/ }