Internet-Draft Structured Email: Trust and security con October 2023
Happel Expires 25 April 2024 [Page]
Network Working Group
Intended Status:
H.-J. Happel
audriga GmbH

Structured Email: Trust and security considerations


This document discusses trust and security considerations for "structured email" ([I-D.happel-structured-email-00]) and provides recommendations for message user agents on how to deal with structured data in email messages.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 25 April 2024.

1. Introduction

Structured email aims to make the content of email messages machine-readable, such that algorithms can help users deal more efficiently with their email.

Accordingly, special considerations with respect to security and trust of structured data in emails should apply for such algorithms.

2. Conventions Used in This Document

The terms "message" and "email message" refer to "electronic mail messages" or "emails" as specified in [RFC5322]. The term "Message User Agent" (MUA) denotes an email client application as per [RFC5598].

The terms "machine-readable data" and "structured data" are used in contrast to "human-readable" messages and denote information expressed "in a structured format (..) which can be consumed by another program using consistent processing logic" [MachineReadable].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Types of security concerns

This section discusses security and privacy concerns that may be raised when introducing structured data into email messages.

3.1. Formal representation of data

Structured email aims to provide a machine-readable version of email content. Hence, the machine-readable information typically won't go beyond what is communicated in the human-readable part of email messages.

Accordingly, the major difference is the formal nature of the data, which makes it easier to extract and process. Certain forms of formal data are however already common today, such as (flight) reservation data encoded using barcode or the PKPASS format.

3.2. Automated processing

Structured data in email messages might users want to create certain automated processing chains. For example, a user might want flight reservations to be automatically added to a travel itinerary application.

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

3.3. External references

Emails with a text/html body part ("HTML emails"), may contain image resources that link to web servers. Such links can be used for tracking user interaction with their MUA.

Similar concerns would 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.

In addition, RDF structured data might be impartial by design and include mere references for additional data. Using a "follow your nose" approach, tools can try following URL references to obtain further structured data concerning a resource.

For example, a piece of structured data about a news article could opt to 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.

5. Trust mechanisms

5.1. Trusted senders

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

In addition, such trusted senders may be added to the MUAs address book or a special list therein.

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

5.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 puts burden on the recipient to discern if a message is legitimate 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 issues
* Message id?

6. Categories of use cases

Certain types of structured data might need to be kept more secure than others. For instance, the structured data representation of a music album shared by a friend would not contain major personal information, while e.g., medical records or financial statements certainly would.

7. Implementation guidelines

7.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).

Open isues
* Github

7.2. Inlining data

Strucutured data included in an email message should be self-contained. This means that a MUA should be able to provide meaningful user interaction also without loading additional referenced resources from the web.

Open issues
* Github

8. Implementation status

< RFC Editor: before publication please remove this section and the reference to [RFC7942] >

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

8.1. Structured Email plugin for Roundcube Webmail

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

9. Security considerations

Security considerations are core subject of this document itself.

10. Privacy considerations

Privacy considerations are core subject of this document itself.

11. IANA Considerations

This document has no IANA actions at this time.

12. Informative References

The Calendaring and Scheduling Consortium (“CalConnect”), "Calendar operator practices — Guidelines to protect against calendar abuse (CC/R 18003:2019)", <>.
NIST, "NIST IR 7511 Rev. 4", <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, , <>.
Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, , <>.
Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, , <>.
George, R. and B. Leiba, "Sieve Notification Using Presence Information", RFC 6132, DOI 10.17487/RFC6132, , <>.
Melnikov, A. and B. Leiba, "Sieve Extension: Externally Stored Lists", RFC 6134, DOI 10.17487/RFC6134, , <>.
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

Author's Address

Hans-Joerg Happel
audriga GmbH