Several attempts have been made to improve this situation. We discuss some of them in the following.¶
Within the IETF, various RFCs have been devised to structure certain types of email interaction. Probably most notable, iMIP [RFC2447] allows users to deal with meeting workflows in a structured manner. Further examples structure interaction with message delivery notifications [RFC8098], mailinglist subscriptions [RFC8058] or specify header-based semantic indicators for certain domains [RFC6477] or Emoji-based semantics of approval/disapproval in mailinglist discussions [RFC9078].¶
In more administrative use cases, special kinds of email body parts are used for abuse reporting [RFC6650] or administrative reporting [RFC6522]. In a USENET context [RFC1036], so-called "control messages" are defined for what can be considered certain API calls, such as for creating a USENET group.¶
Looking outside the IETF, the "Email Markup" approach [EMarkup] by Google allows allows senders to integrate certain Schema.org [SchemaOrg] annotations (such as for hotel reservations or parcel delivery) in their email, such that email clients can provide customized support, including certain easy to use response actions.¶
Email markup is still in use, but has a number of limitations:¶
- Being a proprietary standard owned by Google¶
- It does not support to annotate standard email elements such as headers or attachments¶
- It is supported by only few providers¶
- It is limited to a few fixed use cases¶
- It is only available for senders that went through an approval process¶
- It is not designed for human end users to send structured emails¶
More recently, AMP email [AMPemail] (also initiated by Google) and Microsoft Actionable Messages [AM] have been specified. Compared to Email Markup, their focus is less on semantically annotating email content, but on more rich interaction, e.g., allowing the submission of simple forms. In addition, both approaches can include dynamic elements, by retrieving certain data, or even replacing the complete email body at reading time.¶
Both approaches however suffer from similar limitations as those already pointed out for Email Markup. There also seems to be a lack of consensus, since Microsoft Outlook is reported to have removed initial support for AMP email [OutAMP].¶