Re: Scope for self-destructing email?

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Aug 17, 2017 at 9:23 AM, John C Klensin <[e-mail]> wrote:

> Folks,
>
> It seems to me that three things are emerging on this thread.
>
> (1) The original proposal and problem to be solved, at least as
> most of us understood it, was to allow a sender to send some
> sort of notification that would cause all copies of a message to
> be  automagically destroyed.  We appear to have unanimity that
> problem is unsolvable, at least in the general case and/or in
> the absence of universal trust.
>

​It is agreed that it is impossible to solve without trustworthy hardware.

The only thing that has stopped me adding such a feature to Mesh/Message
has been that there is a dense thicket of IPR covering such techniques and
I have not read it.

If the next President of the US was to come to me and ask if I could
provide a mechanism that would allow her to send an email message to
members of her cabinet and that supported a 'recall' feature, I would have
no hesitation in saying yes, conditional on some technical support which
Microsoft and Apple and some others are both capable of providing.

If she then said, 'What about adding the UK Prime Minister', I would answer
no.
​


> (2) We have considerable experience (in both email and netnew)
> with putting out messages with expiry dates as information for
> the recipient (whether expected to be acted on automatically or
> not).  While there are important exceptions, they have never
> been as useful as was apparently assumed when they were
> adopted... to the point that the IANA registry entries for the
> relevant email header fields identify them as obsolete.


​That might be because they were never implemented sufficiently widely. I
can turn off send receipts for example.

Another issue is that SMTP is a push service, not a pull service. For
Mesh/Message, I want to provide a superset of the capabilities of dropbox
like mail and SMTP like mail. So my basic scheme is:

When the mail is sent: Store the message on the sending server, send a
notification to the receiving server.

If the message is less than the receiving server size limit (varies by
sender), forward the body of the message after x minutes.

The reason for this is that most of the times I want to recall a message,
it is because I want to add the #Q$%%* attachment or correct the spelling
mistake.


(3) We have now reached the stage in which people seem to be
> discussing alternate problems that can be solved.  That isn't
> very hard, but those alternate problems are not the original one
> and little or no case is being made that the new problems are
> worth solving or that solutions would be useful, even if they
> are feasible.
>
> It seems to me that, if people believe there is a problem worth
> solving and if they think they have a feasible solution, we need
> to see an I-D that explains both, rather than continuing to
> circle around an ever-expanding collection of possible issues on
> the IETF list in the absence of such a draft.


​Well I have released 6 drafts this week and I am currently working on
another 3...

I don't think it is a problem that is solvable within the framework of
SMTP. It is a problem that can only be solved in the context of a new
messaging infrastructure in which every user supports the capability by
default. Such infrastructures have been successful in the recent past, see
Snapchat. Sure, they are wobbling a little now. But they have more users
than S/MIME, OpenPGP, IPSEC and SSH combined.
​