Internet DRAFT - draft-melnikov-email-big-files

draft-melnikov-email-big-files







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-<digest-name> -- 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 = <Defined in RFC 6838>
subtype-name = <Defined in RFC 6838>

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*<any (US-ASCII) CHAR except SPACE, CTLs,
            or tspecials>

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 = <Defined in RFC 5322>

date-strict = day SP month SP year
       ; day month year

day =   1*2DIGIT

year =  4*DIGIT

month = <Defined in RFC 5322>

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 = <Defined in RFC 5322>

CWFS = <Defined in RFC 5322>

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,
              <https://www.rfc-editor.org/info/rfc5234>.

   [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,
              <https://www.rfc-editor.org/info/rfc2045>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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, <https://www.rfc-editor.org/info/rfc2231>.




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,
              <https://www.rfc-editor.org/info/rfc3864>.

   [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,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc2046>.

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]