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

"Paul E. Jones" <> Mon, 08 February 2016 18:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 578891B31AB; Mon, 8 Feb 2016 10:59:59 -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 JZqFYrJC4n8Z; Mon, 8 Feb 2016 10:59:58 -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 DB3EF1B319E; Mon, 8 Feb 2016 10:59:57 -0800 (PST)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u18IxkkA010031 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2016 13:59:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1454957988; bh=hTgR6z8Xh+bHIVecnAjbrNer5iKOsp7XII6nEgwbfwY=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=mHUqFhksNgGsx6TxYYrzq0Hou48HwtvKFExpnXkbMj5ZqxSNhu/IYjPcrZlU20dfs DujyWbkNsQlKQtcpTELHPMaPOYnvvYnleS6QZwlnKw0Jp9ES5wDhLoRkugIL1jNpHi V0EaDnLGtEL6KOMAIZUixYRze8wcf3Ujd9o/zFME=
From: "Paul E. Jones" <>
To: Cyrus Daboo <>, John C Klensin <>,,
Date: Mon, 08 Feb 2016 19:00:16 +0000
Message-Id: <em67ef0b5c-33c6-4fd5-ae6a-15f29ac400d2@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 13:59:48 -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: Mon, 08 Feb 2016 18:59:59 -0000


>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.