Network Working Group B. Gondwana Internet-Draft FastMail Intended status: Experimental A. Melnikov Expires: 9 May 2024 Isode 6 November 2023 Referencing big external files in email messages draft-melnikov-email-big-files-00 Abstract This document specifies a way to reference big attachments in email messages without including them inline. 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/. 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 9 May 2024. 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. Gondwana & Melnikov Expires 9 May 2024 [Page 1] Internet-Draft Big Files in Email November 2023 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 2 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 2 3. Content-External header field . . . . . . . . . . . . . . . . 3 4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Requirements on the solution and alternative solution not taken . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction and Overview Most SMTP systems limit the size of messages that can be sent, which can be as low as 10 Megabytes. Moreover, limits vary depending on recipient's system. End-users want to send files to each other and the file sizes that end-users create keep getting bigger. This document specifies a way to reference big attachments in email messages [RFC5322] without including them inline. In order to achieve this the document defines a new email header field "Content- External" as specified in Section 3. 2. Document Conventions 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. Gondwana & Melnikov Expires 9 May 2024 [Page 2] Internet-Draft Big Files in Email November 2023 3. Content-External header field The Content-External header field can appear multiple times. Each instance describes an externally referenced attachment. The generic syntax of Content-External header field is the same syntax as used by the Content-Type header field [RFC2045], so the same generic parser can be used. The media-type value is the media type of the external attachment being referenced. (Note that if a different media type is returned when the external attachment is retrieved, the value in the header field overwrites the value returned by the retrieval protocol). The list of currently defined attributes of Content-External is included below. See Section 4 for details of the syntax. URL -- URI [RFC3986] (typically an HTTPS URL) used to access the external attachment. This parameter is required and it can only appear once. NAME -- The recommended name of the external attachment. This parameter is optional, but can't appear more than once. DIGEST- -- Value of the specified digest of the external attachment in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter is optional, but can't appear more than once. EXPIRATION -- The date (in the [RFC5322] "date-time" syntax) after which the existence of the external data is not guaranteed. This parameter is optional, but can't appear more than once. SIZE -- The size (in octets) of the data. The intent of this parameter is to help the recipient decide whether or not to expend the necessary resources to retrieve the external data. Note that this describes the size of the data in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter is optional, but can't appear more than once. Gondwana & Melnikov Expires 9 May 2024 [Page 3] Internet-Draft Big Files in Email November 2023 PERMISSION -- A case-insensitive field that indicates whether or not it is expected that clients might also attempt to overwrite the data. By default, or if permission is "read", the assumption is that they are not, and that if the data is retrieved once, it is never needed again. If PERMISSION is "read-write", this assumption is invalid, and any local copy must be considered no more than a cache. "Read" and "Read-write" are the only defined values of permission. This parameter is optional, but can't appear more than once. In order to allow for long parameters, [RFC2231] encoding can be used in Content-External parameter values. Simple example 1: Content-External: application/postscript; name="BodyFormats.ps"; url="https://www.example.com/storage/123"; expiration="Thu, 30 Nov 2023 19:13:14 -0400 (EDT)"; size=1234567 Example 2: Content-type: text/html; URL="https://www.example.org/1/2/3/4/5/6/7/ 8/9/10/11/12/13/14/15/16/17/18/20/21/ file.html"; SIZE=100000000; digest-SHA-256="..." [[Open Issue: ]] The ability to include Content-ID header field is lost, when compared to message/external-body, so external attachments can't be referenced inside multipart/related? Should we define "id" as a new parameter of Content-External to address this issue? The Content-External header field appears in the header section of the body part that is used to display a message to a user of a MUA that doesn't support this extension. Such body parts MUST have either "text/plain" or "text/html" media types. (Future revisions of or extensions to this document can allow use of Content-External with other media types). If a Content-External header field appears in the header section of a body part which is not listed above, it MUST be ignored. [[Also allow it at the top level message level?]] MUAs compliant with this specification SHOULD hide body parts with one of the media types listed above that also contain a Content- External header field. They MAY present a UI allowing the user to download such external attachments or they MAY do this automatically. [[See Security Considerations. Should we always require user confirmation?]] Gondwana & Melnikov Expires 9 May 2024 [Page 4] Internet-Draft Big Files in Email November 2023 4. Formal syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by MIME, part 1 [RFC2045]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. type-name = subtype-name = content-external = "Content-External" ":" [FWS] media-type [CFWS] *([FWS] ";" [FWS] parameter) [FWS] media-type = type-name "/" subtype-name ; Matching of media type and subtype ; is ALWAYS case-insensitive. parameter = attribute [FWS] "=" [FWS] value attribute = token ; Matching of attributes ; is ALWAYS case-insensitive. value = token / quoted-string token = 1* tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / <"> "/" / "[" / "]" / "?" / "=" ; Must be in quoted-string, ; to use within parameter values allowed-display-media-parts = "text/plain" / "text/html" ; Allowed media types for display body parts ; where Content-External is allowed. registered-content-external-params = url-param / name-param / expiration-param / size-param / permission-param / Gondwana & Melnikov Expires 9 May 2024 [Page 5] Internet-Draft Big Files in Email November 2023 digest-params url-param = "URL" [FWS] "=" [FWS] url url = value ; Syntax as described by absolute-URI in RFC 3986 ; When represented as a quoted-string, internal ; SP/TAB are stripped from the value before full ; URL is reconstructed. name-param = "NAME" [FWS] "=" [FWS] value ; Recommended file name expiration-param = "EXPIRATION" [FWS] "=" [FWS] expiration-value expiration-value = quoted-string ; the quote string value is [ day-name "," ] date-strict ; time-strict day-name = date-strict = day SP month SP year ; day month year day = 1*2DIGIT year = 4*DIGIT month = time-strict = time-of-day zone time-of-day = hour ":" minute [ ":" second ] hour = 2DIGIT minute = 2DIGIT second = 2DIGIT zone = SP ( "+" / "-" ) 4DIGIT size-param = "SIZE" [FWS] "=" [FWS] number64 number64 = 1*DIGIT ; Unsigned 63-bit integer ; (0 <= n <= 9,223,372,036,854,775,807) Gondwana & Melnikov Expires 9 May 2024 [Page 6] Internet-Draft Big Files in Email November 2023 permission-param = "PERMISSION" [FWS] "=" [FWS] permission-value permission-value = "read" / "read-write" ; The values are case-insensitive digest-params = 1*digest-param ; Multiple attributes of this form are allowed, ; as long as they all use different hashes digest-param = "DIGEST-" digest-name [FWS] "=" [FWS] digest-value digest-name = atom ; IANA registered. E.g. SHA-1, SHA-256 digest-value = value ; Define exact syntax... FWS = CWFS = 5. Security Considerations TBD: tracking access to the remote file on the web server to determine that the message was read by the recipient. (Countermeasure: automatic download by the recipient's mailstore or MUA, using private browsing relay.) TBD: Content possibly changing after the email message was sent and mitigations (include the hash). TBD: dealing with encrypted files. Also how can antivirus solutions check content automatically. 6. IANA Considerations This document requests IANA to add the following registration to the Permanent Message Header Field Registry, in accordance with the procedures set out in [RFC3864]. Header field name: Content-External Applicable protocol: Mail Status: standard Author/Change controller: IETF Specification document(s): [RFCXXXX] Gondwana & Melnikov Expires 9 May 2024 [Page 7] Internet-Draft Big Files in Email November 2023 7. Requirements on the solution and alternative solution not taken The proposed solution is motivated by the following requirements: Clients that don't support the email extension proposed in this document should be able to show links to external attachments. Multiple external attachments can be specified. External attachments can be referenced in draft messages. [RFC2046] specifies the message/external-body media type that otherwise would be a good fit, but many widely deployed email clients display it as an attachment with no link to the external attachment visible. 8. Acknowledgments Editors of this document would like to thank the following people who provided useful comments and/or participated in discussions that lead to this document, in particular: . This document copies some text from RFC 2046, thus the efforts of the authors of RFC 2046 are appreciated. 9. References 9.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008, . [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, . [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, DOI 10.17487/RFC2231, November 1997, . Gondwana & Melnikov Expires 9 May 2024 [Page 8] Internet-Draft Big Files in Email November 2023 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, . Authors' Addresses Bron Gondwana FastMail Email: brong@fastmailteam.com Alexey Melnikov Isode Limited Email: alexey.melnikov@isode.com URI: https://www.isode.com Gondwana & Melnikov Expires 9 May 2024 [Page 9]