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

John C Klensin <john-ietf@jck.com> Sun, 07 February 2016 23:13 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051861A8777; Sun, 7 Feb 2016 15:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaaaDbPwXmwI; Sun, 7 Feb 2016 15:13:39 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B34B1A8776; Sun, 7 Feb 2016 15:13:39 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aSYWO-000NxF-RJ; Sun, 07 Feb 2016 18:13:36 -0500
Date: Sun, 07 Feb 2016 18:13:31 -0500
From: John C Klensin <john-ietf@jck.com>
To: "Paul E. Jones" <paulej@packetizer.com>, apps-discuss@ietf.org, webfinger@ietf.org
Message-ID: <EE5D283AC957E10DA443AA15@JcK-HP8200.jck.com>
In-Reply-To: <em72874602-962e-43e1-90d2-497acacceffd@sydney>
References: <em72874602-962e-43e1-90d2-497acacceffd@sydney>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/itoMJGFjVKxtXYjf_dsRbF9UYGg>
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2016 23:13:44 -0000


--On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones"
<paulej@packetizer.com> wrote:

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

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.


> The idea is basically this:
>   * User enters paulej@example.com into the email client and
> email password
>   * Email client queries
> https://example.com/.well-known/webfinger?resource=acct%3Apaul
> ej%40example.com
>...

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