In my recent article on ending no-reply email, I had my out-of-office notification bouncing off no-reply email addresses.
This raised two points for me. One is that my email provider1 isn't aware of no-reply addresses. The second is the end service wasn't aware of my out-of-office. As far as both services were concerned, everything was a regular email2.
An objection to this is that so many permutations of communication exist. Same goes for the web, and we're still embracing JSON-LD. The data model behind JSON-LD, schema.org is not perfect. Nor is it intended or need to be4.
Many services already scan the content of the emails. Services like TripIt and Expensify have it as a core feature. Gmail will also parse out common items like Airline tickets.
Looking at the source content5 of an email will horrify you. In the case of my American Airlines ticket, the plain text version was blank. In contrast, the HTML version was an exercise in brutalism. The latter isn't AA's fault. HTML in Email is a hacky process. It's roughly equal to supporting every major browser version, ever.
Parsing HTML is a brittle method. Modern HTML has some semantic features. This helps a little. The HTML used in email has none6. So using JSON-LD here presents a major improvement. You can keep your HTML email, but annotate it with normalized, machine-readable data.
Google's Gmail already does this7. If you have a JSON-LD event in your inbox, it'll attempt to parse it out. If you're a Gmail user, you've likely seen the "One-Click actions" and event details. That's coming from JSON-LD.
What does Google support?
Google has documented their JSON-LD support in GMail. This was heartening, but I wanted to see it in action for myself.
Getting your hands dirty with JSON-LD and Gmail didn't prove as easy as I imagined. You need to send from a domain with DKIM/SPF set up. Plus you need to be whitelisted by Google. There are some workarounds. Rather than bore you with the details, you can see the sample code on GitHub: https://github.com/jonathannen/semantic-email-tester.
The results of that test were initially a little disappointing. One-Click-Actions and Flight Tickets worked great. But none of the other examples did (10/12). Then I checked in Google Inbox rather than Gmail. All the samples showed up great. You can take a look at a sample screenshot.
If you're sending emails from your application, start dropping JSON-LD into your emails. Especially if you have one of the supported types. Including the data won't hurt and could drive adoption. One nice side effect is it makes your emails just a little more test-able to boot.
Bots in your Inbox
For the number of times email has been declared dead it's got amazing staying power. And there continues to be innovation on the client-side. Gmail is one example. Newer ones are platforms like Superhuman and Front.
Adding in JSON-LD and other semantic data gives a new opportunity with email. You could tag Out-Of-Office automatically. Requests for simple information could be streamlined or automated. Email becomes a method of data-exchange.
It's also easy to imagine more bot-like functionality. The ability to share your location, catalog purchases, get filtered recommendations.
Since it needs to be supported on two sides, it's a chicken-and-egg adoption cycle. The security framework also needs to mature. Email is a major vector for security attacks. So increasing the surface area on the face of it is a terrible idea. Hence Google's whitelisting approach. Even so, with the right controls it also could make email more secure.
There is still a lot in email. It touches many of the transactions in our lives. Right now that data is just sitting there. Being able to leverage that data could open up a bunch of possibilities. New and existing email clients use this as a route to innovate and win new customers.
And, perhaps, it'll mean we can dispense with no-reply emails for good.