IETF Logo Mail Archive

Re: [ietf-smtp] message/external-body

"John R Levine" <johnl@taugh.com> Thu, 10 January 2019 22:09 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF373131284 for <ietf-smtp@ietfa.amsl.com>; Thu, 10 Jan 2019 14:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=e7IfLeBN; dkim=pass (1536-bit key) header.d=taugh.com header.b=ZdJBrJV6
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 cHxUUANxAUCv for <ietf-smtp@ietfa.amsl.com>; Thu, 10 Jan 2019 14:09:55 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926E0131218 for <ietf-smtp@ietf.org>; Thu, 10 Jan 2019 14:09:55 -0800 (PST)
Received: (qmail 67413 invoked from network); 10 Jan 2019 22:09:53 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10753.5c37c2b1.k1901; bh=AKJqgrcW5hqawAfDrG1/jKo5ptCqPU6Q2dHS+Jr7bwA=; b=e7IfLeBN5sBNqhCTI12hbmidgmHv9COWfGQZTJ/vcNOBV/tCc/i6VnGaCp+zH84GlKJY8Mzn3h74B1W2PaRz5jlwJwVbnsg6BUXCHnsz3Td02ZAefRVvavjVbpB70JFu+lIaVJSUKpAKtn7wW+8R++NwwoQTaKZe6yzP3q3Ut5M7Iqic7prz9FaB0TbFO0p3r54OZNUzCGQ1MoeCctl/P8MFNZzvi1vVyX2DvjqCqPWrRLgnV0yf9QXBcPQXLJPw
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=10753.5c37c2b1.k1901; bh=AKJqgrcW5hqawAfDrG1/jKo5ptCqPU6Q2dHS+Jr7bwA=; b=ZdJBrJV6Se4FzDpkF0ZklQIDRh6J5aRV35N6nIBAlUgU7hxJ8esL804jXiptGNA9/anHpFYIDKJa61yT2HeezSYDQzgjXudMP16aGDkMIcHtztTdv9nMHFh6pRcEud121EW6M8H/6rNaicUyiOfjRKqChn7MRBENQsi0peyVXUBe9StsXt1vF5QLqzSGc9vEgOopabz2Ni1Pv0OLOWZOqlSV6VuwokDx6kMOqzNSyp2xRpTCdlP+EATrrUz9/dZm
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jan 2019 22:09:53 -0000
Date: Thu, 10 Jan 2019 17:09:53 -0500
Message-ID: <alpine.OSX.2.21.1901101655280.19314@ary.qy>
From: John R Levine <johnl@taugh.com>
To: valdis.kletnieks@vt.edu
Cc: ietf-smtp@ietf.org
In-Reply-To: <18810.1547156963@turing-police.cc.vt.edu>
References: <20190110210727.8878F200C85075@ary.qy> <18810.1547156963@turing-police.cc.vt.edu>
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/59yMSyKOSI-5VrKMhZ4kRePI3YU>
Subject: Re: [ietf-smtp] message/external-body
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Jan 2019 22:09:58 -0000

On Thu, 10 Jan 2019, valdis.kletnieks@vt.edu wrote:
>> I'd really rather the duct tape be applied to make external-body work
>> better.
>
> Agreed.  The last time I looked at this (admittedly quite some time ago), the
> biggest missing parts were an RFC-standard way to denote an expiration time
> ("this URL good until <datestamp>")

Wouldn't that be the expiration= parameter?  See RFC 1521, section 7.3.3.

> and a secure way to pass an indication of what credentials are needed to 
> access the object.

That seems rather un-mail-ish.  The usual model is that if I can read the 
message, I can read anything in the message.  If someone else can peek at 
the message in transit or whatever, they can read whatever's in it.  If 
the message is supposed to be secret, encrypt it with S/MIME or PGP, or 
maybe just encrypt the external-body part.  To make the URL hard to guess, 
make it long and pseudo-random, but most URLs from Drive, Dropbox, et al. 
are anyway.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

v2.23.0 | Report a Bug | By Email