On Thu, Aug 17, 2017 at 9:23 AM, John C Klensin <john-ietf@xxxxxxx> 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.