Structured Email Frameworks
In recent years, several vendors have devised some general frameworks for structured, dynamic and interactive email.
Individual approaches are discussed in more detail on their respective subpages.
Comparison
Overview
| Schema.org for Email | AMP Email | Actionable Messages | |
|---|---|---|---|
| Core idea | Add machine-readable version of its content to emails | Provide special markup for creating a more interactive/dynamic email experience | Provide special markup for creating a more interactive/dynamic email experience |
| Exists since | 2013 | 2018 | 2017 |
| Sender side | Add Schema.org markup to HTML email body | Design email in AMP and add as multipart/alternative | Design email in Adaptive Cards markup and embed in HTML email body |
| Data formats | Schema.org in JSON-LD or Microdata | AMP HTML (subset) | Adaptive Cards JSON |
| Client side | Extract and process embedded Schema.org markup | Render AMP email or fall back to HTML email | Render actionble message or fall back to HTML email |
| Dynamic email content (retrieved via HTTP when viewing) | JSON lists and dynamic autocompletion | Can retrieve/replace complete actionable message | |
| Interaction (Form rendering) | Only simple buttons (“ConfirmAction”) | yes | yes |
| Interaction (Form data) | “ConfirmAction” triggers simple request against a specified HTTP endpoint | Customizable JSON data can be sent to a specified HTTP endpoint | Customizable JSON data can be sent to a specified HTTP endpoint |
| Supporting ISPs | Gmail, Yahoo, WEB.DE, Zoho | Gmail, Yahoo, Mail.ru | Microsoft Office 365, Outlook.com |
| Supporting tools (besides ISP-specific clients) | KMail, Nextcloud Mail | ||
| Related tools | KDE Itinerary | Microsoft Teams |
Discussion
While the described approaches are used in practice, they are typically confined within their vendor-specific “stovepipe”. In particular, there’s barely any support by vendor-independent 3rd-party tools, which is unausual in the case of email.
This section elaborates on various aspects which might inhibit a broader adoption of the different approaches.
High entry barriers
Getting started with either of the three described approaches is a complex and tedious task. Particularly with ISPs, there are various prerequisites imposed. This may involve manual registration and review and message sending requirements such as DKIM/SPF, which even differ between approaches and vendor.
Due to the registration procedures, it is difficult to do proper testing, which may have further negative effects on adoption.
Lack of interoperability
Interoperability is limited on the level of prerequisites (as mentioned before), but also in terms of content and its usage. Notably, vendors supporting Schema.org for Email do partially support different subsets of Schema.org and use different means of presentation to the user.
One-way communication only
All three approaches are basically designed for services to send emails to end users, which have a limited set of response actions, that initiate synchronous HTTP requests. End users cannot respond asynchronously by email (using the curresponding paradigm) and especially cannot send emails using one of the frameworks to others.
Essentially, this contradicts the otherwise decentralized nature of email technology.
Disjoint concepts
While AMP Email (AMP) and Actionable Messages (AM) are quite similar to each other, Schema.org for Email (EM) is roughly orthogonal to both approaches. While AMP/AM allow for more interaction and dynamic features, they lack possibilities to specify the semantic meaning of email content in a way EM allows.
This situation of related and overlapping but technically different approaches - sometimes even provided by the same vendor - may be confusing for potential users.