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

"Paul E. Jones" <> Tue, 09 February 2016 01:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D6CF91B3EB9 for <>; Mon, 8 Feb 2016 17:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R8zNaOUV9OfS for <>; Mon, 8 Feb 2016 17:02:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 739C01B3EBE for <>; Mon, 8 Feb 2016 17:02:55 -0800 (PST)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u1912okd009094 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 20:02:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1454979771; bh=tSbFHKzlbqYt/JcwybXkHEDQVjVF45GjaUPV88/kmRM=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=cl3ExZSSdQO1vwRBA3XX6wQGgkcDiRDVCbmurX1N3f85dRhq2LkiTi78YnhsJ+mnR 3NYHL0OW67b9qzBIBo2zhrgaj9nexJWSvdRH3wVV57c8dHxtuXLfo5qFBLMX/E3aSQ oSw/GhllOnZ3X3SRPAgm1cniWdzXpnsYwkWcCOAc=
From: "Paul E. Jones" <>
To: Marten Gajda <>,
Date: Tue, 09 Feb 2016 01:03:21 +0000
Message-Id: <em2bd7d4a9-56c3-466d-824b-35bcc0137d0e@sydney>
In-Reply-To: <>
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 ( []); Mon, 08 Feb 2016 20:02:51 -0500 (EST)
Archived-At: <>
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via WebFinger
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: Discussion of the Webfinger protocol proposal in the Applications Area <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Feb 2016 01:02:58 -0000


Thanks for the encouraging words; it sounds like you understand the 
problem that needs to be solved.

I always felt the server side was the trivial part.  As you said, it's 
possible to set up a simple WebFinger server with a static file (or sets 
of files), an .htaccess file, etc.  I use a server that pulls data from 
a database, myself.  Importantly, though, the WebFinger protocol is very 
simple (and I have to thank a number of folks who forced that 
simplicity), so I see the server side as being far less of a barrier.  
Hosting providers, for example, could very quickly and easily support 
this server-side.

The clients are the challenge.  As others have noted, this requires code 
changes in the clients and deployment of the clients.  I'm encouraged 
that you're working on client code. :)

Having an RFC is going to be an extremely important step to actually 
seeing this problem solved.  That said, I did not want to spend time on 
something that would be met with total rejection.  It sounds like there 
is at least enough interest to start a meaningful dialog, so I'll try to 
put together a draft soon and we can go from there.  If you're 
interested to collaborate on that, you're certainly welcome.


------ Original Message ------
From: "Marten Gajda" <>
Sent: 2/8/2016 5:54:58 PM
Subject: Re: [webfinger] [apps-discuss] Mail client configuration via 

>Hi Paul,
>as a client developer I'm very interested in this topic. We've actually 
>implemented draft-daboo-aggregated-service-discovery-03 and there is at 
>least one groupware server product which also supports it.
>While working on our implementation we've identified a few minor issues 
>with the latest draft and we've already discussed them with Cyrus. I 
>think most of these issues are solved easily.
>Though, the major issue has not been addressed yet. It's the issue 
>mentioned by Stephen. Under certain conditions a client might have to 
>ask the user upfront to authenticate, which may disclose the user's 
>credentials to the wrong service.
>We didn't release this feature in our generic CalDAV/CardDAV clients, 
>mostly due to that issue.
>Anyway, I think it really starts with the server developers. 
>Implementing the current spec is not that much work on the server side. 
>In many cases the server configuration document could just be a static 
>file and setting up a simple WebFinger end point is not that hard 
>either. Actually, for our corporate server we've just created a few 
>static files and some redirect magic in our .htaccess file to provide 
>the WebFinger stuff.
>On the client side it's more work, because it affects the account setup 
>flow a lot. But it surely is worth the efforts if more services support 
>However, before even the server developers can start, it requires an 
>RFC. So lets start to think about how to solve the authentication 
>Am 08.02.2016 um 20:00 schrieb Paul E. Jones:
>>>Right now it is not clear to me that an ASCOT-like solution would be 
>>>adopted given the use of device management. Before embarking on this 
>>>we need to take a careful look at whether any solution is likely to 
>>>be adopted (with the biggest burden likely being on clients/OS 
>>>vendors to support it). Given the device management solutions already 
>>>out there, I suspect there would be little value to m,ost of those 
>>>folks to actually support ASCOT.
>>I completely agree that we should try to get a sense of the likelihood 
>>of success.
>>Within the enterprise -- especially the larger ones -- you are 
>>entirely correct that device management systems provide a good 
>>solution for most of the employees.   However, I interact with a lot 
>>of smaller businesses that do not use such systems.  Many of them have 
>>a web hosting company host their domains and do not have IT staff to 
>>help them on a daily basis.  I'm skeptical that a device management 
>>system would help that class of users, so arming hosting providers 
>>with tools they can deploy to their customers would help, I think.
>>There are also a number of individuals who have their own domains, 
>>many hosted on the many, many web hosting providers out there. Same 
>>issue for most of them.
>>So, I think there is a market need.  I suspect if we were to create a 
>>solution, hosting providers were to deploy it, and client developers 
>>were to support it, people would use it.  However, that's a string of 
>>"ifs".  I think it starts with the client developers.  If there were 
>>people interested to solve the problem, I think the rest falls into 
>>All that said, if client developers are uninterested, there's little 
>>point working to solve this problem.
>>>As an alternative, the IETF might want to take a more serious look at 
>>>the overall device management solutions, and see if there might be 
>>>scope for standards in that area. That would allow us to build off 
>>>something that is already deployed (in a number of proprietary 
>>>solutions) but is today solving the problem of account setup.
>>I think your suggestion is worthwhile independent of whether we solve 
>>the problem for smaller businesses and individual users of hosted 
>>domains.  It would good if the same solution or would address those 
>>needs of smaller businesses and individuals, but if it didn't, it's 
>>still a step forward.
>>webfinger mailing list
>-- Marten Gajda
>dmfs GmbH
>Schandauer Straße 34
>01309 Dresden
>phone: +49 177 4427167
>Managing Director: Marten Gajda
>Registered address: Dresden
>Registered No.: AG Dresden HRB 34881
>VAT Reg. No.: DE303248743
>webfinger mailing list