Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Matts (1087)

Matts
  (email not shown publicly)

I work for MessageLabs [messagelabs.com] in Toronto, ON, Canada. I write spam filters, MTA software, high performance network software, string matching algorithms, and other cool stuff mostly in Perl and C.

Journal of Matts (1087)

Wednesday March 05, 2003
04:18 AM

Hotmail Content-Type

[ #10900 ]

In Hotmail you can create rich text emails by selecting a special editor. This works only on Windows, and uses an ActiveX control to do the editing. A few weeks ago, if you created a rich text email it would send out a multipart/alternate email with two parts - a text/plain part first, and a text/html part second. This is standard practice for email clients, and is recommended in the relevant RFCs.

A couple of weeks ago Hotmail changed their system to only send out text/html - no text/plain part and no multipart/alternate.

Now I can see why they did this - it saves them an awful lot of bandwidth to do it this way. And my problem with them doing this isn't that it goes against the RFC suggestions (it's not mandatory after all).

My problem with this is it lessens the capabilities of spam filters.

Prior to this change a good heuristic was checking if the content-type was just text/html. If that was the case (and in a lot of spam it is the case) then there was a pretty good chance it was spam.

But Hotmail represents an awfully large portion of the internet. With some 60+ million users. That means anyone filtering on the above heuristic and still wanting to get hotmail email either has to whitelist hotmail, or has to cut back that heuristic. Neither are great options.

It makes me wish with email you could do content negotiation like you can with HTTP:

Sender:What formats can you accept and what encodings?
Recipient:I can accept text/plain, text/html or text/rtf, but my preferred format is multipart/alternate
Recipient:I can also accept deflate encoding
Sender:Cool! Here's the email in multipart/alternate, body is deflated.

Experience on the web with AxKit tells me that deflating text is going to be better than removing the text/plain part anyway.

Ho hum.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • It makes me wish with email you could do content negotiation like you can with HTTP

    I have an on-going argument/discussion with a coworker about whether SMTP is broken or not; in general, I'm on the not side, though things like this sometimes make me want to rethink my position.

    However, given the basic assumptions of SMTP (store and forward, recieving host might not always be connected to a network, etc), how could the interaction you describe possibly take place? It can be done with HTTP because, in ge

    --
    (darren)
    • However, given the basic assumptions of SMTP (store and forward, recieving host might not always be connected to a network, etc), how could the interaction you describe possibly take place?

      Well it couldn't work, as you say. But if it could, it *would* be a fundamentally different protocol anyway. And a fundamentally different SMTP-NG might take the view of HTTP - that if the remote end is down then its just down (so you store on the local machine, rather than at the ISP).

      I'm not suggesting it should happ