
Email is not broken: It’s a framework, not an application - orthecreedence
http://blog.killtheradio.net/technology/email-is-not-broken-its-a-framework-not-an-application/
======
tferris
Couldn't upvote this more.

I am fed up with posts telling me email is broken and a new disruptive tech
will be the cure. Email is an open protocol, decentralized, providing optional
security.

Shortcomings—or rather call them additional requirements—can be solved with
tools keeping email focussed on async text-based communication. Want to send
large files? Dropbox. Want more automation? Improve the client side and/or
write scripts. Want less spam? Don't distribute your address or sign-up
everywhere.

If you don't like your inbox being a todo-list you should change
something—maybe your job, profession or your work environment but it's
definitely not email. I have got rarely todos in my inbox.

For me, email is—if you mind a set of rules—an efficient way of communication
which is documented. You can easily and asynchronously discuss and agree on
topics in a transparent manner with one or more participants, again: with an
open and decentralized technology, no middleman anywhere. Sometimes obviously
it's better to meet folks face to face.

Now tell me, which tool can do this? What do you want to improve?

This whole email is broken thing is just done for the sake of getting
attention, making a lame conference presentation "disruptive" or getting some
crappy todo app funded.

~~~
oskarth
_Email was not designed to be used the way we use it now. ...my inbox is a
todo list, and email is the way things get onto it. But it is a disastrously
bad todo list. ...it seems unlikely that people in 100 years will still be
living in the same email hell we do now. And if email is going to get replaced
eventually, why not now? ...some of the most powerful people are all at the
mercy of email too._ [1]

Your posts reminds me of someone arguing to keep the oral tradition going
instead of switching to writing.

I am not saying anyone has suggested anything close to the equivalent of
writing, but there is definitely a fundamental problem with email that can't
just be solved by a couple of perl scripts and rules. I would also assume
one's career choice is a premise for making better tools and protocols -
anything else seems kind of backwards. If the president was forced to work in
a public market space, would you tell him to change career if he remarked on
how he couldn't get anything done?

There is a difference in saying email should be killed forever and that it
should be replaced by something else for certain usages, just as twitter and
Facebook replaced portions of email. Incidentally though, such a replace could
likely render email useless for many people.

1: <http://paulgraham.com/ambitious.html>

~~~
gbog
When I read this piece from Paul Graham, I wondered if he had an assistant (I
mean a flesh and bones personal assistant). Is that that assistant are too
expensive nowadays in the West? If I were a powerful influencer with enough
money, I'd consider hiring an assistant to help me filter these mails. He or
she will probably be easier to train than a Bayesian filter...

Automatisation is not the last word for every human activities. Many people
are struggling to find a job. Many could do this kind of task efficiently, and
even enjoy it.

Maybe I have a different point of view because I live in China, where labor is
cheaper, but for instance here if you have a kid and don't wish to change 100%
of his diapers, you can just pay someone to do so, it is cheap enough and many
people are happy to do this for you (it is often better paid and always safer
than working in iPad factories).

"Externalizing" some tasks to other people also means you have a life with
more and deeper human contacts. Surely, these human being must be handled much
more carefully than a "web service", you have to smile to them and consider
their problems. Sometime you have to do compromise and accept a less than
perfect outcome. Sometime you have to manage these people that work for you.
But this is life.

~~~
flogic
Yea he should probably hire an assistant. Good secretaries can light saber
through bullshit. That said, I can't afford a secretary and my inbox is
completely out of control. It's won. I've lost. There is virtually nothing I
can do about it at the moment.

~~~
Zak
In what way is it out of control? I may be working on things that can help
with this problem.

Is it just that you're communicating with too many people? Do most of the
emails require action, or are some of them things you don't even want to read?

~~~
flogic
All of the above.

------
myspy
Without all the sexual allusions this could be a decent statement -.-

(sorry, I have nothing against that when joking with friends or reading some
not so serious post, but it does not fit to a commentary about email)

~~~
alexchamberlain
I thought I was the only one who got frustrated with sexual innuendo peppered
blog posts or those with swear words ever other sentence.

~~~
kelnos
Diff'rent strokes for diff'rent folks. It amused me and made the post more
entertaining for me to read, thus holding my attention better.

Yes, I probably do have the sense of humor of a 12-year-old, but that's
immaterial.

~~~
alexchamberlain
I don't agree with you. We should be establishing a polite ettiquette

~~~
icebraining
And why would anyone follow it? You need some kind of punishing system for it
to be effective, and I'm opposed to that.

~~~
alexchamberlain
I'm opposed to that too, but I immediately ignore arguements made by people
who can't make them without swearing.

~~~
ktizo
What about those who choose to swear?

Also, your stance might be unfortunate if someone ever shouts at you, "Fuck
me, there's a tiger, run!"

~~~
alexchamberlain
I'm not saying swearing doesn't have its place. However, it is not in a
professional arguement.

~~~
ktizo
Not usually a spelling nazi, but if you are telling people what words they are
allowed to use professionally, could you also spellcheck the words you choose
to employ. There are less of them, so it should be easier.

~~~
alexchamberlain
I assume you are referring to my spelling of _arguement_ ; the additional e is
allowed in British English.

~~~
ktizo
Fair point, you are right. I think it would be picked up as incorrect by most
English teachers in Britain, all the ones I had anyway, however it is correct,
if a touch archaic.

But I was being an arse for picking at that in the first place anyway, I just
thought that your views on avoiding swearing were a bit over the top and not
entirely realistic.

Many professional environments cope fine with quite a blue tinge to their
speech, possibly because having to watch your tongue all the time can be a
negative in places that require rapid communication with the full range of
emphasis.

~~~
alexchamberlain
I was probably being an arse by not admitting a misspelling. (Chrome says arse
is spelt wrong.)

However, I still don't think it is appropriate to swear in a written
communication.

------
jmilloy
I thought this was obvious, but I guess not. When people say email is broken,
they mean that their email _client_ is broken. When people talk about fixing
email, they mean producing a better email client. That the OP doesn't get this
obscures his message to the point that I don't even think I get what he's
saying. In the end, he doesn't disagree with people who say email is broken,
because he tells them just to fix the client.

Can anyone offer some links to recent/current projects that want to "fix"
email by changing the protocol?

~~~
fluorid
These are PG's words: "This new protocol should be a todo list protocol, not a
messaging protocol,"

<http://paulgraham.com/ambitious.html>

~~~
jmilloy
Replacing email isn't fixing email, it's replacing email. When I discovered I
couldn't practice running a mile in my house, I went to the local track. I
didn't fix my house, I replaced it _for this particular task_ with something
else. Isn't this the same?

I think PG is in the minority when he considers a conversation over email a
"degenerate case" of a TODO list item. A public-writeable personal todo list
application is separate from my email client, whether it uses the email
protocol to send todo items, or a new protocol to send todo items, or http to
put todo items on a centralized database, etc.

------
SagelyGuru
The style of this post is a bit 'wild' but the message is sound.

I was reading those posts earlier, thinking the same: there is no point in
burdening email with constructing 'todo' lists for named senders because my
Opera mail client has been doing this successfully and more flexibly with
filters for years.

Also, the thought of receiving potentially important emails which can only be
read by, say, 'MS word-receiver 2012, v.3.2' fills me with forboding.

~~~
kingsidharth
> The style of this post is a bit 'wild' but ...

So? Is that bad? Everyone has their own way of expressing. Some herein declare
that electronic mail is not flawed. Some say that email is not broken. Some
just say that email doesn't need dick-sucking.

~~~
SagelyGuru
Yes, everyone has their own style and some are better than others. It does not
bother me but I think a metaphor like this is misplaced and distracting.

~~~
kingsidharth
> some are better than others

No they are not. Some are more * preferred * by you than others. Personally I
find such metaphor to be engaging & expressive. I love @holman 's writing for
same reason. But that doesn't mean one is better over the other.

Writing style is form of art & expression. The quality of an art piece is
determined by how well it is expressed and formal technicalities. So as long
as his expression is in place, and grammar is sound - it's good art.

~~~
drucken
You're writing an awful lot of words and almost seem offended by the mildest
possible expression of someone's opinion about the stark contrast of a
technical topic and more than colloquial writing. A whole thread over
"wild"...?

------
joedev
"Email is a distributed, asynchronous messaging protocol." What a complete
disconnect from the users of email.

To 99.99% of people who use email, Paul is correct: "Email is not a messaging
protocol. It's a todo list. Or rather, my inbox is a todo list, and email is
the way things get onto it." When people say "email", they almost always mean
their email client.

Failure to account for the common usage of the word and demand that people use
the word email only to mean the protocol is short sighted, results only in the
angst found in this article, and solves nothing. Life is too short to be so
angst-filled over the use of one word.

~~~
nkassis
"To 99.99% of people who use email, Paul is correct: "Email is not a messaging
protocol. It's a todo list. Or rather, my inbox is a todo list, and email is
the way things get onto it."

I don't agree with this, in fact I feel this projecting the email power user's
use of email onto everyone. At the end of the day, I think most people just
want to email each other a message or a small file or pics of their kids or
the latest dumb chain email. I do use my email as a todo list personally I
write those elswhere, I do send myself links through email but I've configure
Gmail to recognize that and put them in my bookmark label.

I also agree with the post, email does what it's meant to do well and you can
build clients to do all the features you are asking for.

~~~
joedev
"you can build clients to do all the features you are asking for". I agree and
that is exactly what people mean when they say email can be smarter - they
mean email _clients_ can be smarter.

------
mladenkovacevic
I noticed that there is a wider trend to write articles with headlines such as
"<This common thing in our lives> is broken, HERE is how to fix it!". Try and
think about other ones (TV, search, music...)

This type of writing sure gets people excited and attracts many readers but
it's a quite destructive way to think of our world. Just because something has
certain annoying problems or has maybe become boring and mundane does not mean
that the only way to make it better is to completely reconstruct it. Most
"It's broken" essays usually come with a dangerous degree of hubris and
presuppose that in order to make things better, the offending industry needs
full destruction before it can be rebuilt and renewed in the image of writer's
glorious new vision (often times this vision is not even presented - it seems
that something being "broken" implies that there is a better and completely
different way of doing it). Lessons learned doing things the old way become
meaningless or at least decline in value because, well it's broken.. we didn't
really learn that much right?

I agree that sometimes a complete re-framing is needed to get on the (more)
correct path towards making something better or at least just to allow
yourself to "think outside of the box". But going on a deconstruction campaign
of everything that's served us reasonably well thus far is another box which
you can easily trap yourself into.

------
alexchamberlain
The poster is correct that email is not a TODO list.

However, email is broken. Email is inherently insecure, unauthenticated and
wide open to abuse. There is no way of knowing that an email from me is really
from me and wouldn't it be better if SPAM could never get onto the network in
the first place?

~~~
SagelyGuru
Email can be secured and authenticated with GPG and perhaps more people should
consider doing this.

The problem with SPAM is that what some may consider to be a 'fascinating
circular' will be perceived by others as SPAM.

SPAM is often in the eye of the beholder.

~~~
Animus7
> Email can be secured and authenticated with GPG and perhaps more people
> should consider doing this.

Doesn't work unless you teach people about security, which is difficult. We
have padlocks next to URLs but it's amazing how many people are still willing
to send CC info over HTTP.

> SPAM is often in the eye of the beholder.

There's a lot of grey area, but when a particular string has a 99%
unread/deleted rate, you can make statistical inferences. An enormous
percentage of email falls into this category, and it's why "spam filters"
exist and generally do a good job.

~~~
kelnos
>> Email can be secured and authenticated with GPG and perhaps more people
should consider doing this.

> Doesn't work unless you teach people about security, which is difficult.

Simple, transparent security is hard. But this is again a UI problem, not a
failing of email.

Think about this for a second: let's say Google decided that it was going to
transparently PGP-sign all GMail users' emails. Now GMail knows that any
message with a from address that ends in @gmail.com but without a valid PGP
signature is fraudulent.

Now let's say Yahoo wants to adopt this too. So we add some syntax to SPF that
advertises, "any mail coming from this domain must be PGP signed." And another
field that points to a public key server. So then all other SMTP servers (or
even end-user mail clients, if they want), can auto-reject mail based on this
criterion.

Sure, this leaves out some details, like people sending mail from an
@gmail.com address using their own SMTP server via a thick mail client that
doesn't support PGP (or requires complicated setup to do it properly, like
most do). But it's a (hopefully) interesting idea that might work with some
modifications.

This has nothing to do with email per se, nothing about its successes or
failings. It's just building an easier-to-use distributed authentication
system that mail recipients can use.

~~~
SagelyGuru
Gmail etc. could have provided encryption and authentication if they wanted
to. Unfortunately they don't want to because their business model(s) rely on
reading our emails.

~~~
kelnos
Not at all relevant to my point. I'm talking about _signing_ messages, not
_encrypting_ them. Authenticating messages is completely orthogonal to
encryption and whether or not Google can read your mail.

~~~
SagelyGuru
True, they could at least allow signing, good point.

------
mattmanser
This post seems a little off. I agree that the fundamental concept's not
broken, but why link to the error message problem? He talks about technical
shortcomings of email but then just launches into saying that it's not todos?

So what about the technical problems? The crappy security, the poor error
messages, that the senders email gets dumped straight to spam without any
notification? What about crappy email threading that requires people to send
the entire post back in the reply? That if a normal person wants to send
emails themselves it's a colossal undertaking that's better farmed out?

Say it's not a todo app, sure. But don't pretend that there's not any problems
with it.

~~~
chaosprophet
>So what about the technical problems? The crappy security, the poor error
messages, that the senders email gets dumped straight to spam without any
notification? What about crappy email threading that requires people to send
the entire post back in the reply? That if a normal person wants to send
emails themselves it's a colossal undertaking that's better farmed out?

All these are issues with email _clients_ and not email itself.

You want security? Encrypt your emails before sending them.

Poor error messages? The computer understands the error code its getting. It's
your client that's not showing you a layman understandable error message.

Sender's email dumped straight to spam without notification? Duh, hello, it
was sent to Spam because your client classified it as spam (and more often
than not, that classification was right). Do you want to get a notification
for every email that lands up in your spam folder?

Email, threading works pretty fine in gmail, so I suppose that again is a
client problem.

And normal people send and recieve emails daily. Very rarely does a 'normal
person' send bulk emails, and if you wish to frequently send bulk emails and
not get caught up in spam filters, then you will have to work a bit towards
it. However, again this is not a problem with email. It's a problem with the
spam filters of service providers.

What I am trying to say here is that the author's point is simply that email
is very good at what it does. The issues with email are all in the way the
email is handled, and not in email as a technology itself.

~~~
copper
Email threading has worked for longer than I care to remember in mutt, for
whatever it's worth :)

------
davemel37
FIXING EMAIL is the secret sauce to solving a problem on the internet. Email
is the most basic communication protocol. IF I have a communication problem
and dont know how to solve it, I use email as a band-aid to get it done.

As the most basic form of communication, email is the place to look to solve
peoples problems. If we are using email to do or accomplish something, that is
an opportunity for a startup to build a new app that simplifies that specific
form of communication, and solve the pain of using email which was clearly
never meant for or is just a bandaid for that need.

Just look at your inbox and what you use it for and ask yourself, "Does this
belong here? Could this be done better? If the Answer is Yes, Great, Go build
a new startup!"

Before we had social bookmarking, we mass emailed our friends.

The way of the world and evolution is things diverge. They break off into
smaller, hyper-focused products and services. This is how new categories are
created and new brands succeed. This is a LAW OF NATURE, a LAW OF EVOLUTION
and a LAW OF BRANDING.

Want to build something great and amazing, something frighteningly ambitious,
look at your inbox and FIX EMAIL!!!

------
ed209
_> We fix it by building smart clients._

I think improving email lies before the client. Email is just a message
container and apps generally throw a load of different content into that
container, events, to-do's, photos etc.

Some of this stuff should never arrive in my inbox. A to-do email should
automatically go to my to-do list, an event should automatically go to my
calendar, photos should automatically go to iPhoto (or whatever).

Separately to that I can choose how I'm notified about that content.

For example, for all the marketing emails, I'd much prefer to have a Flipboard
type app on my mac that receives all of those messages so that they never
arrive in my inbox.

So no, email is not broken, but we haven't kept up with ways to manage the
growing number of correspondence email is handling. I think the solution lies
on the server where mail is sorted into types i.e. if you have that Flipboard
for Marketing app, you get those marketing messages otherwise you don't.

~~~
evaneykelen
<http://pigeonal.com/> is my attempt at doing this, we've built this app for
email that you can deal with in an "out of band" fashion e.g. while waiting in
queue. Disclaimer: I'm one of the creators of this app.

~~~
ed209
that's a pretty nice start. I guess it's similar to label+rules in Gmail? This
creates a series of "inboxes" for the 200 services you recognise - and for
client side that's pretty cool.

I was thinking more that I'd never actually get these messages via email, that
on the mail server, these messages would be interpreted and assigned to
whatever app/protocol is relevant. A bit like Tripit do with bookings email.

Look forward to see more from your app!

------
qznc
If you write pedantic rants, then get your terminology right. Email is a
heavily overloaded term.

The protocol is SMTP,POP3, and IMAP. The data format is something defined
through various RFCs and proprietary convenience. The use cases differ from
corporate Outlook via Exchange server to people typing text into webforms.

------
Navarr
> You send a message and it either goes where it’s supposed to, or you get an
> error message back. That’s it, that’s email. It’s simple. It works.

Except when you DON'T. Except when the mail server is broken, except when the
error message you get is ENTIRELY CRYPTIC.

Email works. That's it. It doesn't work WELL, It just works. That's why it
needs to be fixed.

> But sometimes I just want to send a fucking message, not “make a TODO.”
> Boom, I just “broke” the new email.

Though I think you're fairly right about this one - you're also wrong. You're
making whoever you're messaging a TODO. "Read This" Email has become a TODO
list, you can't fix that - not without a new mail protocol that takes that
into account and separates the todos from the messages. Certainly a client
could do this but a client can never ever be smart enough to get it right all
the time.

~~~
icebraining
_Though I think you're fairly right about this one - you're also wrong. You're
making whoever you're messaging a TODO. "Read This" Email has become a TODO
list, you can't fix that - not without a new mail protocol that takes that
into account and separates the todos from the messages. Certainly a client
could do this but a client can never ever be smart enough to get it right all
the time._

Separating TODOs from messages reliably can be done using MIME. You do not
need a new protocol for that, just define a format and give it a custom MIME
type.

~~~
ori_b
Or a header. Mail supports custom headers.

    
    
        X-Todo-Item: true
    

Boom. You now have a way of knowing that this email is a todo item.

------
MrJagil
The bottom line for me is: I hate email. It might be a great framework and
all, but I dread opening up gmail. I know it's going to be full of shit I
don't care about, I know there's going to be an unsurmountable, unsorted,
confusing, library of old emails. Further, if i'm expecting an email, it could
be anywhere! Bulk? Spam? Inbox?

But why then do i love getting an sms? Where's the difference? The speed? The
quality? The simplicity? Somewhere, email has gone wrong.

A simple answer could be that've just been giving out my email to too many
services, but honestly, that's what every email user does, and this should be
assumed by the developers. It could be that it's just the clients that are
broken, but then fix the clients!

~~~
Proleps
I hate getting email as well, but I also hate getting text messages.

Most people I know think modern communication is holy and you should check
you're email and text messages multiple times a day and always answer as soon
as possible.

I check my email personal email once a day (often don't read any email in the
weekend) and this sometimes pisses people off. It sometimes feels like I
should constantly be on my guard because people have send me something
important (which it almost never is).

I would love it if we could go back to the time when you could only answer the
phone when you are at home. Or the time when it was acceptable to wait two
days to reply to email.

But i guess this is a bit of topic because the original message was talking
about the technical part of email :P

------
zokier
> You send a message and it either goes where it’s supposed to, or you get an
> error message back.

I wonder how large percentage of messages are dropped silently by services
like GMail as a spam prevention measure. I bet it's non-zero.

> It’s simple.

How many email related RFCs are out there? And how many additional non-
standardized common practices there are? How many pitfalls imposed by common
legacy software? Email is far from being 'simple' imho.

Yes, a lot of stuff can be done at the client. But email protocol _stack_ is
still very ugly as a whole, especially if you need to reliably inter-operate
with the rest of the net.

~~~
gst
> I wonder how large percentage of messages are dropped silently by services
> like GMail as a spam prevention measure. I bet it's non-zero.

Nobody forces you to use GMail. There are other mailservers with a much more
sane behavior. For example, the mail server I use either accepts a mail, or
doesn't accept it (when it looks like spam). It might be possible that a
certain percentage of mails is misclassified, but in that cases the sender
receives a confirmation.

~~~
zokier
I can't choose what service my recipients use.

edit: I might add that spam backscatter is a significant issue (which stems
from fundamental problems in email), and thus not sending bounce messages is
fairly sane too.

~~~
vog
You are confusing "clean rejects on SMTP level" with "backscatter".

If your server accepts the email first, then scans it, and then decides it is
spam, it's too late. Then it has only the choice between ignoring and
backscatter, because it can't reliably inform the real sender - the TCP/IP
connection is already closed and the email's sender is almost certainly
forged.

However, if your server scans the email during the SMTP transfer, and rejects
it with a clean error code, the sender gets a clean error message and its _the
sender_ who is responsible to inform the client.

Note that there's another downside of this approach which is why you don't
find this early-reject very often in the wild: The receipient has no chance to
get the email, not even by scanning their spam folder. So the sender has to
understand the error message and to send a "less spammy" email, or he can't
get in contact to the receipient at all. For some professions, this might be a
no-go, as this means missing potential customers just because they use a bad
email client which sends spammy-looking emails.

However, if you don't have this "type" of customers, early-rejecting on SMTP
level is a perfect solution. We're using this configuration for years on our
mail servers, it works pretty well and we've never, ever had to send
backscatters. Yet every sender whose email was classified as spam has been
correctly notified about this issue.

------
evaneykelen
>We fix it by building smart clients.

If you allow me to pick an interesting remark from this post: I think the idea
of embedding instructions in the payload of an email is an interesting one.
For instance an email could contain text and a link to a Pivotal Tracker story
while at the same time it could contain a JSON payload which tells my
augmented email client to render the story and allow me to interact with it.
The post makes a good point in that email as a protocol is not broken but that
the problem lies with today's email clients.

~~~
7952
I agree that payloads are an interesting idea; but would be a security
nightmare. As soon as you load a URL based on an email, you are leaking
information to the sender. You could restrict the types of content, but all
you end up with is RSS.

~~~
evaneykelen
It could be implemented in a secure way, without using a URL as you mentioned.
The email client could support plug-ins (Thunderbird does I believe), the user
would authorize the plug-in to connect with his Pivotal account and the data
inside the JSON payload would be used to render a Pivotal story. With other
words: an augmented email client could do things with payloads inside emails
that are far beyond what email clients do nowadays and I believe it can be
done in a secure manner.

------
dkrich
Love this. This whole "email is broken" argument reminds me of the "SMS sucks,
and iMessage/GChat/BBM will destroy it" argument perpetuated by TechCrunch and
other tech pundits.

There are two reasons that email and SMS are not broken, and the author of
this article points them out: asynchronous communication, and no single entity
controlling the entire ecosystem. The value of knowing you can reach anyone,
anywhere, anytime is worth a lot more in most use cases than some extra
features appealing to one or two very specific use cases.

~~~
joedev
SMS helps prove the point that email is broken. When my wife sends me a text
message, does she care about the protocol? No, she just wants to remind me to
pick up appetizers, wine, and beer for tonight's party. Does she want to be
limited to 140 bytes? No. She can send a long message and has no idea about
the protocol limit. Nice SMS clients take care of splitting it up and
packaging it all back together into one seamless text message.

The SMS improvement is not an improvement to the protocol, but to the tools
and is a great example of what people mean when they say email can be
improved.

If my mother in law wants to send a gigantic PowerPoint deck of "Our Grand
Canyon Vacation.ppt", why should she sign up for a separate service to do so?

There is opportunity to improve the tools which have been and always will be
known as email.

~~~
dkrich
But your wife is one use case. Think of the users of SMS or email or any
asynchronous communications protocol as a Venn diagram. You have categories of
people who need to communicate with each other that happen to both have
iPhones. Others both have GChat. Others both have BBM. Still others happen to
be online for real-time chat at the same time.

All of these users fall into one umbrella category, however: a group of at
least two people, at least one of whom needs to say something to another
person. If I need to say something now to a friend, I use SMS ten times out of
ten. Why? Because I know, without a doubt, that if I send an SMS, it is going
to be read by that person regardless of device, software, etc. A centralized
protocol is required to tie together disparate software. The 140 byte limit is
annoying. But what happens when technology catches up to human length
requirements, and it is extended to 400 or 1000 characters? Then you are going
to care about length limits even less.

The author's point is that email as a concept and prototype is not broken and
is functioning exactly as it should be, which is why it is the preferred
communication medium for most people despite decades of development in better
chat/list/calendar clients. Knowing you can get a hold of somebody every time
is a benefit that outweighs any other. Same reason Skype hasn't taken over
cell/land line phones. Centralized protocols are a necessity. Do they come
with limitations for some use cases? Of course. Nothing can be everything to
everybody. Which is why the author's point is so well taken: that additional
functionality catering to single use-cases belongs at the client level in the
form of extensions.

Edit: Also, it seems strange to me that people argue that email is broken
because their inboxes have turned into todo lists. I think the reverse is true
and people are looking at it through the wrong end. Email is such a simple,
useful tool, that people not only use it for its intended purpose
(communication) they now also use it for managing todo lists. After all, there
are boatloads of todo list software and more and more coming on the market
everyday, and yet people still use email while they talk about how shitty a
solution it is.

------
netdog
I think part of the problem is that many, if not most people using email don't
have a good understanding of what email is and is not.

 _Email is not a reliable messaging system._ It gives enough of an appearance
of reliability that most people using it think it is reliable. But if you have
ever had a very important message disappear into a black hole with no
notification, you learn not to treat email as reliable.

 _Email is not private._ But most people do not realize this, and act as if it
is. The quantity of proprietary business information and very private personal
information transmitted by email is astounding. Governments can, and many do,
slurp all email messages. Email "providers" such as ISPs, Google, Yahoo, et al
have all your emails, even those you think you may have deleted. PGP/GPG are
attempts to add a privacy layer, but have failed because they are too
difficult for almost everyone.

Email is useful, for what it was intended for. If you expect it to be
something it was not designed to be, then of course you might think "email is
broken".

Today there is a need for a reliable and private global messaging system. SMTP
is not such a system, but it is still used as one because it's "good enough"
and so widespread that nothing better has been able to displace it.

------
scotu
To me email IS broken. But email is not broken because it's not a todo list (I
agree with the author that this is a layer above the protocol to fix).

To me email is broken because:

1\. a discussion is not a discussion but is a series of messages that happen
to have the same subject. The client trying to simulate a discussion is not
enough.

2\. a message carries all the previous discussion: top posting (or any other
way)? This should not be a problem: the other messages are (should be) in the
discussion (quoting parts of the message is fine as is).

3\. group messaging sucks so bad that I feel dirty when I add more than one
recipient to an email. Don't get me started on adding someone to a discussion
that has already started or trying to refer someone to a certain email or
discussion. Again, I feel like fixing the first point could make this better.

Google tried too hard with Wave (no email interoperation whatsoever, useless
protocols to have smarter messages/gadgets, mixing wiki messaging and
collaboration), so it failed IMHO. It should have been just the messaging
part, embeddable/linked-to a proper wiki, document, collab app. That and
supporting interacting with email users via email (this would have the problem
that the new system has initially lots of the same pitfalls of email, but not
all of them. And with time and the vanishing of email-users, those pitfalls
could vanish too). Even if is a different protocol, it should be marketed as a
different _client_.

Ah, the third point: As I see the protocol as open and distributed, I didn't
use "group messaging" by chance. That is there to solve the other first world
problem that drives me mad.

~~~
icebraining
1\. Email clients do add headers that define a thread, it's not just a series
of messages with the same subject. Specifically, they use the In-reply-to and
References headers to identify the parent and thread correctly.

Gmail uses a different model, but many MUAs shows threads as trees, just like
e.g. HN.

~~~
scotu
As you can infere, I didn't know that, thanks :)

------
jvehent
There are so many problems to solve in the world. Why would you take the one
system that has been working perfectly for the last 40 years, and rebuild it
from scratch ?

To all hungry devs who can't wait to build something amazing: don't try to
reinvent the wheel, build on top of it. Leave the email be, and focus on
what's next.

~~~
Navarr
FTP has been working perfectly for the last 40 years, why do we need SFTP?

Just because something WORKS doesn't mean it works WELL. Making an
Asynchronous email protocol would not be difficult. We can do it. Everyone
talking about re-inventing email is talking about making a protocol, not
centralizing it, not de-synchronizing it.

Email is an AWFUL AWFUL mess. It was good for its era but its no longer as
good. Any good replacement will use things like MIME and other such things and
simply be a better replacement to the protocol. It'll be the same thing but
better.

Which has happened many times before, considering how many versions of POP and
IMAP there are. Or the fact that IMAP even exists. Somebody said that email
was bad and it needed this and they made it, now we all use it.

Clearly, there is room for improvement.

------
charlieok
It's a set of distributed messaging protocols that happens to be very widely
deployed. Something else might replace it.

I'd like tools that make it not matter so much _how_ I got a message from
somebody. It could be an SMTP message or an SMS (or MMS) message or an XMPP
message or a message through somebody's privately owned social network. Just
put a little logo up in the corner so I have some sense of just what kind of
message it was. Other than that, I want all those messages brought together in
one place that I control and can get to from any device.

------
code_scrapping
A-min. The problem is that the way we're using e-mails has changed, but the
e-mail is still a good concept. I would keep it ASCII (ok, maybe UTF) and
screw everything else. It was supposed to work like that and it does it just
fine.

The other note is that the communication is changing. E-mails are less and
less like a full mail message, and more SMS-like, almost real-time, and packed
with multimedia content. I think GMail is handling that as well as it can.
It's surprising how slow it takes us to make new standards when they're
obviously needed.

~~~
gst
> and more SMS-like, almost real-time, and packed with multimedia content

Unfortunately yes.

Just a decade ago we made fun of people sending mails with HTML content
because they didn't know better. The same goes for correct email quoting.
Nowdays this seems to be commonly accepted - even by people who call
themselves "hackers". The only difference is that the omnipresent @hotmail.com
has been replaced by @gmail.com.

------
plant42
As with most things, users will complain that tool X doesn't do job Y
therefore it must be broken.

Email is not broken it does what it was orignally intended to do, namely
enable communication between a number of parties. To say its broken because it
doesn't do x, y or z is as false a statement as saying my screwdriver is
broken because its not good at hammering in nails.

If email doesn't do what you want it to do, then find something else that
does. If that does not exist, then build it. Better yet, pay me and I'll build
it. :-)

------
7952
Although I agree with the sentiment; I doubt that the solution is with ever
more powerful email apps. The end result would mean turning Outlook into a web
browser. This would be an atrocity and a technological dead end.

If email really is only a protocol; it would be better to have numerous single
purpose apps that use it as a transport. This would be hugely useful in
business where email is much less filtered than websites. If people lack the
app in question, you could provide a text/html based alternative.

------
pasbesoin
There is one thing I have found to be "broken" with email. Or rather, a manner
in which it is commonly poorly/mis-used. Group conversations.

In the work environment, little is more frustrating than not being
addressed/cc-ed on some important/critical conversation. Someone leaves your
address off, and "Bam!", you're out of the conversation.

I call this the "submarining conversation". It dives below the water, and you
remain unaware of it unless or until it surfaces. (Whereupon it often causes
considerable disruption. E.g. An entire section of specifications that you
were never made aware of.)

Or you are added to an assignment and have to spend time and effort chasing
down the various email conversations that have comprised its efforts to this
point. AND... once you have them, gluing them together in your head and/or on
screen or in text, in order to come up with a coherent and not overly
redundant picture.

Google's Wave I saw as a genuine effort to address this. Actually, it is
really an iteration on the centrally stored, group conversation. For example,
web bulletin boards that were "all the rage" about a decade ago.

Wave added decentralize-able membership controls and sophisticated authoring
and version control. Things very useful in a work or similar environment.

It didn't need to be email. But it could better fulfill a role too often
filled poorly by email.

HOWEVER, Google slapped a ridiculously bogged down and unintuitive user
interface on top of it, then said "figure it out". And so, it died, at least
as a Google product and with respect to gaining Google's potential momentum.

SO, I'd say there are some applications of email, that could better be done
other ways than through email. But this is not email's fault. It is the result
of the limitations of users, both conceptually and in terms of the limited
scope of tools that -- particularly in many work environments -- they are
supplied and permitted.

P.S. Such organization of conversations pertains not only to contemporary
work, but also to compliance and audit-ability. When trying to determine later
what happened, with email conversations one it left to obtain, search, and/or
reconstruct any number of email archives, hoping that none of the archives nor
individual messages have been irretrievably lost or deleted.

~~~
Gormo
> In the work environment, little is more frustrating than not being
> addressed/cc-ed on some important/critical conversation. Someone leaves your
> address off, and "Bam!", you're out of the conversation.

Internal message boards are a possible solution to this.

------
lonnyk
I think the confusion comes from the fact that Email has two definitions: a
protocol and a client. Both of which are referred to as Email.

I find this happens quiet often in technology. It is important at times to
specify, but I do not think it is always required.

For instance, when you say 'Email is broken and needs to be fixed'. Unless you
have the solution I think it is more appropriate to be ambiguous.

------
Lednakashim
Whats the difference? If our client reads specialized xml instead of
plaintext, haven't we "changed" e-mail to the extent that we have broken it
for non-compatible clients? To me e-mail is ascii/html without meta-data, when
we add meta data we have e-mail 2.0, which is not compatible and hence
different.

------
antninja
Email is broken by spam. It's incredibly difficult to send mails without being
blocked by one of the antispam systems. The big names easily block IP
addresses of the SMTP servers if one user has been declared a spammer. This is
not a "perfect" and healthy protocol.

------
mkopinsky
Can anyone tell me what, if anything, is added to this article by the
profanity and obscene references? The point made here is good, but the
language detracts significantly.

------
Estragon
Is someone actually proposing to update the email network protocol to support
todo lists, or is that just a straw man?

------
joedev
For better or worse, email has been and always will be an application. When
people say email, they almost always mean their email client and not the
protocol. Sorry, that's just the fact. You can use energy trying to change
that, but it seems like as much a waste of time as attempts to get the US to
change to metric.

~~~
ForrestN
Well, as one piece of data, I certainly mean the system, rather than any one
client, when I say "email."

When I say "email me," I don't mean "make something show up in _gmail_ ," I
mean, send me a message over the email protocol. I don't use email as a to-do
list. I use it for correspondence, often with people who use other clients.

My conception of email is client-agnostic, and I think almost everyone I deal
with (admittedly outside of the tech/valley/startup inside) thinks of it the
same way. I hear things like "I'll shoot you an email," or "I need to check my
email," or "what program do you use for email?", none of which imply that the
speaker intends to be talking about an app.

Texting isn't an app, the telephone isn't an app, email isn't an app, at least
for many people.

------
fluorid
Don't shoot the messenger.

And Email is just the messenger.

------
erpa1119
Been reading hacker news for a while but haven't posted till now.

Extending the functionality of Email or What could you accomplish if emails
were machine readable?

Email is currently not easily parsable by machines and therefore creates a
unique challenge (and business opportunity) to companies that are in need of
automating tasks based upon incoming emails.

What is needed is functionality that allows for emails to be easily read and
parsed by machines, allowing for things such as bug reports to be routed
directly into a company’s CMS or database or to-do’s to be created
automatically or any other advanced use that a company may require based upon
their own unique business requirements.

What if we could inject a template into an email message based upon the domain
name of the recipients email address and or type of email that the user is
sending?

Changing the way in which billions of people use email is a large and
difficult challenge, the requirement for augmenting the existing system needs
to be extremely easy to use from a users stand point as well as from an
administrator’s standpoint.

The system, outlined below would not require any change to the way that users
currently use email, which from a “take rate” perspective for billions of
users is nearly frictionless and has zero adoption impediments.

Templates: Templates would in essence be xml envelopes embedded in the email
html body.

Templates are nothing more than xhtml/xml files with embedded html controls
such as text boxes, radio buttons or any other valid html controls including
basic html elements that an email client can display.

A template would be downloaded and possibly cached on the user’s device from
either a global generic template repository for companies that do not wish to
create their own or pulled from a company’s public template server.

The template could be displayed in the users new mail message window as a
dropdown box of available templates[1]. When the user selects the given
template say for instance a bug report template from the drop down list, the
xhtml/xml would then be injected into the body of the email message for the
user to fill out. In addition, if the email address has a default template,
the email template would automatically be injected into the html email body of
the mail message.

Template Security: To help alleviate the potential security risk of a template
being pulled down from an unknown or untrustworthy source, perhaps because of
the user misspelling a recipients email address domain, new templates that are
downloaded to the users device would require the user to accept a domains
Email Template Certificate (ETC) which would display the companies identity
(company name, email address, phone, address, ticker symbol, hash of the
existing template and hash of the new one, etc.) based upon reverse dns lookup
queries to the domain in question.

For instance, when a user types in bugreports@microsoft.com or other such
email addresses, either on the lost focus event of the “To” textbox (for e.g.
the user presses the tab button on their keyboard) or on a email clients
parse/verify email event a background thread could be started to pull down the
most recent templates. Should the user be “offline” a cached version of the
template would be used.

Overwriting templates would also prompt the user to accept the new template,
displaying items in text such as changes, version number, support and or
contact information etc. I imagine it being a prompt (i.e. message box or
modal form) with 2 or more tabs, with the front one being a basic overwrite
request with written changes from the OEM, date released etc. and the 2nd tab
showing a “diff” and other technical details for power users.

Template Parsing: It is inevitable that an email containing a template would
be replied to or forwarded to another address or set of addresses. The parsing
system should only parse the first template (from a top down POV), placing all
other content into a “previous entries” variable. Should an email contain
content before the first template envelope the parser shall parse this content
and include it in an “additional details” variable, making that, as well as
any “previous entries” variable available to the containing systems Business
Intelligence modules/handlers.

Template Definitions: A global definition for template types and definitions
should be created and maintained on behalf of the system itself, owned,
operated and overseen by a board elected by OEM partners and public interest
groups, such as the W3C or IEEE does today.

Forgive my crude photoshop skills...
<http://img59.imageshack.us/img59/5738/emailheaderp.png>

~~~
kristianc
A combination of GMail filters, canned responses, and a service like
OtherInbox could go some way towards solving this problem, without added
cruft.

------
zobzu
yay another email post.

------
ricefield
This guy gets it.

~~~
the0x
Agreed!

------
blackysky
love this post !!! e-mail is not broken but we don't use e-mails like 2000...
we need a smarter client

