[apps-discuss] Mail client configuration via WebFinger
"Paul E. Jones" <paulej@packetizer.com> Sun, 07 February 2016 22:45 UTC
Return-Path: <paulej@packetizer.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 A7A6C1A6F39; Sun, 7 Feb 2016 14:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.707
X-Spam-Level:
X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 6uQQ57Vu_fsm; Sun, 7 Feb 2016 14:45:50 -0800 (PST)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABFF1A6F53; Sun, 7 Feb 2016 14:45:50 -0800 (PST)
Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u17MjmWm004471 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 17:45:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454885149; bh=0D/O2XStpPzyyu8iXnKIvygZtF0LYFXdic5dWjI6jYw=; h=From:To:Subject:Date:Reply-To; b=BC6HG5xsgdf+IIhq1Sxsuwtiyp4t3VctfnI/aYgf2m3UhxfFM/hyz1zY2QjDTrrQD bUzbouY07+3hxwac1zntGb+r9Y9qcf+iutlCqLat682LcwHldtQhar8wa8UG2XrUrA UVEESLDR0bP83fQ6uRFigX8SJgVS4kwHI+LfgXis=
From: "Paul E. Jones" <paulej@packetizer.com>
To: apps-discuss@ietf.org, webfinger@ietf.org
Date: Sun, 07 Feb 2016 22:46:17 +0000
Message-Id: <em72874602-962e-43e1-90d2-497acacceffd@sydney>
User-Agent: eM_Client/6.0.24316.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.14 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 17:45:49 -0500 (EST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/YExGD2ehpIntC_Ae2dI24YLEtkE>
Subject: [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
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 22:45:52 -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 paulej@example.com 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
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … Cyrus Daboo
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Dave Cridland
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] [webfinger] Mail client config… Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … Stephen Farrell
- Re: [apps-discuss] Mail client configuration via … Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- [apps-discuss] Mail client configuration via WebF… Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … Dave Cridland
- Re: [apps-discuss] Mail client configuration via … Claudio Allocchio
- Re: [apps-discuss] Mail client configuration via … Paul E. Jones
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- [apps-discuss] call blocking was Re: Mail client … t.petch
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … Claudio Allocchio
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … Eric Burger
- Re: [apps-discuss] Mail client configuration via … John C Klensin
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Arnt Gulbrandsen
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … Doug Royer
- Re: [apps-discuss] Mail client configuration via … John Levine
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker
- Re: [apps-discuss] Mail client configuration via … Phillip Hallam-Baker