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

Jamey Sharp <> Sun, 01 August 2021 16:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A6273A093A for <>; Sun, 1 Aug 2021 09:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JuEWst-zh9Ef for <>; Sun, 1 Aug 2021 09:43:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64F233A093B for <>; Sun, 1 Aug 2021 09:43:30 -0700 (PDT)
Received: by with SMTP id k1so16870471plt.12 for <>; Sun, 01 Aug 2021 09:43:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ( []) by with ESMTPSA id h24sm9010458pfn.180.2021. (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 <>
To: John Levine <>
Message-ID: <YQbPLiMLCVowKgyj@eh>
References: <> <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: <>
Subject: Re: [Jmap] the large email (attachment) problem
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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  <> 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.