Why don't we use HTTP for email? | Hacker News Reader

Why don't we use HTTP for email?

10 pointsrvkennedy12 comments

When accessed from a mail client, mail servers expect connections by IMAP, POP, and SMTP. The back-end inter-server comms use SMTP. But HTTP requests are standard for many non-web internet apps. Aside from historical reasons (the mail protocols predate HTTP and are well-established) why have mail providers not moved towards HTTP (or HTTPS) as a well-supported, flexible standard for client communication? If the mail protocols continue to evolve, what are the arguments for keeping them separate?

View on HN

If rms can use SMTP for web pages, we might as well do the opposite. ;-)

Email has different needs than do web pages, thus the protocols are different. Could one implement email over HTTP? Sure! But what, exactly, will be the benefits and costs? And then there is history. Unless the benefits are extremely compelling it will never be worthwhile to upset the entire email infrastructure.

HTTP is used for a lot more than just web pages - as I mentioned above, it's a de facto standard for a great many internet applications that are not web-based. The benefits - well, Gabor Cselle summarizes these quite well (http://blog.gaborcselle.com/2010/02/how-to-replace-imap.html) - so many problems have already been solved with HTTP due to the massive interest in the web over the past 20 years.

But I take issue with the idea that replacing IMAP with HTTP would in any way upset the email infrastructure. Changing the client protocol does precisely nothing to the infrastructure, unless you choose also to replace SMTP completely. I could write my own server for my own email account, with HTTP for the client, and as long as it used SMTP to send and receive in the network, no-one would see any difference.

No need to take issue with something I didn't say. You mention IMAP, POP and SMTP as targets for replacement. I agree that it's workable to add an additional client protocol without disruption. If it were good then people would support it. If it were good enough then the other protocols would fall into disuse and eventual deprecation. Replacing SMTP would be problematic, though.

The question specifies client communication. Replacing SMTP in the network is also a valid issue, but it is not the question that was asked here.

Depending on your point of view, you might say we are already moving in this direction. :-)

A large number of people consume e-mail using HTTP, so it has in many cases replaced IMAP and POP. We also send e-mail using HTTP, both through web-mail systems and ad-hoc forms. This replaces SMTP-for-sending.

All that's left really is the server-to-server SMTP, and if the distributed social networking protocols (OStatus etc) take off, then SMTP will have been partially replaced as well.

The main issue is that aside from OStatus, none of these are remotely close to being standardized. So automation is hard. This is good for preventing spam but bad for many legitimate things.

Well - as for people using HTTP to browse e-mail... People never used SMTP to send mail, they used software (sendmail/pine in the earliest days iirc). So this argument is invalid :)

There's an old saying "when all you have is a hammer, everything looks like a nail." A saying that often fits those enamored of HTTP tools....

Why do we have Spanish? Or English? Or any other language? Can't it all be said in one?

Similarly there are some things that get handled in one protocol that can't be as readily executed in others. Yes, you could do mail using HTTP transactions, but then you'd have to add all the layers that make up IMAP and SMTP actions. Wheel, meet your reinvention.

An old thread about designing a replacement for IMAP:

http://news.ycombinator.com/item?id=1101693

That's a really good thread, thank you!

Can you provide reasons why you think this is a good idea? How it would make your life easier? Or what is broken with the current protocols?

I think a stronger argument would be for moving from MIME to XML, I can envision some advantages there, but I don't think that will happen anytime due to inertia.

Replacing the convoluted multi-party email forward with a dynamic document would be nice.

We barely hear of Google's SPDY, I bet they are secretly working on something like this. They aren't the type to unnecessarly bundle it in with http in SPDY, but maybe they found a reason.

Reply on news.ycombinator.com