Re: Scope for self-destructing email?

[Toerless Eckert <[e-mail]>]

John,

I did like to use a couple of those nice email functions driven
by special headers. IMHO the main reason why those never catched on
is the absence of easy ways for users to figure out how much their
software (MTU/MUA) sucks. 

One thing IMHO that would help are mechanisms to provide users with
an easy ability to learn what their software is claiming to support,
and what's missing. User experience should be some web-page that
explains this to the user in easy terms and ideally even suggests
to create RFE emails to the vendors. The question would then be what
standards APIs one would need to enable interested third parties
to generate such web pages (including IETF).

Eg: Have some yang model/API into MTU/MUA that declares the features
supported, maybe also some options to exercise probes/tests and provide
authentication to do this (eg: via the usual "i am [e-mail]
because i can show some token received in email to that address").

Admittedly, i've been annoyed for 25 years that IETF unlike ISO is not
doing PICS, so maybe this is a more pragmatic approach to tackle
that gap. And one that would be more user friendly, dynamic and maybe
even more reliable (depending on how much actual probing instead of
just declaration you would be able to do via the API).

Toerless

On Thu, Aug 17, 2017 at 09:23:06AM -0400, John C Klensin 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.
> 
> (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.  We have
> less experience with the originator of an already-sent message
> as expired or obsolete, but no evidence has been offered so far
> that such a facility would be appreciably more useful than the
> "Expires:" header field.
> 
> (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.
> 
>      john

-- 
---
[e-mail]