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

Jamey Sharp <jamey@minilop.net> Sun, 01 August 2021 16:43 UTC

Return-Path: <jamey@minilop.net>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6273A093A for <jmap@ietfa.amsl.com>; Sun, 1 Aug 2021 09:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=minilop.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuEWst-zh9Ef for <jmap@ietfa.amsl.com>; Sun, 1 Aug 2021 09:43:30 -0700 (PDT)
Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F233A093B for <jmap@ietf.org>; Sun, 1 Aug 2021 09:43:30 -0700 (PDT)
Received: by mail-pl1-x62d.google.com with SMTP id k1so16870471plt.12 for <jmap@ietf.org>; Sun, 01 Aug 2021 09:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minilop.net; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HQldz/lTm6eskUykw79uMUnUAY57XKX3yyb0hELnTO4=; b=Qku3fW92rH7rbB42N4bL86AcJhJ+zafPP4PkKyC7Zrb8lOogsGEg0GuUXmsOT8LYuV gApDbwkjoGi44CcE9wInbD4q9e92Wlq/INS3/Kva51JY1WCmsiGWyjdAoLeuworkbl4L xehy4o0iaQtg/cHyAWjsHNWlPmCEbpw6gwY1k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HQldz/lTm6eskUykw79uMUnUAY57XKX3yyb0hELnTO4=; b=SR/HZYa6hAl0Wkp7brkD9KyphjUq2CVwNL482c8s132hplPc8T6hJGSMplJquQryiQ dhlqGh9d+fBPiiV6GnjuagDjdcOHPrgwIIJfH9QWJInVlppHdbZZEnhvOcOsx707wc6z jL4O7en1GeQMtzdek62kIo2lWzvnN2jAmK5+AMnIgyv8kZ80DBHEUWwL+KCDVPZEMj3w BLcAfcII4L6ajgsFZ+iubUY+Q8/osF85B38qtYH1brI/f5+mtzgCy3Uf2tKspcxH+Ol/ +NpOlKcXXPEkdqZDFBi/YgxI2Y7hcCqf+54HGXAe497qrpDhy8QX0MwNIFbgAAtMjGC/ cYng==
X-Gm-Message-State: AOAM531sWSxf2a21oLkUyOMXGP9GDDlqycw5zGGyEFLL/IVtiIzkgIyC FR8b8Sg6VC9qX/OhoIJVidHxsO1zJkqnzfAh
X-Google-Smtp-Source: ABdhPJzzj7+j6ETwejyxGIJ31/1U3cw4DhlgJWvkCzPRN/B9895QHYerDLLxQXcDBnyvCfMk+2g6VQ==
X-Received: by 2002:a63:d849:: with SMTP id k9mr2936640pgj.67.1627836208592; Sun, 01 Aug 2021 09:43:28 -0700 (PDT)
Received: from eh (63-230-166-62.ptld.qwest.net. [63.230.166.62]) by smtp.gmail.com with ESMTPSA id h24sm9010458pfn.180.2021.08.01.09.43.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 01 Aug 2021 09:43:28 -0700 (PDT)
Received: by eh (sSMTP sendmail emulation); Sun, 01 Aug 2021 09:43:26 -0700
Date: Sun, 1 Aug 2021 09:43:26 -0700
From: Jamey Sharp <jamey@minilop.net>
To: John Levine <johnl@taugh.com>
Cc: jmap@ietf.org
Message-ID: <YQbPLiMLCVowKgyj@eh>
References: <CAJi=jadiwMGvLXG7nK93Ht=TzN-QdmAqyE4Nf7UnGG47f3zSwg@mail.gmail.com> <20210731170047.DE0772563EB0@ary.qy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20210731170047.DE0772563EB0@ary.qy>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/88cWlZCj1NmV7L3d6hP7opqCRQk>
Subject: Re: [Jmap] the large email (attachment) problem
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Aug 2021 16:43:37 -0000

On Sat, Jul 31, 2021 at 01:00:47PM -0400, John Levine wrote:
>It appears that Jamey Sharp  <jamey@minilop.net> 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