Referencing big external files in email messages
draft-melnikov-email-big-files-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Bron Gondwana , Alexey Melnikov | ||
| Last updated | 2023-11-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-melnikov-email-big-files-00
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]