Subject: Re: Scope for self-destructing email?

From: Toerless Eckert <[email-masked]>
Date: Mon, 21 Aug 2017 19:02:58 +0200

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 [email-masked]
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

-- 
---
[email-masked]

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 22 Aug 2017 06:44:51 +0000 (UTC)

I have begun to hope that this email thread will self-destruct.
 
Lloyd Wood [email-masked] http://about.me/lloydwood

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Aug 2017 10:10:15 -0400

--On Monday, August 21, 2017 19:02 +0200 Toerless Eckert
<[email-masked]> wrote:

> 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).
>...

Interesting idea, but a very different discussion (hence the
change of subject lines).   As you know, the IETF has tended to
avoid API specifications, largely because we have preferred
performance standards (i.e., "this is what you need to do and
support") to implementation ones ("this is the API, probably
expressed on code or pseudocode, all you need to do is call
it").  We've also tended to focus on what happens or is
transmitted on the wire between machines rather than how and
what things are dong or implemented before the bits leave a
source system or after they get to a destination one.    In
addition, many people have argued strongly that we should,
insofar as possible, stay out of the UI business, in part
because the IETF, as a community, demonstrably has no skill in
the area.

Personally, I think it is desirable to review those constraints
and assumptions from time to time and to do so explicitly.   It
concerns me a bit when we charter WGs to make major excursions
into the interface between mail delivery servers or IMAP servers
and mail stores without explicitly having that review and
discussion. 

All of that said, I think the MTA situation is fairly good,
especially if one is willing to let MTAs be MTAs rather than
expecting different, or even contradictory, functions (message
recall or destruction among them).   The MUA situation sucks,
but, I think, more because of two reasons the IETF probably
can't solve, certainly not by more standards or APIs.  First,
the providers of free MUAs as part of larger packages or
software or services have little or no incentive to strive for
high quality, especially if quality improvements would make it
easier for users to switch to other packages or mail services.
They have little incentive to carefully conform to standards
either, especially if those standards would interfere with the
lock-in to their packages or other pieces of their systems for
which they have a business model.  Second, in an environment in
which most of the users in the world are using either Webmail
interfaces to mailstores and submission systems that are
proprietary to the same providers or "free" mail clients that
are bundled with office or similar packages, it is hard to think
about where major investment in new, improved, and updated MUAs
is likely to come from, especially when one remembers that these
things need to be maintained to be and stay effective and
useful, not just developed once and put out there.   I note that
development stopped on Mulberry and Eudora years ago and that
Pegasus Mail has never really caught up with current feature
expectations and development has progressed very slowly if at
all.

There are two additional challenges to MUA development today.
HTML-format email is becoming increasingly common, sometimes
with advanced and clever (and arguably dangerous) features.
MUAs that do not use browsers (or APIs to browsers) to read that
mail but, instead, display either plain text only or that use
HTML interpreters that are very restrictive about, e.g.,
automatic processing of external links have large advantages in
terms of reduced risk from attacks but are attractive only to
specialists and others with the knowledge to care or require
significant resources to develop and maintain, especially in the
age of HTML 5.x.   As far as I know, no one has made the effort.
In addition, significant parts of the email community decided a
few years ago that support for email addresses with non-ASCII
characters in both the local and domain parts was important.
The features needed to provide and use those addresses have been
deployed very slowly, partially because of a chicken and egg
problem and, perhaps more important, because the development of
high-quality multilingual (not just multiple script, one or a
few languages other than English, or crudely translated) email
clients is a hard (and expensive, whether measured in time,
money, or both) problem.  Any work done by the IETF that would
make the task of getting those more internationalized capability
deployed more difficult would be, long-term, a serious
disservice to the community.

> 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).

FWIW, there is a point of view that suggests that what made the
PICS [1] approach important was the proliferation of options
that make protocols useful only when profiled.  The IETF, at
least in the best of our work IMO, has tended to focus on
interoperability rather than conformance to lists of features
and on keeping protocols simple enough and free of "settle
arguments but putting everything in" designs to avoid the need.
Some of us think those preferences are high on the list of
reasons why we are not all running X.400 mail today.   YMMD, but
be careful what you wish for.

      john

[1] for those who don't know, a "protocol implementation
conformance statement" that explains exactly what features of a
protocol a particular implementation, or set of implementations,
supports.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Aug 2017 01:39:12 +0200

Thanks, John for the elaborations. Fully agree.

Some thoughts:

The principle of the IETF to focus on interfaces that require
interoperability is IMHO good, and it has taken certainly a lot of
time to recognize when and how this requirement applies to
north/south interfaces, "abstract APIs", or however you want to 
call them. 

IMHO, the desire to be able to compose software on single systems
from multiple suppliers should evolve to be an ever more important reason
for the IETF to consider those north/south interfaces. As you said
of course there are conflicting market interests to continue building
"platform monopolies". I just hope that some market segments will easier
see the need for such vendor freedom than eg: the consumer market. 
I continue to be grateful we had the opportunity to deploy  rfc822
ubiquitously before the silicon valleys business model of vertical
monopolies took over.

Wrt to PICS: How about we eliminate all SHOULD/MAY fromIETF 
standards and see whats left ;-). There is also the line of
thought that a separate RFC per optional feature is a much better
way to comply with work metrics in certain companies sponsoring
IETF work ;-) IMHO i agree that options should be minimized, but
we also should find a better way for products to allow declaring
how they do implement standards because options are a fact of life
Even in the best IETF work.

Cheers
    Toerless

P.S.: I just can't let go: Self destructing emails exist for a long
time. They are called mails with programs. And they have shown for
decades now how they can destroy themselves and a lot more. So why
do we need a standard. And how do we get all those malware developers to
come to the IETF ? ;-P

-- 
---
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Aug 2017 18:04:16 -0400

> because the IETF, as a community, demonstrably has no skill in

​As you say later, this sort of thing needs regular review. As we go up the
stack, the difference between an API and a protocol quickly blurs and
eventually vanishes. ​

​Protogen is a tool I use to generate protocol specifications and reference
code from a common schema. It is similar in concept to YANG except being
designed to be used at a much higher level. Here is an example of a
specification written using it:

http://prismproof.org/Documents/draft-hallambaker-mesh-confirm.html​

​The API for the client library and server dispatch methods is ​generated
from the same schema that generated the documentation. So a protocol
specification is an API.

This is not the case for most IETF specs, of course, not even application
specs. The 'cost' of doing that is that many of the choices that protocol
designers often make are fixed:

* Encoding, is JSON
​* Discovery is SRV
* ​Presentation is HTTP

​I believe that making these choices consistent improves the spec. ​

​The API is not the same as the user experience of course. But the design
of an application protocol is ​mostly a choice of

* Which information to store at the client vs the server
* The ways the information is to be indexed at the server