

How to fix email while still keeping email - eof
http://gd0t.com/node/23

======
orthecreedence
As I commented in another post bashing email recently, there's nothing to fix,
and this can be easily pushed to the client. As a messaging protocol, email
works great. If you want JSON messaging included, you could build a client
that reads that specific MIME type and interprets it differently than other
messages. Is this not how Outlook meeting requests work? They are just shown
as random attachments in non-supporting clients. Outlook meetings are not part
of the email standard, _nor should they be_.

We don't need to add more cruft to email itself. If you want to create extra
protocols for doing different things using email as a medium, go ahead. Email
is extendable, as Microsoft, Gmail, Xobni, etc have shown.

Long story short, you can do whatever the hell you want with email. It's not
perfect, but it's a really great messaging framework. You can send any message
you like, to whomever you like. How the recipient interprets that message is
up to them (ie their client).

EDIT: just wrote this up since I'm sick of repeating myself:
[http://blog.killtheradio.net/technology/email-is-not-
broken-...](http://blog.killtheradio.net/technology/email-is-not-broken-its-a-
framework-not-an-application/)

~~~
lucian1900
Actually, email as a standard is horrific. It would be worth the effort to
replace it just to move to something more consistent.

------
qznc
The problem: Unknown mime-types are displayed as attachements. People are
confused due to these "broken attachements". That is why I do not use
"PGP/MIME", for example.

As far as i know, there is no mime-type stuff to the proposed "semantic
alternatives".

~~~
ricardobeat
Is that really an issue? I get those weird attachments from Outlook very
often, mostly in corporate mail. I think most people have been conditioned to
simply ignore them.

------
zdw
Some of this could be very good - I already get messages like "your next issue
of 'Linux Journal' is ready" that tip me off to go grab it. It would be nice
if this would auto-download and get synced up to my other devices - especially
for things like bills, statements, etc.

But I tend to think that's a corner case (email based subscriptions
notifications that need to be delivered by non-email means) - we already have
tech to do this, between Microformats, RSS feeds with enclosures, and other
established attachment formats like vCard and [v|i]Cal. I'm thinking that
building on those rather than inventing new and arbitrary JSON syntax to
enclose via MIME is probably a better long term strategy.

I also see the distinct possibility of abusive, antisocial behavior. Most
people don't understand whitelisting, and the crazies among them already set
their email clients to always tag every email from them as being "IMPORTANT",
demand read receipts on everything, send HTML only messages, and worst of all,
top post.

~~~
toomanysecrets
There's nothing wrong with read-receipts. In fact I think all messages should
have them.

~~~
darklajid
You can add it to all your messages easily.

But there's no way you'll succeed in pushing people to reply to those requests
you're making.

Mail to my inbox might be considered 'important' by the sender and might
consider a header that makes my MUA ask me if I'd like to confirm that I'd
read the message - but I can disagree and decline. In fact, I have rules that
filter out important flags at work (they are always abused and there's no need
to flag something on your side if I'm reasonably on top of my mail queue
anyway) and ignore read receipts (Send me stuff and I read it unless it is
spam. But I decide when and won't disclose that with anyone).

Use a good subject and accept that mail is not a real time protocol and we're
getting along.

------
sopooneo
Correct me if I'm wrong, but isn't this essentially how MS Exchange works for
calendar items and invites and probably a whole bunch of other things I've not
encountered yet?

------
pfraze
I've been working on a JS framework to make this simple in web apps.
<http://github.com/pfraze/link> It's not ready to use, but I wanted to mention
it here so nobody starts a duplicate effort unnecessarily.

The use case goes in both directions: extensable code means plugins to do what
you need, and reusable code means multiple remote services can use the same
UIs. Think of a single inbox which natively sends & receives messages with
email, private social network(s), twitter, Facebook, LinkedIn, and anything
else with a web API (or that can be wrapped in one). Adding new services
and/or UIs is just adding a JS file.

So I'm building this HMVC-like mediator framework that uses command objects
(which behave like http requests / responses) to try to make that happen. It's
kind of like a set of UI-building proxies in the browser. Each module is a
contained set of resources which should drop into a URI structure and start
working.

I need to refactor the API a bit and write the docs. I also figure it would be
cool to package it with some node servers to allow users to install it and run
it purely clientside, since all it really needs is config persistence, a proxy
to deal with cross-origin, and some gateways to handle oauth.

------
Canuteson
There are so many other problems with email that could be addressed by a new
protocol, eg: spam, security.

There are measures to address these issues more broadly with SMTP, but they
are not widely adopted, something that could be standardized in a new
protocol, ie: encryption by default, message signing to prevent spoofing,
encrypted transmission, etc.

------
keyle
I was writing an imap client recently and I also thought about using that in
the same way to prompt for deadlines or bringing a sense of urgency.

In fact email is wrong but so is ADSL's design (using the high frequencies on
copper lines) - yet it works. So at the cheapest, email protocol could simply
be augmented with a set of metadata which then clients have to somehow
integrate.

It doesn't sound like the solution, but it is a quick and dirty fix. And it
may be all we need until the real solution emerges, which I think nobody quite
knows what it is yet.

------
xd
I was attempting to use email as a message transport mechanism some time back
.. some problems I ran into; off the top of my head:

1, Acknowledgement of receipt .. this has a whole load of pitfalls to watch
out for so you really have to treat email as a send and forget and if you
require acknowledgement of a message .. good luck.

2, Timing, email isn't real-time, your message will arrive when it's good and
ready.

~~~
mrweasel
I've used email as a transport mechanism for more things than I care to think
about. In some cases it was a perfect fit, and in others... no so much.

I build a system that synchronized user data between to organisations. It
didn't need to be real time, just a nice feature where a user could change his
or her address a the parent organisation and it would later trickle down to
other systems.

A second system has handling orders for production of electricity in the
Danish power grip. The decentralized power plants had a little as 15 minutes
to react. The designers of this system clearly didn't understand email, the
assumption was that emails show up in a minute or two, failing to understand
that in reality it shows up when, as you say, "It's good and ready".

Email can be a good it for a messaging mechanism, you just need to consider
the application. If you need to communicate with a lot of people or system
cheaply, and you can afford to lose a message or two, emails fine.

On the other hand, email and ftp is most likely the two most misused protocols
ever devised.

~~~
xd
That's interesting about the powerplant .. I bet there was a good amount of
face palming going on when that was picked up.

Email appealed to me mainly because it explicitly includes identity. The
system I was attempting to use it for was an online school data management
system that needed to stay in sync with the schools in house data systems.
Unfortunately spam filters just kept breaking things, because in the UK many
schools have what are know as "managed services" which translates to underpaid
keyboard monkeys with no clue running their IT infrastructure.

------
justauser
Interesting idea. How would you go about simple authentication to prevent
spoofing since PGP/GPG is too difficult to explain?

~~~
chimeracoder
> PGP/GPG is too difficult to explain

I don't know about that - I was able to get my dad (not a tech-geek by any
means) to understand it enough to start using it very easily.

The Web of Trust may be harder to explain, but you don't _need_ to take
advantage of the Web of Trust in order to get value out of PGP/GPG
signatures...

------
Navarr
I like this. This seems like a good temporary fix before one of us finally
breaks down and creates a good email protocol that takes the uses of modern
email into account; as well as a webclient and server for that protocol.

Mayhaps I'll have time for that this summer.

~~~
Fuzzwah
Thanks in advance.

------
pepijndevos
Seems like a good fit for activity streams?

