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

Eric Burger <> Sun, 07 February 2016 23:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC6771A8998 for <>; Sun, 7 Feb 2016 15:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TiCCqMiTNwhY for <>; Sun, 7 Feb 2016 15:22:20 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 969111A8997 for <>; Sun, 7 Feb 2016 15:22:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Ylq/PE7nkW3IFhNaYI/ZJfQ6C/G4LpS+c4kp3S/hQVw=; b=VhP1nFELvN0Ohb6zSqD6h3UAEpmHUrCkRgDn+1gTVHPb8iUg9xF64PqaJEAWkk80JtGfCN8FhzMnbrJkEq/pi94PxkZt/w0jsJYcJx17Kxkk8Ml6DVaQYx3HeLk+pLzjEISRh45KLRC22O4LhEKEohtW99MjDQPORuaVHvZptOc=;
Received: from ([]:51011 helo=[]) by with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from <>) id 1aSYek-0005Wh-8p for; Sun, 07 Feb 2016 15:22:20 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_BAFC42BE-304D-424B-90A9-151C780BFBC6"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Pgp-Agent: GPGMail 2.6b2
From: Eric Burger <>
In-Reply-To: <>
Date: Sun, 7 Feb 2016 18:22:14 -0500
Message-Id: <>
References: <em72874602-962e-43e1-90d2-497acacceffd@sydney> <>
X-Mailer: Apple Mail (2.3112)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
Archived-At: <>
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Feb 2016 23:22:22 -0000

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 <> wrote:
> --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones"
> <> 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 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
> _______________________________________________
> apps-discuss mailing list