Re: Scope for self-destructing email?

John C Klensin <john-ietf@jck.com> Wed, 16 August 2017 18:44 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E42132396 for <ietf@ietfa.amsl.com>; Wed, 16 Aug 2017 11:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 HdphidI51L8e for <ietf@ietfa.amsl.com>; Wed, 16 Aug 2017 11:44:09 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5524126B6E for <ietf@ietf.org>; Wed, 16 Aug 2017 11:44:09 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1di3IU-000GpU-I2; Wed, 16 Aug 2017 14:44:06 -0400
Date: Wed, 16 Aug 2017 14:43:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: Matthias Merkel <moritz30@moritz30.de>
cc: Ted Hardie <ted.ietf@gmail.com>, "ietf@ietf.org Discussion" <ietf@ietf.org>, vaibhav singh <vaibhavsinghacads@gmail.com>
Subject: Re: Scope for self-destructing email?
Message-ID: <B51EC6138C87451D02AB6B53@PSB>
In-Reply-To: <4c4a0d3a-352b-4be0-8163-f581e5d4d549@email.android.com>
References: <4c4a0d3a-352b-4be0-8163-f581e5d4d549@email.android.com>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JT9dNfGssdAm6SbyCCWcyHDeayw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 18:44:12 -0000


--On Wednesday, August 16, 2017 20:10 +0200 Matthias Merkel
<moritz30@moritz30.de> wrote:

> The difference seems to be that Expires is a pre-set email
> header. The command for this can be sent after the email was
> already sent.

But, if an MUA is going to process it, which is implied by
"Invalidation of Messages... mark messages in a way, that the
client somehow can mark the message as "not being relevant
anymore"..., then it needs to make it into the headers of the
message that is seen by the receiving MUA.  Probably we have
enough mechanisms in message management protocols to signal the
delivery MTA or message store to insert that header field.
While I think any of us could devise some new mechanism that
would not require new header fields, such a mechanism would
imply inventing and deploying more machinery and make adoption
of this mechanism even less likely.

But I think the above (both your comment and my response)
demonstrate my main point -- it is time to get to an I-D that
specifies the details rather than continuing an on-list
discussion that is mostly about generalities (as a striking
example, note "...or something like that) and which each of us
is hearing a little differently as to what are, and are not, key
elements of the proposal.

best,
    john