Re: [dispatch] Work for IETF114 message external bodies

John C Klensin <> Fri, 10 June 2022 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 683DDC1A7F15 for <>; Fri, 10 Jun 2022 10:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vPrvYXyoIxSr for <>; Fri, 10 Jun 2022 10:33:39 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0D82C13607D for <>; Fri, 10 Jun 2022 10:33:39 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1nziVt-00030V-Da; Fri, 10 Jun 2022 13:33:37 -0400
Date: Fri, 10 Jun 2022 13:33:31 -0400
From: John C Klensin <>
To: John Levine <>,
Message-ID: <E2F1A655449DE3B55E6934F2@PSB>
In-Reply-To: <20220610164052.3150B4356B3B@ary.qy>
References: <20220610164052.3150B4356B3B@ary.qy>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [dispatch] Work for IETF114 message external bodies
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jun 2022 17:33:43 -0000

FWIW, this is a much more fully-developed version of the "let
the MUA deal with it and use message/external body" idea in the
note I sent a couple of hours ago.  I see some problems with the
details of what John suggests, but they are details that could
be sorted out rather easily.  Similarly Tim Bray's suggestion
(also within those couple of hours, is a (more complete)
variation on my "trick URL" approach.  The path I was headed
down might do a slightly better job of protecting the key
itself, especially against the unwary, but with emphasis on the
"might".  In both cases, the proverbial devil is in the details.


--On Friday, June 10, 2022 12:40 -0400 John Levine
<> wrote:

> It appears that Bron Gondwana  <> said:
>> Use case: user wants to store a file encrypted on a server,
>> and provide a link such that their recipient can get the
>> decrypted file, without the server ever seeing the plaintext
>> content.
>> Which basically means - the URL/URI that the sender provides
>> to the recipient contains the key data to decrypt the content,
> When this came up before we noted that the
> message/external-body MIME type defined in RFC 2017 gets us
> most of the way there.  It currently lets you point at a URL,
> and it would be straightforward to add a few new headers along
> the lines of:
>     Content-ID: <>
>     Content-type: message/external-body; access-type=URL;
>                   URL=""
>     Content-type: video/mp4
>     Content-Transfer-Encoding: binary
>     Content-Length: 1234567890
>     Content-Hash: SHA1/22od022m2m3s00ll2lo23ou32
>     Content-Encryption: AES-CBC
>     Content-Key: swordfish
> The length and hash let the client verify that the file hasn't
> changed, the encryption and key let the client decode it.  The
> key is optional, if missing the user provides it if you don't
> trust the MTAs that forward the message.
> The Content-ID is optional, so other parts of the message can
> refer to this part as if you want to
> put a link in an HTML part.  See RFC 2392.
> A security issue is that if the key isn't in the message,
> whatever malware checking you do has to be able to run at the
> point the user provides the key so it'd be in the MUA rather
> than the delivery agent.
> R's,
> John
> _______________________________________________
> dispatch mailing list