
Why is email broken? - nnoitra
I never understood why email needed replacing with something else, can someone shed some light?
======
bowlofpetunias
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.

~~~
sejje
I don't want the NSA (or anyone else) to read my email as it travels across
the wire.

I have no profit motive.

------
jawns
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.

------
Casseres
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.

------
gmuslera
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.

------
byoung2
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.

~~~
chany2
Email is not broken. The usage of email is however mishandled.

\- Overload of messages

\- Email Search / Discovery

\- Finding important content

\- Unnecessary CCs

\- Major contents still live in emails

\- Go-to place for everything; filtering important vs non-important

@byoung2, I think you reference a critical problem with email as I listed
above. Sorting emails by "Actionable Categorization" by both sender and
recipient.

Getting hold of the most important information asap without re-reading the
content.

Currently, I am hacking with an idea on Hashtags for Important Email.

\- Sender can write hashtag inside contents of the emails to group them
appropriately for the recipient.

\- Multiple users using hashtag help group important content together; leading
to a Sharepoint for Email.

\- Long email threads would be summarize to get the most relevant information
possible.

Love to get your feedback @
[https://news.ycombinator.com/item?id=6948659](https://news.ycombinator.com/item?id=6948659)

~~~
byoung2
Sounds interesting...I'll take a look at the other thread. I like the idea of
hashtags for flexible categorization, but I think we need to go further, e.g.
now I can see all #startup #article emails my coworker sent me, or all
#vacation #photo emails from my college roommate who travels for a living, but
do I really have to click into each email to get the link to each article or
image attachment? Can't there be something that lets me choose
hashtags:#vacation #photo,sender:John Doe and returns a CoverFlow type gallery
of all the images, with the text of the emails as captions? Or
hashtags:#startup #article to get a Flipboard type personalized magazine made
up of the formatted text of all of the articles found.

~~~
chany2
I put your idea into consideration. See Image#3 at
[http://garyyauchan.com/sharepoint-for-
emails/](http://garyyauchan.com/sharepoint-for-emails/) . I definitely see the
need only if this new Important-Email-Inbox on my app becomes very abundant
with content. Then the need to filter becomes important.

There are two things I want to stay away from at that moment.

1) Calling this app I am developing as a "New Inbox", I think it would give
the idea there is another source for their incoming mails. The idea is you
hashtag ONLY IMPORTANT EMAILS to set yourself as a reminder, etc...

2) I would also like to avoid the Search / Filtering feature - which leads
back down to the road of Gmail's Search. One of the cases for developing this
app is because Search is not intelligent enough when there is a massive volume
of emails.

Also I am going to re-think the idea of Flipboard as the new UI medium to
become the differentiator to other email apps. Great feedback btw!

------
6d0debc071
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.

------
sullivanmatt
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 :)

------
iSloth
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.

------
cportela
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.

