Email is not broken: It’s a framework, not an application

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.

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

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

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.

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.