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

[Steffen Nurpmeso <[e-mail]>]

John Levine wrote in <[e-mail]>:
 |In article <[e-mail]> you write:
 |>>>> Putting passwords in cleartext in the request uri is ill advised \
 |>>>> because many servers keep logs of requests, caches, etc
 |>> 
 |>> Good point.
 |>> 
 |>> Plan A: if the server needs the user name and password, it sends back
 |>> a 401 response and the MUA sends them via RFC 7617 basic
 |>> authentication.  That seems largely backward compatible and invents a
 |>> minimum of new stuff.

Just yesterday i (currently implementing OAUTHBEARER for a BSD
Mail clone) thought how easy it would be if the OAUTHBEARER
request would have additional fields, like refresh-token etc.
A lot of things, including password changes etc., could be done in
there, protected via TLS, and managable by the mail protocol
itself (SMTP, POP3, IMAP), simply by putting value in data
following (on) the response code (line), instead of using a web
browser.

 |>> Plan B: do it as a POST like most web password entries.  I realize
 |>> this has backward compatibility issues with the current GET.
 |>
 |>What are the risks if the mail server and HTTP server are maintained \
 |>by different authorities?
 |
 |I suppose there might be administrative issues giving the web people
 |access to the mail passwords but that's hardly a new issue.  I see
 |that Apache has a module that does authentication via LDAP, which
 |would often be enough to solve that particular problem.
 |
 |One of the reasons Mozilla checks https://autoconfig.<domain>/ is exactly \
 |this:
 |it lets the mail department run a small special purpose web server \
 |separate from
 |the main web servers.

I will never understand where the benefit of turning mail clients
into fully blown browsers actually is.  I know in the Microsoft
world they have sophisticated integration of everything and a XML
protocol for that (several years ago i had contact with a person
from Microsoft who pointed me to this infrastructure, i was
impressed but since have forgotten most; it was not the one who
had a soapy bath on a stage).  This is actually hard to do with nc
/ telnet.  I mean, i am currently doing OAUTHBEARER: where is the
benefit (compared to kinit / kdestroy, which i have local control
of)?  I really have to go over that immense amount of code that
a browser is, and possibly the tab (even if i open an explicit
window) shares runtime with other tabs, which possibly have
sourced in megabytes of Javascript from who knows where, the most
weird seem to come in via reading newspapers.  I seem to know
Chromium at least optionally separates that better
(--site-per-process?).

Are you trying to enforce code reuse of anyway linked-in web kits,
otherwise i do not know.  If that is new code then it needs to be
written anyway.  Mail protocols offer plenty of possibilities to
send passwords, and could easily become extended with some plain
text commands.  It is all secured via TLS now, everywhere.
Extending usage of client certificates in favour of other
credentials is also interesting, moving away authentication from
the protocol to the transport, and reducing round trips.  And POP3
could need a SYNC for enforcing pending deletes to be fixated, and
i think a body only receive command would be nice too, also.

In the end i will have to implement actions aka "clickable" URLs
for a text-mode mail reader.

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