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

Eric Burger <eburger@standardstrack.com> Sun, 07 February 2016 23:22 UTC

Return-Path: <eburger@standardstrack.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 EC6771A8998 for <apps-discuss@ietfa.amsl.com>; Sun, 7 Feb 2016 15:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiCCqMiTNwhY for <apps-discuss@ietfa.amsl.com>; Sun, 7 Feb 2016 15:22:20 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969111A8997 for <apps-discuss@ietf.org>; Sun, 7 Feb 2016 15:22:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; 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 ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51011 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from <eburger@standardstrack.com>) id 1aSYek-0005Wh-8p for apps-discuss@ietf.org; 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 <eburger@standardstrack.com>
In-Reply-To: <EE5D283AC957E10DA443AA15@JcK-HP8200.jck.com>
Date: Sun, 7 Feb 2016 18:22:14 -0500
Message-Id: <72EAB04F-DD51-428A-93F8-8C8E3F673B4F@standardstrack.com>
References: <em72874602-962e-43e1-90d2-497acacceffd@sydney> <EE5D283AC957E10DA443AA15@JcK-HP8200.jck.com>
To: apps-discuss@ietf.org
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 - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/QLY57SpcoL5rPo-C9h8zQKFMq-0>
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: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 <john-ietf@jck.com> wrote:
> 
> 
> 
> --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
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss