Subject: [webfinger] Auto-configuring Email Clients via WebFinger

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 15 Jul 2019 19:30:53 +0000

ART folks,

Several years ago when I was working on WebFinger, one of the use cases 
I presented was using WebFinger to facilitate auto-configuring email 
clients.  It was and still is a problem I deal with today.

For my own family, I have to manually configure several different 
clients on several different platforms for each member of the family.  
It's time consuming and really needs to be made simpler.

My wife also has to deal with this issue where she works, because her 
company, while just 100 or so employees, has offices in two different 
countries and the mail server settings an employee uses depends on his 
or her geographic location.  To use standard IETF protocols, it means a 
lot of manual provisioning.

I see the same sort of challenges with service providers. If one wants 
to have his or her own domain, but isn't technically savvy, they're in 
for a lot of "fun" trying to figure out the various settings. Seriously, 
no normal person should have to understand what SMTP or IMAP means, and 
definitely what port numbers or security settings to fill in.

While there has been a generic DNS-based method for email provision for 
a while, it doesn't work for me. It doesn't work for my wife's company, 
either. It also doesn't define everything one might need to define 
(e.g., required security settings or policies).

So we put together a very simple example to show how this might be done 
with WebFinger.  See the draft here:
https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00

The example in that document should make it clear how we intend this to 
work, though the detailed procedures and syntax are missing.  We first 
want to see what interest exists and if this general approach will work 
for everyone before getting into too much detail.

We'd love to have some dialog on this to see how we can address this 
problem of auto-configuring email clients.

Paul

---

From: Dave Cridland <[email-masked]>
Date: Thu, 18 Jul 2019 09:40:41 +0100

Obviously I'd prefer ACAP.

But also, please note the existence of RFC 6186. It's not widely deployed,
but if we were to open this can of worms, and not simply reuse
Thunderbird's autoconfig XML format (which, if I recall, is also supported
by various other Open Source MUAs), then I'd be keen to get SRV up and
running properly.

Dave.

On Mon, 15 Jul 2019 at 20:31, Paul E. Jones <paulej=
[email-masked]> wrote:

> ART folks,
>
> Several years ago when I was working on WebFinger, one of the use cases I
> presented was using WebFinger to facilitate auto-configuring email
> For my own family, I have to manually configure several different clients
> on several different platforms for each member of the family.  It's time
> consuming and really needs to be made simpler.
>
> countries and the mail server settings an employee uses depends on his or
> her geographic location.  To use standard IETF protocols, it means a lot of
> manual provisioning.
>
> I see the same sort of challenges with service providers. If one wants to
> have his or her own domain, but isn't technically savvy, they're in for a
> lot of "fun" trying to figure out the various settings. Seriously, no
> normal person should have to understand what SMTP or IMAP means, and
> While there has been a generic DNS-based method for email provision for a
> while, it doesn't work for me. It doesn't work for my wife's company,
> either. It also doesn't define everything one might need to define (e.g.,
> required security settings or policies).
>
> work, though the detailed procedures and syntax are missing.  We first want
> to see what interest exists and if this general approach will work for
> everyone before getting into too much detail.
>
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 18 Jul 2019 10:12:04 -0400

Dave,

RFC 6186 is the DNS-based one to which I referred below. Unfortunately, it doesn't allow setting various configuration options and wouldn't work at all for my wife's use case where employees use different mail servers based on the country in which they reside.

Paul

-------- Original Message --------
From: Dave Cridland <[email-masked]>
Sent: July 18, 2019 4:40:41 AM EDT
To: "Paul E. Jones" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [art] Auto-configuring Email Clients via WebFinger

Dave.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 18 Jul 2019 12:02:53 -0400

Responding to Paul's point about his wife needing a country specific
configuration, I think we need to think about this a bit differently.

This is one example of an application configuration problem and a service
discovery problem. What we need here is a scheme that is capable of
supporting the general case.

It makes no sense for any of the providers to change their existing schemes
unless it is to move to a scheme that is more powerful because it is more
general. Which means that at minimum it is supported by all the MUAs but
ideally means it is supported by multiple applications as well.

I have been thinking about this problem from the other side. I started what
is now the Mathematical Mesh trying to work out how to automatically
configure and maintain S/MIME and OpenPGP. While doing that, I suddenly
realized that I could add in the SMTP configuration as well. So once Alice
has configured her email service on one device, it is configured for them
all. She will get her SUBMIT/IMAP/POP3 settings at the same time that she
gets the S/MIME and OpenPGP keys to work on the device. I showed this to
Dave Clark who asked for SSH as well (which is a real pig to configure as
there is a bootstrap problem and a foul up may require someone to take a
plane trip to a server to fix it).

Being able to replicate the config across devices does not solve the
problem of initial acquisition of course. But the replication mechanism
should certainly use the same data structure (though translated to JSON
probably).

I have not thought about the Enterprise application of the Mesh in detail
yet because I have to get it working for individual users first. But I am
pretty sure that what we want here is single point onboarding (and
terminations).

So Alice joins example.com. She is issued a (new) company laptop and BYOB's
her mobile.

The onboarder checks the boxes for the corporate applications she is
authorized for, email, ssh, etc. and the group encryption services for the
teams she belongs to. The configulator then does all the rest.

All that remains is to connect up Alice and her devices to these
configurations. Which can be done in person via QR code or remotely via a
Base32 fingerprint. It presents a workfactor of at least 2^112 either way.

So from Alice's point of view, when she goes to the badge office to pick up
her badge, she scans a QR code with her phone and that is it - she is all
configured for email, chat, slack, slick, ssh, S/MIME and all the encrypted
data she needs from the cloud. If she is working on some really sensitive
stuff, her line manager or a VP might need to meet her in person to
authorize adding her to certain groups.

Termination should mean no more than unchecking the boxes.

The cryptography I am using was discovered by Torben Pedersen and Matt
Blaze in the mid 1990s. The reason it hasn't been applied was that it was
too hard to use and until Robert Snowden came along, people thought the
administrator of the key service in the cloud could be trusted. So I have
made it really easy to use and administrate even in the case that we have
separation of duties at the administrator level as well.

On Thu, Jul 18, 2019 at 10:12 AM Paul E. Jones <paulej=
[email-masked]> wrote:

> Dave,
>
> RFC 6186 is the DNS-based one to which I referred below. Unfortunately, it
> doesn't allow setting various configuration options and wouldn't work at
> all for my wife's use case where employees use different mail servers based
> on the country in which they reside.
>
> Paul
>
> ------------------------------
> *From:* Dave Cridland <[email-masked]>
> *Sent:* July 18, 2019 4:40:41 AM EDT
> *To:* "Paul E. Jones" <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject:* Re: [art] Auto-configuring Email Clients via WebFinger
>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 19 Jul 2019 09:20:50 +0100

> on the country in which they reside.

I'm not saying that additional information isn't needed, but it'd be nice
to be able to use SRV alongside.

I'd expect SRV to be used on every connection, whereas an auto
configuration file would be used less, potentially only on initial
provision.

The Thunderbird config would need to be adapted anyway; it's not easily
extensible, due to not using XML namespaces, for one thing.

Dave.