How to fix email while still keeping email | Hacker News Reader

How to fix email while still keeping email

gd0t.com

63 pointseof25 comments

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

The only properly-focused criticisms of email I've read go along the lines of "Email is uselessly robust". I don't personally agree, but what I'm getting at is I agree with your message. E-mail is fundamentally a messaging infrastructure; do with it what you will. If you don't like your inbox filling up- that's not an inherent flaw of RFC-5321 (and related RFC's).

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

> If you want JSON messaging included, you could build a client that reads that specific MIME type and interprets it differently than other messages

This is literally what I suggested in the article.

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

that is definitely a big problem that I don't see any solution to.

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.

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.

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

Could not agree more! Sick of the "I did not get your message" -BS!!! You got it and you know it!

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.

Go ahead do that.

Just know I have a filter to ban those who send read requests too often.

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?

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.

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.

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.

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.

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.

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.

failing to understand that in reality it shows up when, as you say, "It's good and ready".

That may be the reality for sending e-mail to random people on the internet.

However, when both the sender and the receiver are under your control then you can indeed make assumptions about average latency, delivery guarantees and failure modes.

I.e. an e-mail will normally arrive instantly (sub-second) unless it is relayed through an unknown path or the network-path is down.

Most MTA's were not designed to be used as a backend message-queue - but can still work very well for that when configured accordingly, as they have most of the relevant primitives baked in (durability, error reporting, redundancy, re-sends).

There's nothing wrong with piggybacking SMTP for such jobs as long as you know what you're doing.

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

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

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.

Thanks in advance.

Seems like a good fit for activity streams?

Reply on news.ycombinator.com