Re: Scope for self-destructing email?

joel jaeggli <joelja@bogus.com> Tue, 15 August 2017 03:12 UTC

Return-Path: <joelja@bogus.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 A9F721324A8 for <ietf@ietfa.amsl.com>; Mon, 14 Aug 2017 20:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 4Si7kJf6ogUK for <ietf@ietfa.amsl.com>; Mon, 14 Aug 2017 20:12:04 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 78BF21323C4 for <ietf@ietf.org>; Mon, 14 Aug 2017 20:12:04 -0700 (PDT)
Received: from mb.local ([IPv6:2607:fb90:824a:e8e8:80eb:e771:7c35:9cd9]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v7F3C27v033421 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 15 Aug 2017 03:12:03 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2607:fb90:824a:e8e8:80eb:e771:7c35:9cd9] claimed to be mb.local
Subject: Re: Scope for self-destructing email?
To: vaibhav singh <vaibhavsinghacads@gmail.com>, "ietf@ietf.org Discussion" <ietf@ietf.org>
References: <CACZ1GipivEf31iHchaM1OPFQF4QkfVRGVNsY_vVx=J8oFZ0JZA@mail.gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <b1289123-04ac-e62b-879e-614fae9b20b0@bogus.com>
Date: Mon, 14 Aug 2017 20:12:01 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <CACZ1GipivEf31iHchaM1OPFQF4QkfVRGVNsY_vVx=J8oFZ0JZA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fIBJW0kL8f4PC7kHwIed1YHtmvE>
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: Tue, 15 Aug 2017 03:12:06 -0000

On 8/14/17 12:01, vaibhav singh wrote:
> Hi,
> 
> As some of you may already know, General Data Protection Regulation
> (GDPR), about to be enforced in the EU within months, and calls for
> strict regulations for Right to rectify communications, Right to be
> forgotten , Pseudonymisation and Data portability.
> 
> With regards to this, me and my friends were thinking about the idea of
> a self-destructing email, wherein the sender will mark the mail to be
> destroyed (expunged from the server) once the receiver(s) have finished
> reading it/after a time period chosen by the sender.
> 
> Another enhancement to this idea was a notification which will be sent
> from some (Exploding email RFC) compliant MUA, in case the receiver
> refuses to delete the email from the client. (I know Snapchat is a poor
> example here, but they apparently send notifications to the originator
> of the snap in case any receiver tries to capture the screenshot of the
> snap. This is, in theory, what we are trying to do here).
> 
> I would also like to know about things (working groups, internet drafts
> etc) which are being done to enforce GDPR to
> email and Instant Messaging especially.

In order that you have some assurance that the demands provided at the
input side are honored on the receipt side you need effectively
end-to-end control over the system, that is the sender, receiver, and
any intermediate hops are part of the same administrative domain such
that any control imposed is actually implemented. That might be
practical for an email system but not generally for the email system.

> -- 
> 
> Regards,
> Vaibhav Singh