Subject: [apps-discuss] Mail client configuration via WebFinger

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 07 Feb 2016 22:46:17 +0000

Folks,

When we undertook the work on WebFinger, one of the use cases we had in
mind was the ability to allow an email client to automatically provision
itself.  What we wanted was for a user to be able to enter an email
address and password and for the email client to be able to determine
via WebFinger exactly what protocols to use, what ports, the name of the
SMTP server, and the name of the POP3 or IMAP server (or both).

We did not have that fully described and it conflicted with work that
others were doing on a more general aggregated services configuration
solution.  Namely, draft-daboo-aggregated-service-discovery-03.
Unfortunately, that work did not progress.

Still, I personally am frustrated with entering configuration data into
my mobile phone, tablets, desktop, and laptop every time I install a new
email client or get a new device.  It's only made worse when I have to
repeat the process for every member of the family.  So, I'd really like
a solution to this problem.

I don't think I'm alone in having this need (or having this
frustration).  Every hosting company has to articulate in detail how
customers go about configuring email for their hosted domains.  Many
(perhaps all) Universities do the same for students so they can access
email, with some going to great lengths to detail the steps needed to be
taken for every OS platform, popular clients, etc.

RFC 6186 exists and it addresses much of what I want, though client
support is lacking.  That begs the question of "why?"  Would defining
something that builds on WebFinger encourage client developers to add
support?

A couple of issues with RFC 6186 are:
   1) Information about services is exposed to the world and some prefer
      to not expose the names of servers, ports, protocols, etc.,
      especially internal ones to a company
   2) It does not allow for user-specific configuration: the entire
      domain is set to use the same information

Issue (2) is an issue with larger enterprises that associate users to
specific servers, as opposed to having some intelligent load balancing
mechanism.  However, there are smaller companies with distributed
offices and servers wherein some users are configured to use servers in
one geography and others in another geography.

Issue (2) also presents challenges with hosting providers.  DNS services
are independent of email services.  So, when a configuration change is
made to email, it has to be coordinated with the DNS side of the house.
If we use WebFinger, it does couple the web server with email, but the
DNS server never has to change.  Further, no additional change is
required to the WebFinger service operating at the root of the domain.
Thus, changes to the email configuration can happen in the back-end
without impact on users and can be used to reconfigure clients when
back-end services change.

I'd like to suggest we tackle this one narrow email provisioning problem
using WebFinger, but want to get feedback before spending time drafting
a formal proposal.

The idea is basically this:
  * User enters [email-masked] into the email client and email 
password
  * Email client queries 
https://example.com/.well-known/webfinger?resource=acct%3Apaulej%40example.com
  * The client would look for a link with a rel value of, say,
    "email-configuration".  This might look like this:
       {
         "rel" : "email-configuration",
         "href" : "https://email.example.com/user/paulej"
       }
  * The client would then query the above URI and receive a JSON document
    that we would define in this proposed spec that conveys the server
    configuration information, including server names for SMTP/IMAP/POP3,
    transport required (e.g., TCP or TLS), port numbers, login
    information (username "paulej" vs. email ID, possibly different
    passwords for each service, and a display name), etc.
  * The above resource would be password protected using the email ID and
    password assigned to the user, with the data conveyed over TLS

The client could be configured to re-fetch this information from
time-to-time, such as when the client starts, when stored credentials
are rejected, or on demand.

I'd like to hear your thoughts. Do others feel this could be a valuable
specification?  Are there client developers interested in helping to
solve this problem and willing to implement something here?

Paul

---

From: John C Klensin <[email-masked]>
Date: Sun, 07 Feb 2016 18:13:31 -0500

> When we undertook the work on WebFinger, one of the use cases
> we had in mind was the ability to allow an email client to
> automatically provision itself.  What we wanted was for a user
> to be able to enter an email address and password and for the
> email client to be able to determine via WebFinger exactly
> what protocols to use, what ports, the name of the SMTP
> server, and the name of the POP3 or IMAP server (or both).
>...
> Still, I personally am frustrated with entering configuration
> data into my mobile phone, tablets, desktop, and laptop every
> time I install a new email client or get a new device.  It's
> only made worse when I have to repeat the process for every
> member of the family.  So, I'd really like a solution to this
> problem.
>...
> RFC 6186 exists and it addresses much of what I want, though
> client support is lacking.  That begs the question of "why?"
> Would defining something that builds on WebFinger encourage
> client developers to add support?
> 
>    1) Information about services is exposed to the world and
> some prefer to not expose the names of servers, ports,
> protocols, etc., especially internal ones to a company
>    2) It does not allow for user-specific configuration: the
> entire domain is set to use the same information

Paul, I wonder whether it is time to revisit ACAP.  Its
predecessor, IMSP, was specifically designed for the types of
email cases you describe and it and/or ACAP were supported in a
reasonable range of mail clients.  Use of a 6186 mechanism to
locate an ACAP server that required authentication (and, where
appropriate, user identification so different information could
be delivered) before giving out information would seem to
mitigate the two issues identified above and use of an existing
protocol (DHCP might be another candidate but has, IMO, never
really taken off for application-layer client configuration and
has issues when used across WANs on the public Internet).  It
seems to me that upgrading something with which we have
significant experience might be a better alternative than
deciding Webfinger is the latest hammer with which to hit all
nails, especially nails that are not specifically web-related
and that such an approach might be more easily accepted.

> I'd like to suggest we tackle this one narrow email
> provisioning problem using WebFinger, but want to get feedback
> before spending time drafting a formal proposal.

See above.

>   * User enters [email-masked] into the email client and
> email password
>   * Email client queries
>...

Given all of the discussions we have been having about security
and privacy lately, if enterprises are, as you suggest,
sensitive about giving out information about how they are
configured, developing a new system that depends on email
addresses as identifiers and passwords for authentication seems
unwise at best.  Of course, ACAP would need examination and
probably upgrading for serious security as well, but...

>...
> I'd like to hear your thoughts. Do others feel this could be a
> valuable specification?  Are there client developers
> interested in helping to solve this problem and willing to
> implement something here?

Again, see above.  This isn't a strong pitch for ACAP, but is
just a thought about the possibility of a well-known tool with
which we have significant experience as an alternate starting
point.

     john

---

From: Eric Burger <[email-masked]>
Date: Sun, 7 Feb 2016 18:22:14 -0500

I would second the ACAP suggestion.

<snarky hat on>
Of course, we would need to translate ACAP from IMAP-friendly PDU’s to XML so we can translate that to JSON and then to YAML, so we can hit all of the PDU format buzzwords of the week.
</snarky hat off>

> On Feb 7, 2016, at 6:13 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 08 Feb 2016 00:45:20 +0000

John,

>has issues when used across WANs on the public Internet).  It

I'm not opposed to revisiting anything, but what will it take to see 
something actually deployed?  ACAP is not a trivial protocol and it's 
scope is broad.  I'm not even aware of any client implementations today 
and I've only seen some historical server implementations.  Nonetheless, 
I'm not opposed to any solution that people will actually get behind and 
make happen.

I would not recommend DHCP, because this is useful for hosting 
providers.  It's even not very useful for many enterprises, since not 
everyone is behind the corporate firewall.

>and that such an approach might be more easily accepted.

WebFinger is merely a defined place to go query via HTTPS to get a JSON 
object that contains pointers to whatever data we're seeking, along with 
a specific syntax for what those pointers look like.  Most of the world 
has infinitely more experience with an HTTP GET request than virtually 
anything else and processing a JSON object is a pretty trivial exercise. 
  WebFinger is used for a few applications, though in only one standard I 
know at present: OpenID Connect.  So, it's not quite the hammer you 
suggest it is.  However, it was designed specifically for discovering 
information like this, not knowing anything but a "subject" and a 
domain.  Given we're just talking about a couple of HTTP queries, I 
think the barrier to acceptance is going to be lower than most other 
solutions we might devise.

>probably upgrading for serious security as well, but...

I am willing to bet that the majority of independent domain operators, 
hosting providers, etc. will continue to use the username/password 
combination for a very long time.  That said, WebFinger (by virtue of 
the fact it is nothing more than an HTTPS query) can use any HTTP-based 
authentication scheme we want, including certificates, 
username/passwords, or whatever else we night propose.  I only suggest 
username/password, as I have yet to personally encounter use of anything 
else.  Whatever solution we devise that replaces the username/password, 
though, will be supported in HTTP and, therefore, WebFinger.

>which we have significant experience as an alternate starting

If ACAP was going to take off, I think it would have by now.  It did not 
and I doubt it will, but I'm absolutely not opposed if we were to 
somehow get a bunch of major client developers on board.  We'd need some 
server software that is well-supported, too.  We either have to resign 
to the fact that it's not going to solve the problem I think we should 
solve, that nobody cares to solve this problem, or that we need 
something simpler (e.g., a couple of HTTP queries to get config info).

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 8 Feb 2016 01:45:41 +0000

On 08/02/16 00:45, Paul E. Jones wrote:
> 
> If ACAP was going to take off, I think it would have by now.

That seems correct to me.

I think solving this problem in isolation would be worthwhile
if folks deployed a solution. (IOW, let's not generalise too
much.)

My own ask here is that the user not be expected to enter a
password until after whatever automatable checks can be done,
have been done. I really hate entering a password into a new
device before I've gotten any feedback that that device is not
going to send the password in clear over the network. And yes
that may be a minority concern, but it is still I think one
we ought not ignore, esp. as it should be quite possible to
encourage good behaviour here (it's as easy as encouraging
bad behaviour;-)

S.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 08 Feb 2016 01:56:28 +0000

Stephen,

>encourage good behaviour here (it's as easy as encouraging

In the case of WebFinger, all requests go over HTTPS only.  That said, I 
think your suggestion is a good one.  It's entirely possible that the 
authentication mechanism might not be password based and we won't know 
what that is until the query is made to the server hosting the 
configuration document.

Paul

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2016 03:00:10 -0000

>Paul, I wonder whether it is time to revisit ACAP. 

I see your point, but I think the answer is no.  The only ACAP
implementation I can find is one that Dave Cridland put on github in
2014, with a note saying it's work he did a decade earlier and it was
extremely difficult to implement.  There might be one in the
commercial Communigate MTA which wouldn't surprise me because Mr.
Communigate is the kind of guy who implements everything just to be
complete, but if it exists, it's proprietary.  I don't see any ACAP
client libraries other than one that looks like an abandoned Java
implementation from 2007.

>>   * User enters [email-masked] into the email client and email password
>>   * Email client queries

Looking at the success of RDAP, it seems to be a good idea to put
together pieces that people already have implemented.  RDAP is easy
because we already have https query libraries and JSON decoding
libraries, and I'd say this would be too. 

For this application, I'd put in an extra level of indirection with an
SRV or URI lookup, since many (most?) domains have their mail servers
far away from the web servers, and the SRV or URI would give you some
confidence that the server you were talking to would understand the
question you were asking.

I think the security issues are manageable.  An https request with
some sort of verification of the server certificate is more secure
than what nearly all MUAs do to verify their imap and pop servers now.

R's,
John

---

From: Dave Cridland <[email-masked]>
Date: Mon, 8 Feb 2016 08:16:02 +0000

On 8 February 2016 at 03:00, John Levine <[email-masked]> wrote:

> extremely difficult to implement.

There's also two CMU implementations, one in OCAML I think, and the other
in C++. The former one works, but has issues; the latter one never did I
think. I like to describe my implementation as the first working one.

FWIW, much of the difficulty in implementation was my lack of experience in
implementing publish/subscribe systems; I saw ACAP at the time as a kind of
hierarchical database with these weird CONTEXT things; these days I think
I'd implement it as a pub-sub system with a search function and probably
get along better.

In any case, ACAP has serious shortcomings - none of which are based on its
syntax or essential capability.

The primary issue is that the user on-boarding path has to start with an
ACAP username and hostname. This derails everything else.

> There might be one in the

The Communigate server is very limited in various interesting ways.

As for libraries, I wrote one (and an entire MUA) in Python some time back.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 8 Feb 2016 08:36:16 +0000

> which we have significant experience as an alternate starting

I tried implementing ACAP in a client and suggest forgetting about it. Such 
is my experience.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Mon, 8 Feb 2016 08:41:58 +0000

John,

I suspect that in this space, we run something of a risk of assuming the
question is which hammer to use rather than deciding what nail we have.

I'm mildly amused that criticisms of RFC 6186 are around exposure and
per-user configuration, since I've never seen either be a problem - but we
could, of course, declare these vital requirements. As a relative newcomer
to email, having only spent a couple of decades on the subject, even I am
well aware that there are as many niche requirements as grains of sand, and
no solution will ever encompass them all.

Instead, there are two extreme approaches we can usefully take, and there's
middle ground as well:

a) We prescribe a sane configuration.

The MUA, given an email address, can programmatically determine the servers
and authentication details without using the network.

b) We define a discovery solution.

The MUA uses network services to locate the servers and authentication
details.

An example of the middle-ground would be that we say servers should be able
to use an email address as an authentication identifier, and that all
services should use the same credentials, and that RFC 6186 records should
be used for discovery. I think that just by adding RFC 6186 records, the
vast majority of services will immediately work. (Many MUAs performing
ad-hoc discovery essentially synthesize 6186 records where the MX is
recognized, after all).

If you want more, you'll need to add more infrastructure, and the costs
here are quite high - especially since you need not only a new service at
the server end, but changes in every client.

There are, in existence, XCAP, ACAP, IMSP, and WebFinger in this space.

You could also usefully add XMPP into the mix - it's never had problems
with server discovery, the addresses and authorization identifiers it uses
are compatible with the vast majority of email addresses out there, and it
can provide a pub-sub based arbitrary data storage via its PEP
functionality which is well deployed.

Which one to use doesn't depend on syntax - though that might be, of
course, a tie-breaker - it depends on exactly what user-experience we want
to deliver.

Dave.

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 08 Feb 2016 09:54:56 -0500

Hi,

--On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" 
<[email-masked]> wrote:

> and I doubt it will, but I'm absolutely not opposed if we were to somehow
> get a bunch of major client developers on board.  We'd need some server
> software that is well-supported, too.  We either have to resign to the
> fact that it's not going to solve the problem I think we should solve,
> that nobody cares to solve this problem, or that we need something
> simpler (e.g., a couple of HTTP queries to get config info).

As one of the few people who implemented ACP/IMSP and all of that stack I 
have to say ACAP's time has been and gone. It was way too complicated to 
implement at the time and nothing has changed. The same could be said of 
the IETF's original calendaring server effort - CAP (RFC4324) - and in the 
end a number of people took a more pragmatic approach of building a 
calendaring protocol using existing technology (HTTP/WebDAV) resulting in 
CalDAV (RFC4791) that has (at least from my standpoint) been pretty 
successful. As it turns out I replaced use of IMSP/ACAP in my 
mail/calendar/contacts client with a simple WebDAV solution - storing 
preferences on my personal WebDAV share. For the most part that has worked 
well and is trivial to implement - most of the short comings could be fixed 
through use of more modern capabilities - likely a JSON solution using HTTP 
PATCH (RFC5789) and JSON patch/merge (RFC7396).

All that said, I do believe that the client account configuration setup is 
something that needs to be addressed. Indeed I tried to start such an 
effort at the IETF (via the AppsArea WG) and number of years ago. That was 
based on work done at the Calendaring and Scheduling Consortium (a group of 
users and vendors who recognised the need for a common configuration 
piece). At the time we titled that work "Aggregated Service Discovery" 
(which morphed into "Automated Service Configuration" (ASCOT) and the last 
draft for that (now expired) can be found here: 
<https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03>.

That draft used a webfinger-based lookup of a "service configuration 
document" that could list all relevant accounts a service provider had 
available for a user. At the time that work stalled partly because there 
was push back at the BoFs about the scope of the work, and because the 
stake holders ended up with other priorities that took precedence.

Paul and I had an exchange about this prior to him starting this thread, 
and he felt new work on this should be tightly focussed on just email. I 
personally believe we need to solve the problem for multiple services, not 
just one.

For email, calendaring and contacts we do currently have a light weight 
SRV-based account provisioning solution (RFC6186, RFC6764), which works on 
a per service basis (i.e., one set of requests for each account type). The 
calendaring/contacts piece of that has been deployed and used by a number 
of providers and clients. Unfortunately, the email piece has not - a number 
of major ISP do publish _imaps etc SRV records, but very few, if any, 
clients make use of that.

I also think that since the original ASCOT work, the world has started 
moving in a slightly different direction - specifically more towards a 
device management solution. With the wild propagation of mobile devices 
into the enterprise a number of device management solutions are now 
available that allow configuring of not only accounts, but provisioning of 
settings (password policy, VPN certs etc) and applications, documents etc,. 
These solutions are fairly wide spread in enterprise environments today. 
Less so in the "personal" device scenario.

Right now it is not clear to me that an ASCOT-like solution would be 
adopted given the use of device management. Before embarking on this we 
need to take a careful look at whether any solution is likely to be adopted 
(with the biggest burden likely being on clients/OS vendors to support it). 
Given the device management solutions already out there, I suspect there 
would be little value to m,ost of those folks to actually support ASCOT.

As an alternative, the IETF might want to take a more serious look at the 
overall device management solutions, and see if there might be scope for 
standards in that area. That would allow us to build off something that is 
already deployed (in a number of proprietary solutions) but is today 
solving the problem of account setup.

PS As it turns out I use a device management tool (one available from my 
employer - Apple) for managing all my family devices, which includes the 
ability to push profiles specific to my kids devices for locking down 
parental control settings and the like.

-- 
Cyrus Daboo

---

From: Eric Burger <[email-masked]>
Date: Mon, 8 Feb 2016 10:43:34 -0500

Perhaps an application-layer DHCP?

> On Feb 8, 2016, at 9:54 AM, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi,
> 
> --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" <[email-masked]> wrote:
> 
> As one of the few people who implemented ACP/IMSP and all of that stack I have to say ACAP's time has been and gone. It was way too complicated to implement at the time and nothing has changed. The same could be said of the IETF's original calendaring server effort - CAP (RFC4324) - and in the end a number of people took a more pragmatic approach of building a calendaring protocol using existing technology (HTTP/WebDAV) resulting in CalDAV (RFC4791) that has (at least from my standpoint) been pretty successful. As it turns out I replaced use of IMSP/ACAP in my mail/calendar/contacts client with a simple WebDAV solution - storing preferences on my personal WebDAV share. For the most part that has worked well and is trivial to implement - most of the short comings could be fixed through use of more modern capabilities - likely a JSON solution using HTTP PATCH (RFC5789) and JSON patch/merge (RFC7396).
> 
> All that said, I do believe that the client account configuration setup is something that needs to be addressed. Indeed I tried to start such an effort at the IETF (via the AppsArea WG) and number of years ago. That was based on work done at the Calendaring and Scheduling Consortium (a group of users and vendors who recognised the need for a common configuration piece). At the time we titled that work "Aggregated Service Discovery" (which morphed into "Automated Service Configuration" (ASCOT) and the last draft for that (now expired) can be found here: <https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03>.
> 
> That draft used a webfinger-based lookup of a "service configuration document" that could list all relevant accounts a service provider had available for a user. At the time that work stalled partly because there was push back at the BoFs about the scope of the work, and because the stake holders ended up with other priorities that took precedence.
> 
> Paul and I had an exchange about this prior to him starting this thread, and he felt new work on this should be tightly focussed on just email. I personally believe we need to solve the problem for multiple services, not just one.
> 
> For email, calendaring and contacts we do currently have a light weight SRV-based account provisioning solution (RFC6186, RFC6764), which works on a per service basis (i.e., one set of requests for each account type). The calendaring/contacts piece of that has been deployed and used by a number of providers and clients. Unfortunately, the email piece has not - a number of major ISP do publish _imaps etc SRV records, but very few, if any, clients make use of that.
> 
> I also think that since the original ASCOT work, the world has started moving in a slightly different direction - specifically more towards a device management solution. With the wild propagation of mobile devices into the enterprise a number of device management solutions are now available that allow configuring of not only accounts, but provisioning of settings (password policy, VPN certs etc) and applications, documents etc,. These solutions are fairly wide spread in enterprise environments today. Less so in the "personal" device scenario.
> 
> Right now it is not clear to me that an ASCOT-like solution would be adopted given the use of device management. Before embarking on this we need to take a careful look at whether any solution is likely to be adopted (with the biggest burden likely being on clients/OS vendors to support it). Given the device management solutions already out there, I suspect there would be little value to m,ost of those folks to actually support ASCOT.
> 
> As an alternative, the IETF might want to take a more serious look at the overall device management solutions, and see if there might be scope for standards in that area. That would allow us to build off something that is already deployed (in a number of proprietary solutions) but is today solving the problem of account setup.
> 
> PS As it turns out I use a device management tool (one available from my employer - Apple) for managing all my family devices, which includes the ability to push profiles specific to my kids devices for locking down parental control settings and the like.
> 
> --
> Cyrus Daboo
>

---

From: Claudio Allocchio <[email-masked]>
Date: Mon, 8 Feb 2016 17:38:28 +0100 (CET)

> Perhaps an application-layer DHCP?

... or something like the "autoconfig tool" used for eduroam wireless 
service (CAT - Configuration Assistant Tool) ?

https://cat.eduroam.org/?lang=it

it detects which device you are using, you select where you "belong to" 
(which provider/organization/...) and you get your correct configuration 
pushed down to the device...

>> PS As it turns out I use a device management tool (one available from my employer - Apple) for managing all my family devices, which includes the ability to push profiles specific to my kids devic…

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

               http://www.cert.garr.it/pgp/garr-cert-pgp-keys

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 08 Feb 2016 19:00:16 +0000

Cyrus,

>need to take a careful look at whether any solution is likely to be 
>adopted (with the biggest burden likely being on clients/OS vendors to 
>support it). Given the device management solutions already out there, I 
>suspect there would be little value to m,ost of those folks to actually 
>support ASCOT.

I completely agree that we should try to get a sense of the likelihood 
of success.

Within the enterprise -- especially the larger ones -- you are entirely 
correct that device management systems provide a good solution for most 
of the employees.   However, I interact with a lot of smaller businesses 
that do not use such systems.  Many of them have a web hosting company 
host their domains and do not have IT staff to help them on a daily 
basis.  I'm skeptical that a device management system would help that 
class of users, so arming hosting providers with tools they can deploy 
to their customers would help, I think.

There are also a number of individuals who have their own domains, many 
hosted on the many, many web hosting providers out there.  Same issue 
for most of them.

So, I think there is a market need.  I suspect if we were to create a 
solution, hosting providers were to deploy it, and client developers 
were to support it, people would use it.  However, that's a string of 
"ifs".  I think it starts with the client developers.  If there were 
people interested to solve the problem, I think the rest falls into 
place.

All that said, if client developers are uninterested, there's little 
point working to solve this problem.

>As an alternative, the IETF might want to take a more serious look at 
>the overall device management solutions, and see if there might be 
>scope for standards in that area. That would allow us to build off 
>something that is already deployed (in a number of proprietary 
>solutions) but is today solving the problem of account setup.

I think your suggestion is worthwhile independent of whether we solve 
the problem for smaller businesses and individual users of hosted 
domains.  It would good if the same solution or would address those 
needs of smaller businesses and individuals, but if it didn't, it's 
still a step forward.

Paul

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Feb 2016 14:26:28 -0500

Cyrus,

Thanks for stepping in on this.  A few comments and
clarifications below...

--On Monday, February 08, 2016 09:54 -0500 Cyrus Daboo
<[email-masked]> wrote:

>> It did not and I doubt it will, but I'm absolutely not
>> opposed if we were to somehow get a bunch of major client
>> developers on board.  We'd need some server software that is
>> well-supported, too.  We either have to resign to the fact
>> that it's not going to solve the problem I think we should
>> solve, that nobody cares to solve this problem, or that we
>> need something simpler (e.g., a couple of HTTP queries to get
>> config info).
> 
> As one of the few people who implemented ACP/IMSP and all of
> that stack I have to say ACAP's time has been and gone. It was
> way too complicated to implement at the time and nothing has
> changed.
>...

While I was (deliberately) vague, my "look at ACAP" comment was
not intended as "go adopt ACAP".  My own view of ACAP comes from
a different perspective than Cyrus's, but is consistent with the
above and some of his other remarks: it seemed to me to be far
too "flexible" and complicated for the actual requirements and
generally to suffer from a bad case of second system effect.  

However, I agree with Cyrus that it would be helpful to look at
configuration for some class of applications that we can
configure in a reasonable way --not just email but also not
"everything".  I mentioned ACAP because I think looking at it
from a "what works, what is needed, and what is unnecessary or
harmful decoration" perspective might provide a better
real-world starting point than, to paraphrase another comment,
starting with Webfinger and whatever buzzwords and formats are
in fad at the moment.   Perhaps Webfinger (with or without
ASCOT) or, as Cyrus suggested in passing, WebDAV, will turn out
to be the right answer (I really don't have an opinion) but I
think there would still be a lot to learn from the ACAP
experience... starting from "no more complex and option-laden
than absolutely necessary".

>...
> For email, calendaring and contacts we do currently have a
> light weight SRV-based account provisioning solution (RFC6186,
> RFC6764), which works on a per service basis (i.e., one set of
> requests for each account type). The calendaring/contacts
> piece of that has been deployed and used by a number of
> providers and clients. Unfortunately, the email piece has not
> - a number of major ISP do publish _imaps etc SRV records, but
> very few, if any, clients make use of that.

And, as Paul and others have pointed out, SRV-based approaches
are not particularly well-suited for environments in which the
configuration information itself may raise privacy issues or in
which per-user or per-device, rather than per-domain,
configurations may be needed.  SRV approaches might, however, be
used to bootstrap the right configuration tools even if they are
not those tools.

>...
> As an alternative, the IETF might want to take a more serious
> look at the overall device management solutions, and see if
> there might be scope for standards in that area. That would
> allow us to build off something that is already deployed (in a
> number of proprietary solutions) but is today solving the
> problem of account setup.

Agreed for either device management or potentially per-user
application management, but I'm also suggesting that part of
such an effort should be to examine the many approaches we have
adopted or tried to adopt to this general class of problems and
see what we can learn from them, at least to the extent of
avoiding repeating those mistakes.

Of course, if there are a collection of almost-good-enough
proprietary solutions out there, the two other questions that
should be asked are (i) whether, and how, the IETF can actually
add value to the situation and (ii) whether those vendors would
shift to a standardized, interoperable, mechanism rather than
continuing to push their proprietary ones with whatever
advantages keeping them proprietary bring.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Feb 2016 14:49:17 -0500

> Perhaps an application-layer DHCP?

Obvious, but another example of why I think we need to look back
and do some examination.  Something built on a DHCP-like model
(or, I suspect, on the sort of device identification model
Claudio mentioned) probably means exposing the device and/or its
location in all sorts of ways.  That is precisely what assorted
privacy efforts are trying to avoid.  But Dave suggests (I think
probably correctly) that one of the fatal flaws with ACAP is
that it requires a username and hostname.  That has other
problems, but can also lead to a different set of privacy issues
(including the potential for linking various credentials and
device information).  One can work around those issues using
HTTPS with verifiable client certs, but that just changes the
problem in other ways.  Or one can move to a layered solution,
hoping that opportunistic encryption based on traditionally
largely-unverified server credentials will adequately hide the
private stuff.

Better be sure we know what problem we are trying to solve.

    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2016 14:56:47 -0500

> used to bootstrap the right configuration tools even if they are

We keep going round in circles in these arguments. We really need some
authoritative source for the Internet architecture.

I agree with John's conclusion but with an older argument. Namely that
people have tried to use DNS for account type information since
RFC1035 was published and none have been successful.

In my view, the DNS is the Infrastructure that maps DNS names onto
current descriptions of services. So extending the use of the DNS for
DANE like purposes with respect to TLS is certainly within scope of
the DNS. Attempting to use the DNS for account based information has
consistently failed.

John's raising of the privacy argument seems to me to be the capstone
of this argument because all of the reasons people have given me for
not making information in LDAP or X.500 directories publicly
accessible are essentially privacy arguments. The concern that head
hunters would use the company directory to cold call people is a form
of privacy argument.

The reason I thought I would flag this is that if we are going to
build such an infrastructure, we should probably start from the idea
that privacy is a paramount concern and plan accordingly.

I do have some code that might be relevant to this problem in the
Mathematical Mesh but it is not a problem that I have considered
except in the abstract so far.

It seems to me that any mechanism that would allow contact information
to be shared would have to leverage two separate principals

1) Social media style 'friend' links
2) Progressive disclosure (aka kimono protocol).

My email information is online but not my telephone number. I really,
really want to get rid of the telephone number ASAP because I am
getting half a dozen spam calls a day now. Even with nomorobo in
place, each spam call still causes one ring and that is starting to be
a hassle.

So if we are looking to support features like calendaring, instant
messaging, VOIP, etc. We really need to have some sort of concept of a
hierarchy of introductions. Something like:

1) Can send me a contact request
2) Can send me an ordinary length text email
3) Can send me large emails and emails with potentially dangerous attachments.
4) Can request voice / video / chat
5) Can put items onto my calendar
6) Can interrupt my work with notifications

The last of course is something that I am going to probably expect to
be paid for.

As I keep saying, there is no problem in providing a cryptographic
infrastructure that supports all these needs in end-to-end security
and in multilayer security models. Give us a clear description of the
requirements, and the crypto is not too hard. The hard part is being
clear about the requirements.

> avoiding repeating those mistakes.

+1

> advantages keeping them proprietary bring.

I think there is a very clear area where IETF can add value, we can
provide a mechanism that puts the user in control rather than being
designed to bind them to one proprietary service provider.

In theory I can use proprietary mechanisms to transfer my email
settings from one device to another. In practice these only work for
the limited set of devices a vendor supports and these in turn tend to
be allowing me to move to the hardware/software of the provider.

There is also a real problem with platform providers who

1) Force me to perform regular software updates
2) Think nothing of trashing my personal settings during an update.

Right now I have an iPhone whining because it hasn't been connected to
the iCloud account I don't use and don't want. I have a Windows
desktop that shuts itself off after 10 minutes despite my repeated
disabling of the power saver mode because one of its functions is as a
server. I also have a large collection of bookmarks that I collected
using the Google Toolbar that I can't properly access from Google
Chrome without the use of a third party plug in that almost certainly
will add malware in a future revision.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2016 15:09:53 -0500

On Mon, Feb 8, 2016 at 2:49 PM, John C Klensin <[email-masked]> wrote:
> that it requires a username and hostname.

I may have a solution.

There is another problem I see with ACAP, like the typical Internet
application of its day, it starts with a protocol description and then
it tries to add security.

The Mathematical Mesh is an infrastructure I have designed, build and
demonstrated:

https://www.youtube.com/watch?v=6vM6vxtQzGg
http://www.prismproof.org/

[Yes, there are Internet drafts and the source is MIT license]

The approach in the Mesh is the reverse of the ACAP approach. It was
originally designed as a mechasnism to allow me to easily move public
and private key material around to allow a single user to control
multiple devices connected to a 'profile'. It was designed to support
S/MIME, OpenPGP, SSH, TLS and the like.

It was only after I was writing code to store S/MIME keys in the Mesh
that I suddenly realized that I could just as easily store all the
email configuration data in the Mesh.

The Mesh itself is configured as an untrusted service. In the
demonstration, the server for the Mesh is actually located inside the
dalek you can see in the background. The point being that if you use
strong end-to-end security, you don't need to worry about where your
endpoints lie.

Now one major caveat here is that privacy is a much harder problem
than email encryption and not the problem I set out to solve. At the
moment the Mesh protocols deliberately leave information accessible
that I would like to obfusticate later on because trying to debug a
system in which every identifier is anonymized is probably going to be
a #@($%*#@$(%!!!

> That has other

+1

If someone can give me a clear description of 'the' problem, solving
it is easy. What I am trying to do right now is to provide a solution
to the problem we claimed to have solved in 1998/1999 but hadn't.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2016 15:22:54 -0500

> encourage good behaviour here (it's as easy as encouraging

PLEASE

No more password based protocols.

Passwords are not the way to solve this problem except in the
hopefully very rare case of catastrophe recovery.

'We believe in strong cryptography and reviewed code'

The problem with passwords is that a human cannot be expected to
remember any piece of information that is secure enough to be
unguessable.

Remember when the requirement to have mixed case and a punctuation
mark in a password came in? That was in response to Crack published in
1991 which was a dictionary based search running on machines that
could do 35 password tests a second. Four years ago, someone lashed
together 20 GPU cards discarded by the bitcoin miners and built a
machine that could do 350 billion tests a second. It isn't a
dictionary attack and so the password restrictions actually reduce the
search space and make the problem easier.

Passwords are done, they are dead.

If we want to have an application configuration protocol it should be
capable of configuring cryptographic authentication credentials. Now
we might optionally encrypt those credentials with a PIN, but that is
a local security matter, not something that travels over the network.

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2016 01:12:13 -0000

>of the employees.

There are plenty of people using mail systems on networks not under
the same management as the mail server.  I'd think that most
smartphone users would be in that situation.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 8 Feb 2016 20:14:54 -0500

> smartphone users would be in that situation.

BYOD is now the name of the game.

And you don't have an email app configuration solution unless you can
configure S/MIME and OpenPGP.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 9 Feb 2016 08:32:28 +0000

> configure S/MIME and OpenPGP.

Wait, what? Solving the problem for the 99.995% who don't use PGP isn't 
worthwhile?

Arnt

---

From: t.petch <[email-masked]>
Date: Tue, 9 Feb 2016 10:49:22 +0000

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Sent: Monday, February 08, 2016 7:56 PM
> > <[email-masked]> wrote:
<snip>
> place, each spam call still causes one ring and that is starting to be

Phillip

I have a CallBlocker which suppresses all rings, and the difference it
makes is magic.  The phone still logs a call, giving time, number and a
flashing red light which I notice only when I am willing to be
interrrupted.  The box is American so I imagine it will work with half
the world's networks.

The weakness is the lack of data entry, not even a web interface, so I
cannot add numbers to its directory except by catching a call and
pressing a button while it is in progress so I am still hassled by those
that ring when I am out and fill up my VoiceMail.

And, crooks are smarter than phone companies so they are now using
forged source addresses - no RPF for the phone - to bypass the blocks so
the effectiveness of the blocking is diminishing.  Thank heavens for
e-mail (even if I have to configure it:-).

Tom Petch

<snip>

---

From: Eric Burger <[email-masked]>
Date: Tue, 9 Feb 2016 06:45:22 -0500

Would I not accept an automatic mail configuration protocol that does not configure S/MIME or PGP? No.

Would I not try really, really hard to create an automatic mail configuration protocol that does configure S/MIME or PGP? ***ABSOLUTELY***

In 2016, it would be criminal to not provide a solution for the 99.995% of users who cannot spell PGP or S/MIME. I agree with PHB’s sentiment here: we have to try, and we have to try really hard, to make the security configuration a major purpose for the effort.

For that matter, one can argue that without security configuration, the market has passed us by. My current experience is with MacOS. If you use Gmail, iCloud mail, Yahoo! mail, AOL, or Exchange, your mail configuration magically happens. If you are using a raw IMAP or POP3 server, more especially if you are using a real submit server at a different address, too bad for you. However, I’ll bet 99.995% of typical users are using one of the big providers and would ask “why is the IETF working on how to configure Gmail? It just works already. The IETF is solving yesterday’s problems.” If we say, “because you get security,” 99;995% of people would say, “the IETF is great!”

> On Feb 9, 2016, at 3:32 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> Wait, what? Solving the problem for the 99.995% who don't use PGP isn't worthwhile?
> 
> Arnt
>

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 9 Feb 2016 13:49:04 +0100 (CET)

On Tue, 9 Feb 2016, Eric Burger wrote:

> For that matter, one can argue that without security configuration, the 
> market has passed us by. My current experience is with MacOS. If you use 
> Gmail, iCloud mail, Yahoo! mail, AOL, or Exchange, your mail 
> configuration magically happens. If you are using a raw IMAP or POP3 
> server, more especially if you are using a real submit server at a 
> different address, too bad for you. However, I’ll bet 99.995% of typical 
> users are using one of the big providers and would ask “why is the IETF 
> working on how to configure Gmail? It just works already. The IETF is 
> solving yesterday’s problems.” If we say, “because you get security,” 
> 99;995% of people would say, “the IETF is great!”

+1 !

---

From: Doug Royer <[email-masked]>
Date: Tue, 9 Feb 2016 14:38:58 -0700

Maybe the there are two separate issues.

 - How to containerize and standardize passing of configuration
information from service provider to consumer. Maybe a MIME type with
sub-registration of protocol (email, calendar, VOIP, ...), and mandating
it be sent encrypted.

 - How to transport that information across whatever transport is
available. SRV record to MIME blob URL, sent in email, HTTP/FTP
download, ...

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2016 02:59:35 -0000

> - How to containerize and standardize passing of configuration information ...

> - How to transport that information across whatever transport is available.

I'm a big fan of not inventing stuff if we don't have to.

First I'd like to understand why mail clients don't implement RFC
6186.  It seems to me that for a whole lot of mail users, it provides
all the configuration info they need.  I realize there are mail
systems where the e-mail address isn't the user ID, and systems where
users in a single domain are assigned to different servers, but there
sure are a lot of systems including the very largest where that's not
a problem.

If the answer is anything other than inertia, that might give us some
guidance as to what a better design would look like.  If, as I
suspect, the answer really is inertia, a new design is unlikely to be
any more successful.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 10 Feb 2016 09:12:15 +0000

John Levine writes:
> 6186.

a) Client support for SRV is oddly poor, to the point where I've seen XMPP 
clients not do SRV lookups. b) There's another way that achieves better 
results for comparable effort (accessing a mozilla-maintained database). c) 
... I'm sure there's more.

Arnt

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Feb 2016 10:05:05 -0700

> sure are a lot of systems including the very largest where that's not

(1) I just checked GMAIL, YAHOO, AOL, HOTMAIL, and my ISP. Only GMAIL
seems to -mostly- provide the correct information.

Gmail SRV returns:

_submission._tcp.gmail.com. 86400 IN SRV 5 0 587 smtp.gmail.com.

Yet I have to use port 465 (not 587 in the SRV record). 587 simply fails
for me - I did not care why.

(2) Some ISP's want your email address in all lower case when
authenticating, others want it as you entered it. When I setup with my
isp, it asked what email address I wanted: I entered "DougRoyer", so
that is how I entered my account name. I have to use DougRoyer (and not
dougroyer@isp, DougRoyer@isp, or dougroyer) as the authentication name.
It took me an hour or so to figure that out.

Some accounts have nothing to do with the email address. Your
authentication is your phone number, account number, or some unrelated
string.

(3) Password type is not Not in 6186: Plain, Encrypted, Kerberos/GSSAPI,
NTLM, TLS-Certificate, or OAUTH. Some MUA's ask, users do not understand
the question.

(4) And with Kerberos most users have no clue how to setup their email.

(5) With TLS-Certificate, it fails, until they get their certificate, so
they don't push SRV records, they just provide the user with the
connection information.

(6) Different IMAP/POP and submission servers per user, as in:

I want my east coast users to use imap.east.example.com, and the west
coast users to use imap.west.example.com.

Engineering uses IMAP on UNIX, sales uses POP3 as they use an exchange
server because it works with their sales tools.

Load balancing, some users use smtp.host-a, others smtp.host-b...

So they do not push any SRV records.

> suspect, the answer really is inertia, a new design is unlikely to be

It looks like lack of inertia and confusion.

I helped a friend with an ISP that offers POP3 free. If you want IMAP,
you pay extra.

That ISP considers the 'preferred' service IMAP.
You can connect with IMAP, but get no email if you expected the free
service.

--

---

From: Eric Burger <[email-masked]>
Date: Wed, 10 Feb 2016 12:42:53 -0500

I am pleasantly surprised - you have an ISP that respects the RFC that states the user part *is* case sensitive. Most ignore that. Oh well.

> On Feb 10, 2016, at 12:05 PM, Doug Royer <[email-masked]> wrote:
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 10 Feb 2016 13:07:01 -0500

--On Wednesday, February 10, 2016 10:05 -0700 Doug Royer
<[email-masked]> wrote:

>...
> (1) I just checked GMAIL, YAHOO, AOL, HOTMAIL, and my ISP.
> Only GMAIL seems to -mostly- provide the correct information.
> 
> Gmail SRV returns:
> 
> Yet I have to use port 465 (not 587 in the SRV record). 587
> simply fails for me - I did not care why.
> 
> authenticating, others want it as you entered it. When I setup
> with my isp, it asked what email address I wanted: I entered
> "DougRoyer", so that is how I entered my account name. I have
>...

Doug,

I learned a few things from your note, most of which, sadly, I
had already guessed at.

One is a reminder about where at least some of the complexity of
ACAP comes from (I think there is more than is necessary, but
that is another question).  Unless we are going to change a lot
of habits, conventions, and operational decisions that make
perfectly good sense in their own environments, we need a system
that is flexible enough to deliver configuration information to
different users (and their MUAs/ Clients) based on location
(sometimes "normal", sometimes "right now"), on user or client
identifier (which may or may not be connected to a mailbox name
in an obvious way), on properties of the client software, etc.
In some, probably most, cases, the server from which the
information comes will make the decisions and send out only the
specific information needed to configure the client but there
will be cases where it would be better to send out information
that gives the client choices that only it can evaluate.  For
some situations, it will need to receive the request and send
the response in encrypted form; for others that may be
unnecessary, undesirable, or worse.  To the extent to which the
location or client software are involved in the decision about
what to send out, whatever is done will have to work despite our
best efforts to obscure the information in the interest of
privacy, leading to some of the use cases for sending out a lot
of information and letting the client choose.

Now, while I still think ACAP is too complex and probably
includes fundamental design flaws, the above fairly strongly
suggests that a DNS record or two, or even invocation of
WebFinger or something else popular, might be part of the
solution, but are, at best, only a small part... and might
encourage sloppy thinking that fails to cover a lot of important
cases.  If we do want to include those cases, this isn't going
to be an easy problem, and that brings us back to John Levine's
question about inertia (among others).

    john

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2016 18:18:22 -0000

>for me - I did not care why.

I just tried it, port 587 and STARTTLS works fine.  Perhaps your MUA
doesn't know that port 587 needs STARTTLS rather than doing the TLS at
connection time, a bug that should be easy to fix.  Gmail does require
that you create a separate per-app password on their web site for
every device that logs into gmail, but automating that seems rather
beyond what we're looking at here.

Yahoo, Hotmail, and AOL also all have single servers per service (pop,
imap, submit) with the address as the username, so RFC 6186 would work
if they published the SRV records.  So do Comcast and Time-Warner and
Verizon and AT&T.  Comcast even publishes the SRV records.

>authenticating, others want it as you entered it.

Really?  Can't ever remember that being a problem.  In any event, you'd
have exactly the same problem with webfinger and anything else if they
want to be picky about upper/lower case.

>authentication is your phone number, account number, or some unrelated

Yes, I know.  This is not a 100% solution, nothing is.  The question
is whether it is a 95% solution that's worth encouraging people to
implement.

>NTLM, TLS-Certificate, or OAUTH. Some MUA's ask, users do not understand

Then the MUAs are broken, since the MSA tells them what kind of auth
they can use, at least amoung plain, encrypted, and GSSAPI.  If we
invented something new, they'd probably get that wrong, too.

>coast users to use imap.west.example.com.

Yes, for the umpteenth time, RFC 6186 is not a 100% solution.  But it
sure seems like a 95% solution to me.

R's,
John

>You can connect with IMAP, but get no email if you expected the free

We definitely can't cure stupid.

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2016 18:24:07 -0000

>I am pleasantly surprised - you have an ISP that respects the RFC that states the user
>part *is* case sensitive. Most ignore that. Oh well.

No, that's not what the RFC says.  It says it's up to the mail system
to decide what the local part means.  It's perfectly valid for a mail
system to treat ASCII case variants of the local part of its mailboxes
as equivalent, and I have to say it's been a long time since I've seen
one that doesn't.

I wonder what system Doug is using that cares, and how old its code is.

R;s,
John

PS: Where it gets a lot hairier is with optional characters like dots
in gmail names, optional suffixes like user+ext@domain or
user-ext@domain, and the whole world of EAI and UTF-8 where I am sure
there are all sorts of things that are obviously equivalent in some
languages and not in others.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 10 Feb 2016 18:34:22 +0000

> languages and not in others.

The EAI situation is better than you probably think, mostly because the 
unicode committee does very good work and the rest of the world is lucky 
that it does.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 10 Feb 2016 18:36:54 +0000

John Levine writes:
> Gmail does require

That's not entirely true. If you don't do that, you're at mercy of per-user 
configuration, but my account worked fine without any changes that I can 
remember.

> want to be picky about upper/lower case.

IIRC Thunderbird used to probe about 140 combinations of things 
just-localpart or whole-thing, lower-case vs exact, various default names, 
ports 25 vs 587. All very boring really.

Arnt

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Feb 2016 11:57:02 -0700

> sure seems like a 95% solution to me.

I know, I just wanted to list the issues found over the last few years.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Feb 2016 12:10:49 -0700

> We definitely can't cure stupid.

Different issue. They provide 2 services POP-free and IMAP-pay, and
DNS/SRV has no way to do smart 'preferred'. (per user again)

If they make IMAP preferred, then their free users get no email.

If they make POP preferred, then their pay users get told to use POP and
not the IMAP they pay for.

RFC 6186:

section 3.4,  " ...When an MUA supports both IMAP and POP3, it SHOULD
retrieve records for both services and then use the service with the
lowest priority value. ..."

  and first paragraph on page 2

"...  The priority field of the SRV record can also be used to indicate
a preference for one message store access protocol over another. ...

For users that upgrade, would have to manually update their MUA.

I would hope that a configuration standard would allow for update data
that does not tell them to use the wrong store/port.

They choose the option that makes their per-users happy.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Feb 2016 12:29:01 -0700

> beyond what we're looking at here.

More oddities, IPv6 vs IPv4.

From Home ISP (defaults to IPv6 after 2 minute timeout, it tries IPv4 -
really ODD results as it still fails):
  telnet smtp.gmail.com 587
  Trying 2607:f8b0:400e:c04::6d... (wait 2 minutes - time out)
  Trying 74.125.28.108... (wait 2 minutes - time out)
  Trying 74.125.28.109... (wait 2 minutes - time out)
  ...

yet, if I telnet directly using IPv4:

  telnet -4 smtp.gmail.com 587
  Trying 74.125.28.108...   (note this is the same IPv4 as above)
  Connected to gmail-smtp-msa.l.google.com.

Makes me think (and unrelated). Are their ISPs that only provide IPv4 vs
IPv6 services? The SRV records point to a host name, not an IP address.

WORKS from Texas: So I ssh'd into a Texas system that I manage and -
everything works, both IPv4 and IPv6 on port 587.

traceroute IPv4 fails for me to port 587. Must be my ISP oddities.
I think my ISP is busted.

--

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2016 20:17:01 -0000

>unicode committee does very good work and the rest of the world is lucky 

Oh, I agree.  I was thinking of stuff like accented vowels which in
French are usually considered close enough to the unaccented versions
that you'd consider accented and unaccented versions to be the same
name, as opposed to Scandinavian languages where the various forms of
"o" are entirely different letters.

There's also traditional and simplified Chinese characters which are
equivalent except when they aren't.

This has been an enormous can of worms for domain names, trying to
figure out when names are close enough to be more or less equivalent
and if so what to do about it.  With EAI every MTA operator can do
what makes sense in their situation but I'm guessing there will be as
little consistency there as there is about what you do with dots and
plus signs in ASCII local parts.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Feb 2016 21:21:21 +0000 (UTC)

OK, so being offline most of today and about to get on the plane. I see two separate requirements
1) Email service discovery2) Email account config
The first I think should be dealt with using the SRV plus prefixed TXT record pattern that is already established for the purpose in IETF.
The issue here is that we need more than just discovery of the IP address of a host that can serve us. The existing spec is fine for setting the inbound and outbound hosts. But it doesn't have the TLS information I would want. [And no, I do not want to use a DANE hack for reasons I have set out at length in the past.]
One of the security holes in the current email config is that we have a lot of SMTP auto protocols, only some of which are widely supported only some of which have code points registered and all of which are vulnerable to downgrade attacks. It is an ugly mess that I don't plan to propose a fix for right now. But what I do want to do is to define a clean interface to the existing mess.

Email account config is more than just service discovery. I want to be able to configure keys for Endy-mail which at minimum includes S/MIME and OpenPGP and possibly a future S/PGP. So when Alice is using her email client from her laptop and her phone and her tablet, she needs all of them to be automatically provisioned with the necessary keys.
That is what I mean by account configuration and that is what the Mathematical Mesh was originally designed to address. Late in the implementation, I realized that I could also just configure the email account network settings. But that is supplemental to, not a replacement for SRV+TXT config.
The reason for this is that the Mesh profile manager has to find configuration info from somewhere. Right now it will pull them out of a configured email app. But I would also like to be able for the profile manager to pull that info directly. 

Looking at this, I don't see WebFinger as being the answer to either part. We have an IETF architecture for Service discovery, it uses SRV + TXT and there is a quite comprehensive documentation of that in RFCs. I did try to work out if I could use WebFinger for the same uses as I support in the Mesh and I don't think it helps. 
So very committed to helping solve this. I don't think WebFinger is the approach to use.

Sent from Outlook Mobile

On Tue, Feb 9, 2016 at 1:39 PM -0800, "Doug Royer" <[email-masked]> wrote:

--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Feb 2016 21:46:34 +0000 (UTC)

The complexity of the Netscape protocol from 1997 is only partly due to the complexity of the problem. 
The much bigger problem is the architecture. An email account config is ultimately going to end up in some sort of file/registry setting. And so it is going to be a collection of structured data. 
The way we go about that problem today is to write an XML schema or a description of a JSON structure (which is of course a schema but we don't call it that as it frightens the horses). Then we poke or pull data blobs that contain data structures according to the schema. All the complexity of the problem goes into the schema design. And so do any extensions to meet future needs, proprietary purposes, etc. etc.
The Netscape protocol isn't written that way. The complexity that these days we contain in the schema has escaped into the network protocol which is loosely speaking a mechanism for editing the data structure by sending diffs for each branch.
So, I think it is a distraction and not very helpful.

The Mesh follows the schema approach but with layers of cryptography to protect confidentiality and integrity. There may be common network config elements that should be shared by email and xmpp config for example. In fact I am sure there are or we are doing something wrong.