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

[Dave Cridland <[e-mail]>]

On Thu, 25 Jul 2019 at 05:09, Paul E. Jones <[e-mail]> wrote:

> Dave,
>
> We could bake that functionality into the autoconfig fomat, of course, but
> it feels like refreshing the config can happen at a different cadence to a
> SRV lookup, and besides, SRV works well.
>
>
> It works well for the simplest use case, but SRV records are really
> limited. I can name a three things SRV records cannot do today that are
> effectively render it useless for me:
>
> 1) It cannot tell the MUA the login ID to use (which may or may not be the
> email address) [or what credential mechanism to use]
>
> 2) It cannot specify (if I recall) that TLS must be used per corporate
> policy [this is important since both IMAP and mail submission generally
> offer STARTTLS as an option]
>
> 3) It doesn't allow specifying different servers for different users
>
>
And to re-iterate, I'm not suggesting we should forgo any kind of
autoconfiguration format in favour of SRV; I'm suggesting that having the
autoconfiguration format specify servers in the form of SRV would be useful.

That said, (2) is irrelevant on two counts :

a) You can use `imaps` SRV records just fine. They're published for
gmail.com, go have a look.

b) You can require TLS via STARTTLS within the protocols, and you'd have to
anyway, irrespective of what any autoconfiguration stipulated. Would you
consider stipulating a policy in an autoconfiguration file but not enforce
it in the services?

I shall now reiterate the arguments in favour of using SRV in this way,
because it seems I've not be clear enough.

First, some background:

I have written both email servers and an MUA, and for the latter, I wrote a
complete ACAP server to support autoconfiguration. ACAP is effectively
dead, but the experience has left me with some practical experience of how
to write autoconfiguration support in an MUA, and - more importantly - some
idea of how one might retrofit that support into an existing MUA.

The fact is that existing MUAs often have plenty of support for an
autoconfiguration step, but it exists during setup. So you can easily
specify authentication identifiers and so on at this point, but if the
autoconfiguration source changes, you're out of luck. This is unsurprising,
since with IMAP at least, a decent MUA has to do quite substantial effort
on first connect anyway in order to make decisions on the remote server's
mailbox layout. It might change with JMAP, but all existing MUAs are
currently IMAP-based, so in order to gain market traction, we need to aim
for this "auto setup" model.

The UX we're expecting is that, during Setup and "Add New Account", the
user enters an email address, and specifies credentials, and they're done -
the MUA will then autoconfigure the new account. There's lots of useful
information that can be sourced here from an autoconfiguration service.
Does the service support subaddressing? Is the authentication for the
submission service the same as the authentication for the IMAP service (so,
can I share credentials?). All of this is useful and vital information, and
I'm not going to advocate scrapping it (instead, though, please do look at
the ACAP dataset definitions for some thoughts and ideas - Randy Gellens
put a lot of good work into those).

During connection, there is more discovery. This includes locating the
hosts via DNS, discovering what TLS support is available, discovering what
authentication mechanisms are supported, and so on. There are pages of RFCs
already in existence for how these different processes work, and much of it
we - in the app layer - don't care about, because it's taken care of by DNS
libraries, TLS libraries, and SASL.

However, this second phase is routinely done - sometimes from scratch -
every time a connection is made. It's here I'm suggesting that existing
clients could easily be made to use SRV (with A/AAA fallback), and gain
some useful resilience, since this resolution occurs on every connection,
and not just on service configuration. Thanks to a lot of time spent in the
XMPP space (where most clients fully autoconfigure off the Jid), I'm
familiar with the benefits of SRV, and how easy or hard it is to do on most
platforms (these days, very easy, and with added DNSSEC, DTLS, and/or DOH).

There's also final part of discovery for an MUA. Here, after connection and
authentication, an MUA looks at server layout, features, and so on. It will
examine the mailbox layout. Is there a specific Drafts folder? What does
NAMESPACE return? Is BURL supported on the submission server? While these
are all, in principle, subject to change, doing so will deeply confuse many
MUAs, so it's best to consider these a one-off setup. It is, I think, this
that means that the pragmatic aim for this is to assume that whatever we
choose to design, the protocol will mostly be used for "auto setup", and
not a more continuous "auto configuration". Perhaps something else is the
forcing factor though - in any event, auto configuration sources are used
as one-off procedures during setup and not on as a part of connection,
startup, etc.

I hope this is clearer.

Dave.