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

John C Klensin <> Mon, 08 February 2016 19:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 13CE41B2E9F for <>; Mon, 8 Feb 2016 11:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XFsFuHOgUlkM for <>; Mon, 8 Feb 2016 11:49:24 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6F121A1A6A for <>; Mon, 8 Feb 2016 11:49:23 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1aSroI-00080W-Ls; Mon, 08 Feb 2016 14:49:22 -0500
Date: Mon, 08 Feb 2016 14:49:17 -0500
From: John C Klensin <>
To: Eric Burger <>,
Message-ID: <>
In-Reply-To: <>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Mon, 08 Feb 2016 19:49:25 -0000

--On Monday, February 08, 2016 10:43 -0500 Eric Burger
<> wrote:

> Perhaps an application-layer DHCP?

Obvious, but another example of why I think we need to look back
and do some examination.  Something built on a DHCP-like model
(or, I suspect, on the sort of device identification model
Claudio mentioned) probably means exposing the device and/or its
location in all sorts of ways.  That is precisely what assorted
privacy efforts are trying to avoid.  But Dave suggests (I think
probably correctly) that one of the fatal flaws with ACAP is
that it requires a username and hostname.  That has other
problems, but can also lead to a different set of privacy issues
(including the potential for linking various credentials and
device information).  One can work around those issues using
HTTPS with verifiable client certs, but that just changes the
problem in other ways.  Or one can move to a layered solution,
hoping that opportunistic encryption based on traditionally
largely-unverified server credentials will adequately hide the
private stuff.

Better be sure we know what problem we are trying to solve.