Why is email broken?

It isn't broken and it doesn't need replacing.

There are two main sources of the "email is broken" meme. The first came from the snail mail industry, partly in cahoots with the big telco's. The snail mail industry of course quite rightly identified email as a competitor that completely undermined their business, and the telco's saw an opportunity to charge for more than just the bare wires. Verified and most importantly paid email was touted as the solution for spam, but it was really all about money.

The second source are the post dot-com bust social media generation of start-ups, who recognize that killing an open standard and replacing it with a proprietary communication protocol can be highly profitable. They've already managed to reduce several protocols to small niches (IRC, Usenet), but SMTP is the big prize. Just imagine being the company the whole world uses for their next generation email.

Of course for any of that to happen people have to believe email is broken. So next time you read that "email is broken", I suggest you follow the money. There's always someone behind it looking to profit from it.

Email isn't broken, if by broken you mean unusable, like a piano that's had all its strings cut.

But could it be improved? Certainly.

Same thing with just about any modern technology. I have a decent commuter car that gets me from point A to point B. Is it in working order? Yes. Could it be improved? Sure, and it has, in later model years.

Here's a list to get you started:

- No Encryption (security)

- Phishing (security)

- Spam (annoyance)

- Tracking when it's been opened (privacy)

- No confirmation that it's been received by the recipient server. (Did it get lost in the mail? I'm not talking about read receipts.)

- Not easy for the average person to implement one s own server reliably. (privacy - trading convenience for allowing companies to read your e-mails)

Technology is supposed to make our lives easier right? E-mail does a few things better than snail mail (cost and scalability), but it completely fails when it comes to other things.

Email was not designed with privacy from net operators in mind, in a time where actual NSA programs would had been considered a bad horror fiction movie. It relies in sending in plain text your private mail, with little to none encryption for headers (for the content was added some encryption, hard to use, and almost not used at all), sending to whatever server the dns claim that could accept mail for you, and is pretty easy to send mail that appears to come from you.

Reality has changed. Is needed something that is easily usable by everyone, that certifies that the message really comes from you, that prevents interceptions in the path and that is strongly encrypted. Maybe it don't need to be that way for everyday, public mail, but for the one that is meant to be private and authenticated.

The problem for me is that the data contained in an email is unstructured. You have to read through the body of an email to get the important info, like a tracking number or address to a friend's party. Granted Gmail helps with the quick links, but that's only one provider. And search is terrible. There is still no way that I've found to say, show all image attachments from a certain person or show all tracking numbers I've received in the last 30 days without a bunch of clunky searches. And there should be a way to add tags to an email from the sender's side that appear on the recipient's side, like "news, article, startup" when someone sends me a techcrunch link. It would be great to search these by tag. Plus, emails should come with an expiration date option. If my bank sends a daily balance alert, they should be able to send an expiration header of 24 hours so that they don't stack up. In my client I could choose to honor the expiration header and delete or archive, or ignore it altogether. The same would go for event invitations whose dates pass, etc.

Email doesn't need replacing. For insecure iterated text communication, it's just fine. Oh we might quibble about the restrictions it places on us as programmers, but it works from an end user perspective pretty much 'okay.'

However, a lot of communication is not insecure iterated text communication. Email's not so much broken as it is incomplete and largely inextensible.

From that perspective, even something as simple as having a chat with someone through email seems very odd. I mean why are our replies to each other different messages? Why aren't they just inserted seamlessly into one thread in the same way that IRC works?

Setting up a meeting? Oh I know that there are email setups that can do that in corp-space, and theoretically a civ-space client could use them too. But that's not the way things tend to go. In many ways the use of social media to setup meetings is the direct result of emails lack of extensibility in this regard.

Keeping group photo albums? Should be easily doable without the need for a central server like facebook.

Secure chat? Oh, where will we get a trusted certificate authority from? Well, if you don't want to meet the person you've got that problem whatever you'd doing. If you can see the other person, however, you just generate a short random string on your computer, encode it with their public key and see whether they can decode it at their end. No point exchanging the whole key, just check the thing works.

Varying access levels by trust?

Keeping a persistent contacts list across multiple devices?

Presence-aware communication? (Actually knowing someone's at the other end and available right then.)

So people, to varying extents, use other tools for these things. The major cheerleader for email's borked at the moment seems to be the security aspect, with implications for trusted senders.

I mean heck, that's something that would kill most spam right away there - if you had senders that were verifiable as the same person every time, you could implement something like: 'X wants to send to add you to their contact book, do you know them?' Public-facing email addresses would still get spam but we could just blacklist everyone you said you didn't know for your private address and not bother decoding the messages at all - straight to the bin with them.

Since none of the existing replies go into technical detail, I'll add a few points:

E-mail is sent via the SMTP protocol, a protocol that made perfect sense in 1982. Since then, changes have been hacked together and the protocol has been bastardized beyond recognition to achieve various goals.

For example, if you want to transmit messages via an encrypted channel, you'll use the STARTTLS mode (tacked onto the protocol in the mid 2000s). But even if you are using STARTTLS, the server is likely not actually validating the certificate, as very few really do (even Google Apps / Gmail doesn't seem to check, as far as I can tell). So a MITM attacker could just set up their system to answer with a self-signed certificate, and there's a very high chance the client sending the message is going to go ahead anyway, even if it can't verify that the server it's talking to is the real SMTP server for example.com

Additionally, we've had a serious problem verifying that the sender of an e-mail is legitimate. In 2006 SPF (Sender Policy Framework) was proposed, which allows a domain to declare what IP addresses can send mail from it. However using SPF breaks things (like Gmail's ability to allow you to send from another non-Gmail account, for example) and almost nobody uses hard-fail mode to reject mail based on SPF. In 2011 DKIM (DomainKeys Identified Mail) was officially standardized, and this security add-on allows the message to contain an RSA-signed header vouching that the "real" example.com generated the message. DKIM is a really big step for e-mail authentication, and is really starting to see wide adoption. However, many mail providers don't check for the DKIM header on receipt, thus leaving their users susceptible.

Other grossness includes the actual message transmission schemes - using multipart messages with base64-encoded attachments, all encoded (typically) in the quoted-printable encoding. Again a great method for the late 80s, but completely, totally, 100% inappropriate for modern communications. Base64 encoding an attachment also causes the attachment to grow by roughly 33%. Client software has to be incredibly complex to deal with all of the bastardized, non-spec implementations of message boundaries, character encodings, etc. The standards are there, but are complicated and ripe for accidental or intentional abuse. And, finally, messages have to be pretty grossly constructed to support unicode (this is an example UTF-8 subject line: =?utf-8?B?Hello!?= ).

The entire protocol needs a ground-up re-write. In my opinion, a lot (perhaps all) could even be borrowed from HTTPS. Imagine just sending e-mail by using a REST API, authenticated by utilizing client-side certificates. But that's probably just a pipe dream :)

eMail is a lot like SMS within cell/mobile phone networks, it was never made extensible and therefore inherently lacks some functionality that would be fairly simple to implement using todays ideas and tools, for example simple encryption and reliable end to end delivery for eMail would be great!

In the cell/mobile networks we are seeing legacy services like SMS been slowly replaced with better alternatives like Facetime, Whatsapp & Skype etc... However this change is been driven by users partly because of the increased functionality that these services have to offer, but most of all because of the cheaper cost to the end user.

Unfortunately because eMail is natively free the majority of users will just make do with what they already are successfully using, even if it's a bit clunky and lacking features.

Ultimately 99% of people on the web probably have an eMail account, which provides a massive barrier to any new alternatives out there, no matter what feature set that they have.

It's broken because people want to be secure in sending messages however it's design is contrary to that. The metadata prevents it from being truly secure for one.

Encrypting emails is also another very complicated thing for users.

It needs a make over of sorts so we can get something that all users can reasonably use securely.