Hacker News new | comments | show | ask | jobs | submit login
Email is not broken: It’s a framework, not an application (killtheradio.net)
336 points by orthecreedence on Apr 15, 2012 | hide | past | web | favorite | 137 comments



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.


Agreed:

Anyone who claims "email is a bad TODO list" is an email problem is missing the forest for the trees. This isn't an email problem. It's a problem inherit in any communication medium.

If you sit in an IRC channel that can become a TODO list too. For snail mail, the coffee table you throw everything onto is a TODO list. For people who receive a lot of phone calls, their voicemail is a TODO list.


> Want less spam? Don't distribute your address or sign-up everywhere.

Around 1999 or so I noticed someone trying to send spam to every common name on my mail server. I had never given out my email address and yet here I was getting spam just because I had a server. Even if I heavily obfuscate my email address on my website such as with this hack http://icefox.github.com/js_email_link_hack/ I would still get spam because this attack vector.


Yeah you can't really avoid spammers getting your address. That said, it's pretty much a solved problem.


Something like fail2ban could deal with this.


This.

Only partially related, but I'm sick of people coming up with more, 'better' ways to communicate which are then embraced by a subset of my friends and colleagues. My email arrives on my phone, on my laptop, on my (and any) PC, in an easy to read, indexable, exportable and simple format, wherever I am in the world, in near real time. I have had the same email address for ~ 12 years and with Google's spam filter I get zero spam. I actively manage mailing list subscriptions and have no problems there either.

Seriously, for people asking where their jet pack is - take a step back and think about all of that.

It's infuriating for me that my friends choose to use Facebook, Twitter DMs, any number of 'groundbreaking' proprietary messaging apps and a million other message transports (don't get me started on iMessage). Email is a message, in text format (with optional binary attachments), between a number of people. Nothing more, nothing less.

The world has bigger problems to solve.


A glut of "email is broken" posts just before the YC decision day and just after Paul Graham's "Frighteningly Ambitious Startup Ideas" essay smacks of insincerity.

I can imagine email software that does exciting things with JSON data in emails, but I wouldn't alter the underlying protocol.


Great post and we found the hidden agenda of this "email is broken" propaganda. It's sad that the VC/startup business heavily relies on hype to drive interest and valuation.

Nethertheless, I welcome that seemingly a lot do not blindly follow this BS.


> Want less spam? Don't distribute your address or sign-up everywhere.

Quite a lot of spam isn't my e-mail address on mailing lists or sign-ups, it is people I know getting a virus or downloading an app that uploads their address book. I have an e-mail only used with friends that gets an amazing amount of spam (not a common name).

E-mail has problems because it isn't one thing. E-Mail is SMTP, IMAP, POP3, and whatever weird thing Exchange is doing.

I really don't see a replacement since we seem to be in the "closed system" stage of social media much like we once were in the same stage with e-mail (e.g. MCI could not send e-mail to AOL). Variants of IM might have worked but the open versions really didn't make it to everyone.


Thanks for this. I had a hard time articulating why email is not broken, and you pretty much sums it all up.


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


> Email was not designed to be used the way we use it now. ...my inbox is a todo list

So we should not use email as a TODO list, but keep a separate TODO list. Email is not broken, it's just the wrong tool for keeping TODO lists.

I would never have thought of (mis)using email for a TODO list, and I'm astonished to read from various famous people (not just pg) that they're seriously doing that. Maybe this is a typical mistake of Internet beginners, but why are so many experienced and very busy people doing such a huge organizational mistake, every day?

There are lots of tools for keeping a TODO list. For my personal purposes, a plain text file works flawlessly. [1] Bigger organizations use various forms of issue trackers, or use a simple Wiki to simulate an issue tracker.

[1] http://news.ycombinator.com/item?id=3830247


If you get lots of emails, then you won't always have time to follow up on all of them. Somtimes the mere task of comprehending the email to create todos from it takes energy, and you don't always have energy to do that immediately. So the emails queue. Effectively the emails become tasks. After several weeks of high load you find your inbox is crammed with lots of things you mean to get around to but you're exhausted.

This is a common problem for busy people and has no obvious solution. One way we try to tackle hard problems is by identifying them, and then having open discussion.

    > or use a simple Wiki to simulate an issue tracker.
    > For my personal purposes, a plain text file works
    > flawlessly. 
The mechanisms you're talking about don't scale to situations where you're being hit by a firehose of emails and calls, but where you have to have concentration periods as well. e.g. technical role that's customer-facing.

My current solution is multi-layered, and starts with a text file. But it's not the simple problem that you make it out to be.


The common problem you describe is still not about email.

The real cause lies in people with deficits in time management, organisational skills and leadership.

If you have too many projects/threads going on with too many people time to change: do fewer projects, focus, delegate, give people goals rather than nitty-gritty todos, basically stop micro-managing, find talented peers and trust them.


There are mechanisms through which some limitations of email can be worked around, but there are still problems with email.

Technologies lend themselves to particular use and misuse, and when we see a repeating patterns of abuse, it's reasonable to focus on the technology and talk about what we can do differently.

The original post is talking about email as a series of protocols and ignoring the culture of email as we use it in day-to-day use. It's a nerdy rant that dismisses a problem space by forcing a new definition on the language, rather than addressing the problems that people suffer. The chap I relied to continues the tone by insulting people who are dealing with the queue.

Email is the monitoring messages that clog up my inbox. It's the reasonable expectation of response that happens when somebody sends me an email, unlike with my phone where I leave voicemail turned off or a colleague can take a call and I can know that ownership has shifted. Email is the ease with which a difficult-to-understand message is sent and the exhaustion created by comprehending it. It's the poor integration with task management. It's the awkwardness around tracking ownership of an issue that's sent to a group list. It's spam. It's the compromises you make to avoid spam. It's how awkward it is to implement IMAP, and the multiple eccentricities of different IMAP servers, and how woeful POP is. It's Lotus Notes and Exchange, and being forced to use them.


I think people are looking at it the wrong way, it's not problems with email it's the fact that email is flexible, decentralized, reliable that makes it possible to use it for any of these tasks.

The asynchronous messaging that email provides is it's killer feature that would need to exist for any of the features (todo,task management,calendering...) that you mention would need to work well. But the underlying mechanism of email is still working fine and I don't think that should change.

I agree with the article, the client is where this should go with maybe some thing similar to the W3C and Browser vendors (This isn't perfect but it works) agreeing to protocols.


> find talented peers and trust them.

This is the most important advice, I think. Although delegating, etc. is very important, too.


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.


Good point, it reveals a lack of organizational and leadership skills. If one is so wanted that his inbox is quickly full either he has to reduce workload or hire staff and delegate.


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.


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?


All of the above.


> but there is definitely a fundamental problem with email that can't just be solved by a couple of perl scripts and rules

And what is that problem? Yeah, email makes a poor to-do list, but if everyone around you is eating soup out of top hats, then you need to rethink soup bowls, not top hats. Tinkering with email doesn't help you make a better to-do list.


I agree with the entire sentiment as well, but would point out one flaw: You send a message and it either goes where it’s supposed to, or you get an error message back.

Generally yes, assuming everything between you and the recipient is properly configured, but it's not guaranteed. It's possible to send an email had it just disappears. No bounce, no delivery. It doesn't happen often, and as far as I know it's never happened to me, but there's nothing in the protocol that guarantees delivery or guarantees notification of delivery failure.

That said, this is not a big enough problem to require a new protocol or a change to the existing protocol, or in any other way be worth "fixing." If you are building something that requires guaranteed delivery of messages, don't build it on SMTP.


Nothing on the internet is guaranteed. Everything is at some point a leaky abstraction.

While it's possible for a mail to just disappear (or more often, automatically be sorted into a spam folder) the protocol is designed to be quite robust in how responsibilities for delivery are passed on to servers delivering the message.


Doesn't this argue for a TCP-type implementation of "Did you get that or shall I resend?" ala Read Receipts? (On top of SMTP, that is...)


Documented?

Email is a good asynchronous messaging protocol, it's not a great one though. I'd say authentication would be a requirement for such a protocol to be great. I think the next logical step of content protection (encryption) is free if you have authentication and most would want it too. You also don't know if a message has been received, ignored, or blocked by a spam filter.

It's good, it does manage to work and deliver billions of messages a day. And it works pretty well. It's infuriating when it doesn't though.


What's wrong with layering, say, GPG on top of email if you want authentication or encryption?


Indeed. A great protocol is a flexible protocol, and restricting email to one authentication and/or encryption protocol would prevent it from adapting to advances in cryptography.


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)


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


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.


vulgarity can definitely be artful. this was not a case of it.


By your definition. I disagree. That's the nature of art.


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


You don't agree that different people have different sensibilities regarding language?

Or is that you don't agree the author should be allowed to swear in his blog?

Or perhaps you don't agree that blue material is fitting for HN?


Or perhaps some things are distractions, and the audience deserves to read about the issues without distractions being deliberately inserted into the conversation?


Undoubtedly that's true, but the GP said "Diff'rent stroke for diff'rent folks", and the parent said "I disagree."

For certain, the blog in question would be better received by some if it were written differently, but I don't know what that has to do with the conversation here. (The counterpoint is likely true as well.)

I'm trying to determine what about "Diff'rent strokes for diff'rent folks" the parent could choose to disagree with.


didn't the second sentence give you a hint good enough to determine what he doesn't agree with?

no offence but I feel like replying to a troll, and I know I shouldn't :(


If the second sentence answered the question for me, I wouldn't have asked it.

I'm not sure what he disagrees with, or where he intends to enforce this 'polite etiquette', or why someone posting an entry on their blog should be beholden to his set of rules.

It's a genuine question to slake my own curiosity. I am by no means the arbiter of all things tactful, but I am curious where he expects the boundaries to be drawn. I am also extremely eager to hear how one can disagree with the idea of "Diff'rent strokes", as I would posit it as the hallmark of tolerance.

If it is our idea that we should promote civility above tolerance, or above intellectual discourse, then I'd like to hear more insight on that.

Also, not that it's my place to say, but one of my favorite guides for posting on HN is to 'assume good faith'. If you feel like you're responding to a troll, then you shouldn't respond, or you're just feeding worse onto bad. If you're responding, then you should assume good faith, and not make responses like "I'm feeding the trolls".

I don't know what could have been trollish about my question, but I also don't see any particular added value in your comment except to make doubly sure that I actually intended to ask the question I already asked.


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


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


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


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


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.


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


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.


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.


The more I think about this, the more you are wrong. Etiquette shouldn't be enforced, it should be automatic and implied.


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?


I think you are probably right that most aren't proposing changing the actual protocol. However, I think part of what the post is reacting to is the marketing around the ideas for new clients, or the perceived need for new clients.

I haven't been following this so closely, but the articles I have read seem to position these proposals as changes to e-mail as a system, if not as a protocol. I leave thinking the authors want to do something radical, to alter something longstanding, to go up against giant, ingrained players and conventions.

I don't think this post would have happened if we were instead hearing more about "new ways to use e-mail," or "adding functionality to an email client." I think the narrative is more like, as others in the thread have referenced, PG's frighteningly ambitious ideas, more like visionaries who are daring to challenge something so established.

Making a new email client that has some extra features is one thing. Changing email forever is another. I think that's what the post is reacting to.

Edit: and, anyway, I think sharpening the discussion by invoking the difference between the client and the protocol is useful, and hopefully will make future conversations about this more clear.


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

http://paulgraham.com/ambitious.html


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.


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.


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


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.


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


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


I don't agree that this is just a matter of relativistic personal preference. There is also the objective context. So many people think that this kind of style works much better in the context of a standup comedy than in a technical discussion.


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


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


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


Looking at the ten most recent messages in my inbox, I have a political call to action, two invitations to apply for jobs, two newsletters from companies about their services, two informational newsletters, an invitation to a meetup, an account statement and a request from a friend to host a website on my server.

Half of these are not to-do items in a sense other than "please read this text". They don't even want a reply.

* The political call to action is an annoyance; it wants me to sign a petition against CISPA. I plan to write my congress people directly instead. I don't know how I got subscribed to these, but writing this comment reminded me to unsubscribe.

* I don't want to read any of the four newsletters. I might want to read them some day, and ideally, they'd be filtered in to a "newsletters" folder and not show up as "new mail" when they come in.

* The account statement is something I want to have but not act on. It shouldn't trigger a "new mail" alert either.

* I have no desire to apply for the jobs. I'm kind of curious as to where these people got my email address, as they appear to be actual employers and not recruiters.

* I might go to the meetup.

* I wrote a reply to my friend, agreeing to host her website and telling her what she needs to do to make that happen.

How do you propose to improve my experience?


Filters that can automatically file an email from a particular sender in a folder and mark it as "read" (so it doesn't give you a new mail notification) are something that's already been implemented. For example, both Mozilla Thunderbird and Microsoft Outlook support it.


I know I can manually set up filters. I haven't though, and I suspect I'm not in the minority.


What makes you so sure that 99.99% of people using email think it's a todo list and why do think they mean their email client?


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.


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?


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.


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


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


Take a look at DMARC. [1] The webpage is horribly ugly, but essentially, it allows a domain to declare that all their outgoing mail are DKIM-signed and SPF-passed.

Paypal and eBay do this. Gmail filters out any DKIM-fail or SPF-fail mails purporting to be from @paypal.com and sends it to spam, with 100% accuracy. Gmail also puts the little 'key' icon next to the sender name, but that's not really important, the point is that any and all fraudulent emails are filtered out with unerring accuracy.

Thus, we don't need to use PGP or whatever, which needs to be handled at the client level. DKIM + DMARC is already here and working at the server level. You don't need to wait for your favourite email client to adopt DMARC.

Yes, if people send emails without going through that SMTP server etc etc.. that's a problem, but also solvable/solved.

[1] http://dmarc.org/


IMO this looks overly complicated, especially as SPF works fine. The only problem with SPF right now is that many receivers (including) GMail don't abide to the specification. If there's an "-all" clause at the end this implies that you must not accept mails from other mail servers than the ones allowed. If you still do - your fault - but don't complain that your users receive mails with faked sender addresses.


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.


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.


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


This comment is rather silly. Gmail is a hosted service, and tgerefore, their servers would decrypt incoming email on your behalf. Therefore, they could still read your email.


Yes, spam filters work OK, so what is the problem? Do we really need some governmental/corporate agency deleting our emails, with all its attendant dangers of abuse? Because that is what you will get. I would rather have spam.

GPG has email clients and key management clients (e.g. seahorse) which make it increasingly user friendly.


Ok, maybe the fascinating circular should never make it onto the network. To be fair, I meant viagra sales rather than circulars.

GPG is not user friendly. Remember, the public are stupid.


Spam is a human problem more than a technical one. We need deanonymization to name and shame the spammers.


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.


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


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


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


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


Context.IO provides API access to core resources in IMAP-enabled mailboxes such as messages, contacts, threads and attachments, and provides webhooks to manage all of these. Apps can be notified of specific content as it arrives, instead of constantly polling a mailbox for matching content. Makes development of apps that look for and push important messages much much easier. http://context.io/docs/2.0/accounts/webhooks

Full disclosure, I do Community Management/Developer Relations for Context.IO.


KDE's system-centralized PIM solution, Akonadi, seems a decent way to solve that problem. It's designed to share data between local application and external services in a standardized way.

Of course, considering almost everyone is using webapps for that type of stuff nowadays, you'd probably need an Akonadi-on-the-cloud solution, POSTing stuff to each webapp as messages come in.


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.


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!


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.


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


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.


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.


No but you DO need a new protocol for the mess that is mime types in emails, and the two popular open access protocols IMAP and POP - which are atrocious.


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!


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


Simple: use filters, unsubscribe, keep your inbox at zero by default.


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


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.


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.


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.


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.


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.


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.


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.


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.


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


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.


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.


"The horse-and-buggy has been working perfectly for the last hundred years, why rebuild it from scratch?"

Nothing is beyond disruption. Just because a technology is sufficiently functional doesn't mean there's no benefit to rethinking it.


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


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


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.


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.


Yes - sending bounce messages isn't a good idea in most cases. But you don't need to: you can just reject messages during the SMTP dialog and then there's no need to send a bounce (that what's the mailserver I use does).


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.


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.


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


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


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.


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.


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


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.


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.


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.


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.


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


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.


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.


> When people say email, they almost always mean their email client and not the protocol.

Yes, but which client? I use mutt, my office manager at work uses Outlook, our accountant uses Gmail, and our advertising manager uses Yahoo.

The fact that we can all email each other seamlessly is inherently because of the common protocol, even though we don't think of it consciously when talking about email.


Don't shoot the messenger.

And Email is just the messenger.


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


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


yay another email post.


This guy gets it.


Agreed!


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




Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: