Re: [Jmap] the large email (attachment) problem

[Jamey Sharp <[e-mail]>]

On Sat, Jul 31, 2021 at 01:00:47PM -0400, John Levine wrote:
>It appears that Jamey Sharp  <[e-mail]> said:
>>In the text (plain or HTML) parts of the email, large attachments are
>>still referenced by a URL provided by the sender, as has become common
>>practice today. However, we add new attachment-like parts which serve
>>several purposes: to indicate that a given URL should be treated like an
>>attachment at the recipient, to provide metadata hints, and to provide
>>alternate URLs for retrieving the attachment. ...
>
>Take a look at message/external-body in RFC 2017, 2046 and 2912.  It already has size,
>URL, expiration, and content-features parameters.
>
>We could add a few new attributes to external-body like an optional encryption key.

I'd never heard of message/external-body, and wow, that would be perfect 
if everyone implemented it. The 20 years of personal email archives I've 
managed to keep don't have a single instance of that type in them 
though, which is disappointing: I'm guessing there are few, if any, 
implementers today.

I assume the "normal" way to use this in an HTML email would be to 
assign a Content-ID to the multipart/alternative containing the 
external-body, if there is one, or to the external-body part itself, and 
then reference it using "cid:" links, right? But that doesn't work if 
recipients don't understand message/external-body.

Would this work instead? Encourage recipients to collect the URLs from 
any external-body parts and treat references to those URLs as equivalent 
to "cid:" references to the corresponding part. Then a sender can still 
link to e.g. Google Drive in the HTML and plain-text parts, so that 
recipients that don't understand external-body can at least follow the 
link if they want to, but supporting implementations can also choose to 
treat it fully like an attachment.

If that seems reasonable, then I think this is indeed most of the way 
there, and just needs new stuff for integrity and confidentiality.

Jamey