[webfinger] 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: webfinger@ietfa.amsl.com
Delivered-To: webfinger@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 [] (cpe-098-122-181-215.nc.res.rr.com [] (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 []); Sun, 07 Feb 2016 17:45:49 -0500 (EST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/webfinger/AYg5hciip0XjMF9nQHalXgJpKoY>
Subject: [webfinger] Mail client configuration via WebFinger
X-BeenThere: webfinger@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <webfinger.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webfinger>, <mailto:webfinger-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webfinger/>
List-Post: <mailto:webfinger@ietf.org>
List-Help: <mailto:webfinger-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webfinger>, <mailto:webfinger-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Feb 2016 22:45:52 -0000


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

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 
  * Email client queries 
  * 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?