All the Perl that's Practical to Extract and Report
use Perl Log In
Matts (1087)
(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.
Hotmail Content-Type
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.
--Larry Wall in stab.c from the perl source code
Content-type negotiation and SMTP (Score:1)
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)
Re:Content-type negotiation and SMTP (Score:2)
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
Re:Content-type negotiation and SMTP (Score:2)
-- ask bjoern hansen [askbjoernhansen.com], !try; do();