Re: [art] Auto-configuring Email Clients via WebFinger

[Steffen Nurpmeso <[e-mail]>]

Hello.

Sorry, but i am drawning in spam since i post in this thread, and
so i lost your response by accident.  Therefore like this.
I also make it short since our personal discurs leads to nothing
anyway, and that list is noisy as has not been for many many
months.

  |list of potential data points
  |
  |* provider information, like
  |  * name
  |  * branding information, e.g.
  |    * an icon
  |    * a color scheme
  |  * legal information
  |* contact and support information like
  |  * link to provider home page
  |  * link to provider terms of service
  |  * legal information
  |* contact and support information like
  |  * link to provider home page
  |  * link to provider terms of service
  |  * link to password reset page
  |  * link to account management page (e.g. where you can revoke access
  |tokens or set defaults)
  |  * link to online support
  |  * support hotline phone number
  |  * address of email support
  |* available services, including
  |  * a (ideally localized) display name of the service (e.g. "Inbox" or
  |"Calendars")
  |  * endpoint URL
  |  * authentication information, e.g.
  |    * required OAuth2 scopes
  |  * information about the data set
  |    * which services provide the same data set (e.g. a provider might
  |offer access to the same mailbox via IMAP, POP3, JMAP, MS Exchange,
  |WebMail, so a multi protocol client should pick only one of them)
  |  * certificate pinning information
  |* authentication information
  |  * for OAuth2 that would be the various endpoints
  |  * for client certificate authentication, that could be the required issuer

Well, this is obviously a different type of thing that i have in
mind when i think about email, which is SMTP/POP3(/IMAP) here.
(In fact ssh has to be added since it transports to postfix here.)
This reduces the above a lot.  What i need can be done by SRV,
maybe a SRVT i could think about.

I think the above is highly artificial, but having a SRV entry
which provides an URI that leads to some kind of impressum, or
imprint in english, is definetely something that is missing, when
i think about it.  Such things are often very hard to find on web
pages, even though legally required (in Germany).  The rest not,
sorry.

  |The potential successor is already in the works:
  |https://datatracker.ietf.org/wg/jmap/about/

Ah ja, that really is interesting.  Mysterious RFC 2047 examples
that should not occur in practice soil the stuff, but they of
course make the UTF-8 data that the future brings stand out even
more!  Just like always, very nice.  I see human beings happily
looking at DKIM signatures in clear text, in that bright future.
Mind you, keeping connections open more often in other protocols
would improve the results, plain DNS is an example, but as you say
correctly that now is also passed via the HTTP server (to the
browser).  If so, one could also imagine a mail superserver that
switches in between SMTP and IMAP on request.  Well, maybe not,
the asynchronousity is missing for SMTP.

Shall i live long enough to pimp the little text MUA i maintain,
and then have a nice I/O layer, then if dovecot etc. and the major
free mail services do offer JMAP already i might be going for this
thing, rather than for IMAP itself!  It really looks ok, and
i enjoyed the option that user agents no longer need to worry
about mail standards as such -- they can then simply take the JSON
part and display it directly, this is almost what UPAS of Unix v10
and even more in Plan9 had a quarter of a century before that:
using plain text processing on the individual parts of messages
simply by accessing those as files in a (virtual) file system.
The nmh people seem to locally reencode all data to UTF-8 to be
able to do something *almost* similar.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)