Referencing big external files in email messages

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 without including them inline. In order to achieve this the document defines a new email header field "Content-External" as specified in .

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 when, and only when, they appear in all capitals, as shown here.

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 , 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 for details of the syntax. URL -- URI (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 "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. 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, encoding can be used in Content-External parameter values.

[[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?]]

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in . Non-terminals referenced but not defined below are as defined by MIME, part 1. 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.

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 / 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) 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 = ]]>

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.

This document requests IANA to add the following registration to the Permanent Message Header Field Registry, in accordance with the procedures set out in .

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

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.