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.
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 general, HTTP is a 2-point protocol (web proxies are specialized pseudo-points, since they perpetuate the illusion that there is only two points involved in the transaction), but SMTP is a fundamentally different protocol.
One possible solution to this problem would be to negotiate types beforehand, as (for example), an entry in a directory that a client would consult before contacting the mailhost, but this is effectively convention (many clients offer this already, and few people use it).
Re:Content-type negotiation and SMTP
Matts on 2003-03-05T13:54:15
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 happen (and I'm definitely not suggesting it will happen) though. There are serious and obvious problems with the above design.Re:Content-type negotiation and SMTP
ask on 2003-03-08T20:28:17
IM2000!
