Network Working Group B. Hoeneisen Internet-Draft H. Marques Updates: 3458 (if approved) pEp Foundation Intended status: Standards Track 20 June 2023 Expires: 22 December 2023 Email Marker to Indicate Automatic Processing draft-pep-sml-auto-processing-marker-00 Abstract Structured Email suggests to complement existing email standards by means that allow to replace or extend text-based email messages with message parts that describe content (full or in parts) in a machine- readable way. This document specifies a means to mark messages (or parts of) intended for automatic processing. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-pep-sml-auto-processing- marker/. Discussion of this document takes place on the sml non-WG mailing list (mailto:sml@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sml/. Source for this draft and an issue tracker can be found at https://gitea.pep.foundation/pEp.foundation/internet-drafts. 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 https://datatracker.ietf.org/drafts/current/. Hoeneisen & Marques Expires 22 December 2023 [Page 1] Internet-Draft Email Auto-Processing Marker June 2023 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 22 December 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Non-Deterministic Behavior . . . . . . . . . . . . . 4 1.1.2. User Confusion . . . . . . . . . . . . . . . . . . . 4 1.1.3. Automatic Filtering due to Unknown Attachment Format . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Automatic Processing Marker Specification . . . . . . . . . . 5 3.1. Whole Email Message . . . . . . . . . . . . . . . . . . . 5 3.1.1. New Message Context Class, Parameters and Values . . 6 3.1.2. Message Context Specification . . . . . . . . . . . . 6 3.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. MIME Entity . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. New Content Disposition Parameters and Values . . . . 6 3.2.2. Content Disposition Specification . . . . . . . . . . 7 3.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7 4. Recipient Client Considerations . . . . . . . . . . . . . . . 7 4.1. Hiding Decision . . . . . . . . . . . . . . . . . . . . . 7 4.2. Rendering When Hidden . . . . . . . . . . . . . . . . . . 8 4.3. Simple Policy . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Hoeneisen & Marques Expires 22 December 2023 [Page 2] Internet-Draft Email Auto-Processing Marker June 2023 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Early Ideas for Enhanced Automatic Processing Marker Specification . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Whole Email Message . . . . . . . . . . . . . . . . . . . 10 A.1.1. New Message Context Class, Parameters and Values . . 11 A.1.2. Message Context Specification . . . . . . . . . . . . 12 A.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. MIME Entity . . . . . . . . . . . . . . . . . . . . . . . 13 A.2.1. New Content Disposition Parameters and Values . . . . 13 A.2.2. Content Disposition Specification . . . . . . . . . . 14 A.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 15 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Recent IETF discussions on Structured Email (SML) [I-D.happel-sml-problem-statement] suggest to complement existing email standards by means that allow to replace or extend text-based email messages with message parts that describe content (full or in parts) in a machine-readable way. This document specifies a means to mark messages (or parts of) intended for automatic processing. Different Use Cases cover the whole message, a Multipurpose Internet Mail Extensions (MIME) [RFC2045] entity or just a part of a (MIME) entity. Note: It is for further study whether the latter case is really needed (cf. Section 2). According to [I-D.happel-sml-problem-statement] such markers are in scope for the Structured Email (SML) Working Group (in formation): * Additional email header information might inform clients about the presence of Structured Email content. This document updates [RFC3458] to extend the "Internet Message Context Classes" IANA registry. 1.1. Motivation The following scenarios have been encountered in real life, which can be mitigated by this new specification. Hoeneisen & Marques Expires 22 December 2023 [Page 3] Internet-Draft Email Auto-Processing Marker June 2023 1.1.1. Non-Deterministic Behavior Email systems that process Structured Email messages often need to apply fuzzy logic to guess, which parts of the email are applicable to automatic processing. This may lead to non-deterministic behavior or inconsistencies at receiver systems applying automatic processing. In some cases Structured Email parts are missed. 1.1.2. User Confusion Emails containing structured attachment may lead to confusion of the recipient user; for example, if an email system by default attaches the sender's pubkey key for OpenPGP [RFC4880] encryption (e.g., [I-D.pep-email]). If Alice is using such a system to send an email message to Bob, he may get confused by the attachment containing the public key, as he is lacking knowledge on how to handle such kinds of attachments. As a consequence, Bob likely will send a reply to Alice requesting said attachment in a format known to Bob (e.g., as PDF). Alice then needs to explain to Bob that he may simply ignore this attachment (as sending the public key in PDF normally does not make sense). Another case of user confusion are messages that are solely meant for automatic processing. For example, Email systems that inform peers with structures emails about revoked keys for cryptographic email (e.g., [I-D.pep-keyreset]) or systems that feature private key synchronization (e.g., [I-D.pep-keysync]). In both cases such email messages may lead to user confusion. 1.1.3. Automatic Filtering due to Unknown Attachment Format Emails containing structured attachments may get filtered by the recipient's Email system due to unknown attachment format. This may lead to removal of such an attachment or a bounce message to the sender to resend the email using an attachment format known by the recipient's Email system. 1.2. Requirements Language 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. Hoeneisen & Marques Expires 22 December 2023 [Page 4] Internet-Draft Email Auto-Processing Marker June 2023 2. Requirements The following requirements are discussed in this document. A requirement marked with [M] is mandatory, while [O] means it is optional. 1. Mark the whole email message for automatic processing [M] 2. Mark a MIME entity for automatic processing [M] 3. Mark part of a (MIME) entity (e.g., JSON, HTML, XML) for automatic processing [O] 4. Specify automatic processing to be required or optional [O] 5. Provide a SML type of the content for automatic processing such as public key, calendar data, etc. [O] 6. Provide a means to suggest hiding of specific parts meant for automatic processing [O] Note: The optional requirements need further discussion on whether or not and in which form those are needed. In Appendix A you can find some early ideas on how requirements 4.-6. may be specified, if considered useful. 3. Automatic Processing Marker Specification Note: As it is yet unclear, which requirements will be part of the final specification, the following sections (for the time being) only regard the requirements 1. and 2. (cf. Section 2). This specification will be updated depending on the outcome of the requirements discussion. 3.1. Whole Email Message This section specifies a marker in case the whole email message is intended for automatic processing. Hoeneisen & Marques Expires 22 December 2023 [Page 5] Internet-Draft Email Auto-Processing Marker June 2023 3.1.1. New Message Context Class, Parameters and Values The existing "Message-Context" Header Field [RFC3458] is reused and enhanced. The IANA registry for Internet Message Context Classes (cf. https://www.iana.org/assignments/message-header-types/message- header-types.xhtml) allows for registrations of Context Classes. A new Message Context Class 'structured' will be registered with IANA. Furthermore, the IANA registry will be enhanced to allow for Message Context Class parameters and values. The following Message Context parameter is registered with IANA: * auto-processing 3.1.2. Message Context Specification The "Message-Context" Header Field always applies to the whole message (including the Header section). To mark a message as Structured Email, the sender of an email SHOULD add a Header Field "Message-Context" with the value "structured". * Such a Header Field SHOULD also contain a Message Context parameter "auto-processing" to indicate the whole message be intended for automatic processing. 3.1.3. Example The following example shows a Header Field "Message-Context": Message-Context: structured; auto-processing 3.2. MIME Entity This section specifies a marker in case some MIME [RFC2045] entity of an email message is intended for automatic processing. 3.2.1. New Content Disposition Parameters and Values The existing "Content-Disposition" MIME Header Field [RFC2183] is reused and enhanced. The IANA registry for Content Disposition (cf. https://www.iana.org/assignments/cont-disp/cont-disp.xhtml) allows for registrations of: * Content Disposition values Hoeneisen & Marques Expires 22 December 2023 [Page 6] Internet-Draft Email Auto-Processing Marker June 2023 * Content Disposition parameters * Content Disposition parameter values (if applicable) A new Content-Disposition value "structured" is registered with IANA and the IANA registry is enhanced by the following Content Disposition parameter: * auto-processing 3.2.2. Content Disposition Specification The "Content-Disposition" Header Field applies to the corresponding MIME entity (including all subordinate MIME nodes and leafs, if present). To mark a MIME entity as Structured Email part, the sender of an email SHOULD add a Header Field "Content-Disposition" with the value "structured". For backward compatibility reasons the existing Content Disposition parameter "attachment" MAY be used instead of "structured". * Such a Header Field SHOULD also contain a Content Disposition parameter "auto-processing" to indicate the whole message be intended for automatic processing. 3.2.3. Example The following example shows a MIME Header Field "Content-Disposition" as it could be applied for an attachment containing the public key: Content-Disposition: attachment; filename="pEpkey.asc"; auto-processing 4. Recipient Client Considerations 4.1. Hiding Decision The recipient client system may apply different policies or options for Structured Emails (or parts) depending on: * local circumstances * whether or not the recipient system understands the Structured Email (or parts) Hoeneisen & Marques Expires 22 December 2023 [Page 7] Internet-Draft Email Auto-Processing Marker June 2023 4.2. Rendering When Hidden If the decision is to apply hiding (cf. Section 4.1), the system may: 1. Hide Structured Email (or parts) altogether from the recipient user 2. Simply notify there is a Structured Email (or part) meant for automatic processing (but not allow to interact with it) 3. Notify there is a Structured Email (or part) meant for automatic processing and allow to interact with it (e.g., allow to view or download a structured attachment) A short notification for hidden email could be: "Email intended for automatic processing." A notification for hidden attachments could be: "This attachment is intended for automatic processing. If you don't know what this means, you may ignore it." Such notifications should be localized to match the language set in the user interface. 4.3. Simple Policy A simple policy may be: * Render hidden emails with variant 2 and hidden email parts with variant 3 (cf. Section 4.2) 5. Security Considerations As with all content processing the recipient system needs to ensure that also Structured Emails (or parts) are checked for harmful content that may compromise the security (such as viruses, trojan horses or other malware) before or during automatic processing. 6. IANA Considerations The document requests the following IANA actions: * Extend the "Context labels for Internet Messages" registry [RFC3458] to include Parameters and Values for Message Context Classes in similar manner as defined for the "Content-Disposition" MIME Header Field [RFC2183]. Hoeneisen & Marques Expires 22 December 2023 [Page 8] Internet-Draft Email Auto-Processing Marker June 2023 * Register the Message Context Class, Parameters and Values listed in Section 3.1.1 to the "Context labels for Internet Messages" registry in accordance with [RFC3458] and the IANA action in the previous bullet point. * Register the Content Disposition Parameters and Values listed in Section 3.2.1 to the "Content Disposition Values and Parameters" registry in accordance with [RFC2183]. 7. Acknowledgements The authors would like to thank the following people who have provided feedback or significant contributions to the development of this document: Hans-Joerg Happel 8. References 8.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2183] Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, DOI 10.17487/RFC2183, August 1997, . [RFC3458] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, DOI 10.17487/RFC3458, January 2003, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References Hoeneisen & Marques Expires 22 December 2023 [Page 9] Internet-Draft Email Auto-Processing Marker June 2023 [I-D.happel-sml-problem-statement] Happel, H. and C. Junghans, "Structured Email: Problem Statement and Areas of Work", Work in Progress, Internet- Draft, draft-happel-sml-problem-statement-00, 27 January 2023, . [I-D.pep-email] Marques, H. and B. Hoeneisen, "pretty Easy privacy (pEp): Email Formats and Protocols", Work in Progress, Internet- Draft, draft-pep-email-02, 16 December 2022, . [I-D.pep-keyreset] Hoeneisen, B., "pretty Easy privacy (pEp): Key Reset", Work in Progress, Internet-Draft, draft-pep-keyreset-00, 15 December 2022, . [I-D.pep-keysync] Birk, V., Hoeneisen, B., and H. Marques, "pretty Easy privacy (pEp): Key Synchronization Protocol (KeySync)", Work in Progress, Internet-Draft, draft-pep-keysync-03, 6 June 2023, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . Appendix A. Early Ideas for Enhanced Automatic Processing Marker Specification In the following some early ideas on how the requirements 4.-6. (cf. Section 2) could be implemented. Whether or not and in which forms these requirements are needed is still to be discussed. A.1. Whole Email Message This section specifies a marker in case the whole email message is intended for automatic processing. Hoeneisen & Marques Expires 22 December 2023 [Page 10] Internet-Draft Email Auto-Processing Marker June 2023 A.1.1. New Message Context Class, Parameters and Values The existing "Message-Context" Header Field [RFC3458] is reused and enhanced. The IANA registry for Internet Message Context Classes (cf. https://www.iana.org/assignments/message-header-types/message- header-types.xhtml) allows for registrations of Context Classes. A new Message Context Class 'structured' will be registered with IANA. Furthermore, the IANA registry will be enhanced to allow for Message Context Class parameters and values. The following Message Context parameters are registered with IANA: * auto-processing * sml-type * hiding-recommendation The Message Context parameter "auto-processing" may assume the following values: * optional * required The Message Context parameter "sml-type" may assume several values that SHOULD be registered with IANA, including: * order * mailman-request * public-key * pep-key-reset * pep-key-sync * ... The Message Context parameter "hiding-recommendation" may assume the following values (in parentheses a terse explanation): * 0 (not recommended) * 1 (no recommendation; default) * 2 (recommended; ordinary users likely get confused) Hoeneisen & Marques Expires 22 December 2023 [Page 11] Internet-Draft Email Auto-Processing Marker June 2023 * 3 (strongly recommended; even savvy users likely get confused) The numbers allow to set a simple condition on whether or not apply hiding. A.1.2. Message Context Specification The "Message-Context" Header Field always applies to the whole message (including the Header section). To mark a message as Structured Email, the sender of an email SHOULD add a Header Field "Message-Context" with the value "structured". * Such a Header Field SHOULD also contain a Message Context parameter "auto-processing" to indicate the whole message be intended for automatic processing. - The Message Context parameter "auto-processing" MAY contain either of the values "optional" (default) or "required". If the recipient is unable to process a structured message containing such a "required" parameter, it MAY send an automatic reply to the sender indicating the inability to process such a structured message. However, the exact semantics are out-of-scope of this document. (Any corresponding data-format or application specification may further define such semantics.) * Such a Header Field MAY also contain a Message Context parameter "sml-type" (with a suitable value, e.g., "pep-key-reset") to indicate the type of the automatic processing. * Such a Header Field MAY also contain a Message Context parameter "hiding-recommendation" (with a numeric value) to provide the recipient's MUA with a hint on whether or not to apply hiding of the message (cf. Section 4). A.1.3. Example The following example shows a Header Field "Message-Context" as it could be applied to a pEp KeyReset [I-D.pep-keyreset] message (to inform the peer about revoked keys): Message-Context: structured; auto-processing="mandatory"; sml-type="pep-key-reset"; hiding-recommendation=3 Hoeneisen & Marques Expires 22 December 2023 [Page 12] Internet-Draft Email Auto-Processing Marker June 2023 A.2. MIME Entity This section specifies a marker in case some MIME [RFC2045] entity of an email message is intended for automatic processing. A.2.1. New Content Disposition Parameters and Values The existing "Content-Disposition" MIME Header Field [RFC2183] is reused and enhanced. The IANA registry for Content Disposition (cf. https://www.iana.org/assignments/cont-disp/cont-disp.xhtml) allows for registrations of: * Content Disposition values * Content Disposition parameters * Content Disposition parameter values (if applicable) A new Content-Disposition value "structured" is registered with IANA and the IANA registry is enhanced by the following Content Disposition parameters: * auto-processing * sml-type * hiding-recommendation The Content Disposition parameters "auto-processing" and "attachment" may (additionally) assume the following values: * optional * required The Content Disposition parameter "sml-type" may assume several values that SHOULD be registered with IANA, including: * public-key * calendar-data * contact * flight-itinerary Hoeneisen & Marques Expires 22 December 2023 [Page 13] Internet-Draft Email Auto-Processing Marker June 2023 * ... The Content Disposition parameter "hiding-recommendation" may assume the same values as defined in Appendix A.1.1 above. A.2.2. Content Disposition Specification The "Content-Disposition" Header Field applies to the corresponding MIME entity (including all subordinate MIME nodes and leafs, if present). To mark a MIME entity as Structured Email part, the sender of an email SHOULD add a Header Field "Content-Disposition" with the value "structured". For backward compatibility reasons the existing Content Disposition parameter "attachment" MAY be used instead of "structured". * Such a Header Field SHOULD also contain a Content Disposition parameter "auto-processing" to indicate the whole message be intended for automatic processing. - The Content Disposition parameter "auto-processing" MAY contain either of the values "optional" (default) or "required". If the recipient is unable to process a structured message part containing such a "required" parameter, it MAY send an automatic reply to the sender indicating the inability to process such a structured message part. However, the exact semantics are out-of-scope of this document. (Any corresponding data-format or application specification may further define such semantics.) * Such a Header Field MAY also contain a Content Disposition parameter "sml-type" (with a suitable value, e.g., "public-key") to indicate the type of the automatic processing. * Such a Header Field MAY also contain a Content Disposition parameter "hiding-recommendation" (with a numeric value) to provide the recipient's MUA with a hint on whether or not to apply hiding of the message part (cf. Section 4). A.2.3. Example The following example shows a MIME Header Field "Content-Disposition" as it could be applied for an attachment containing the public key: Content-Disposition: attachment; filename="pEpkey.asc"; auto-processing="optional"; sml-type="public-key"; hiding-recommendation=2 Hoeneisen & Marques Expires 22 December 2023 [Page 14] Internet-Draft Email Auto-Processing Marker June 2023 Appendix B. Document Changelog [[ RFC Editor: This section is to be removed before publication ]] * draft-pep-sml-auto-processing-marker-00 - Initial version Appendix C. Open Issues [[ RFC Editor: This section should be empty and is to be removed before publication ]] * Decide on optional requirements: whether or not and in which form those are needed (cf. Section 2, bullet points 3.-6.) * Need to cover more Use Cases? * Enhance Recipient Client Considerations (cf. Section 4) * Enhance Security Considerations (cf. Section 5) * Improve IANA Considerations (cf. Section 6) * Verify Terminology in Section 3.1 based on the outcome of https://www.rfc-editor.org/errata/eid7540 Authors' Addresses Bernie Hoeneisen pEp Foundation Oberer Graben 4 CH-8400 Winterthur Switzerland Email: bernie.hoeneisen@pep.foundation URI: https://pep.foundation/ Hernani Marques pEp Foundation Oberer Graben 4 CH-8400 Winterthur Switzerland Email: hernani.marques@pep.foundation URI: https://pep.foundation/ Hoeneisen & Marques Expires 22 December 2023 [Page 15]