Email client APIs. features. amd siupport (was: Re: Scope for self-destructing email?)

[John C Klensin <[e-mail]>]

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

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

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.