Trust and security considerations for Structured Email

3.1. Spam/virus filters

Structured email increases the syntactical and semantic complexity of email messages. If a spam/virus filter parses structured email in order to block malevolent messages, the filter's parser will necessarily differ from that of the MUA that will finally act on the structured data, creating a risk of misclassification.¶

These risks are elevated when a structured data format has complex syntax, syntax that offers several optional or alternative ways to express the same substance, and of course by parsers that deviate from the specification for better bug compatibiloty.¶

3.2. Formal display of data

A common example is displaying a received calendar invitation using dates/times in the recipient's timezone, in a fixed format.¶

Formal display introduces additional possibilities of discrepancy between the different representations. For example, a single message might contains a multipart/alternative containing a text/plain description of a flight itinerary, a text/html description of the same itinerary, and a structured representation. All three may be different, leading to confusion (and in this example, perhaps to missing a flight).¶

Unintentional discrepancy is a risk for senders; some recipients may be misinformed.¶

If a message is sent to a group and there is a discrepancy, different members of the group may see it differently.¶

If a particular MUA displays the formal representation within the message, a malevolent sender could try to mimic the visual representation using HTML with CSS, but with misleading content.¶

3.3. Automated processing

Automated processing covers actions that are taken as soon as the message arrives rather than when a human user reads the message. For example, a user might want flight reservations to be automatically added to a travel itinerary application and/or a calendar.¶

Such automation could be a custom MUA feature or a future extension of the Sieve email filtering language ([RFC5228]). A related example for abuse in automated processing is calendar spam ([CalSpam]).¶

3.4. External references

Email messages with a text/html body part ("HTML email messages") may contain image resources that link to web servers. Such links can be used for tracking user interaction with the message.¶

Similar concerns apply to structured data types which include image references, such as the cover image of a music album or the teaser image of a news article.¶

RDF structured data can be partial by design and include references to additional data. Using a "follow your nose" approach, tools can follow URL references to obtain further structured data concerning a resource. For example, a piece of structured data about an article could reference the article's authors only by URL. For a meaningful processing of author information, one might try to obtain further data using that URL.¶

4.1. Trusted senders

For the case of displaying remote images embedded in HTML email messages, MUAs often allow users to manually choose if they trust a certain sender.¶

Sometimes, addresses in the MUA's address book are considered trusted, or in a special list in the address book.¶

Besides mentions in related use cases ([@RFC6132]/[@RFC6134]) this mechanism is currently not standardized.¶

Several services manage trust centrally: trusted senders are trusted by the mail service rather than by the individual users.¶

4.2. Sender signatures

4.3. Domain signatures

DKIM defines a signature on sender domain that may be used to verify that a message was sent by the same sender as an earlier message.¶

Some mail hosts restrict structured processing to messages with DKIM signatures, or to a set of senders who are identified by their DKIM signatures.¶

4.4. Transaction identifiers

Part of the simplicity of email is the fact that just the email address is required to reach out to a recipient. This however required the the recipient to discern whether a message is desirable or abusive.¶

Recipient-generated transaction identifiers aim to pass a certain secret to the sender, which helps to prove legitimacy. One such approach are one-time email aliases, which are generated for a single transaction or series of transactions.¶

Structured email by itself might also help define special types of structured data that could help to manage and communicate transaction identifiers more easily.¶

Open issue 1: Propose a header field with an opaque cookie like thread-id, to tie a message to older messages?¶

6.1. Processing structured data

MUAs SHOULD consider structured data in incoming email messages only if:¶

• The sender is trusted (e.g., part of the user's address book) and the messsage either contains a valid personal or domain signature¶

• The message is part of an ongoing thread with a trusted sender¶

If none of those criteria is fulfilled, MUAs should fallback to alternative presentations (e.g., "text/html" or "text/plain" of such message).¶

6.2. Inlining data

Structured data included in an email message should be self-contained in order to avoid privacy problems. This implies that if an MUA is able to provide meaningful user interaction (rather than mere display), then it should do that without loading additional referenced resources from the web.¶

7.1. Structured Email plugin for Roundcube Webmail

The plugin currently uses the "trusted sender" feature of Roundcube to determine if structured data should be processed.¶