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

["John Levine" <[e-mail]>]

I think we agree more than we disagree.  I totally agree that only 
one-time setup when you add a new account to your MUA makes sense, not 
every time it starts up.

But in this application I still don't see the benefit of an extra level of 
indirection via SRV.  Whether we start with ACAP or (more likely) with the 
Mozilla XML format, you've already got the indirection.  Large mail 
systems like Gmail and Hotmail/Outlook get redundancy now via multiple A 
and AAAA records.

R's,
John

On Thu, 25 Jul 2019, Dave Cridland wrote:

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