Re: [art] Auto-configuring Email Clients via WebFinger

"John R Levine" <johnl@taugh.com> Tue, 16 July 2019 19:31 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A811D120114 for <art@ietfa.amsl.com>; Tue, 16 Jul 2019 12:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=O4kqLEh2; dkim=pass (1536-bit key) header.d=taugh.com header.b=Uid8zWVu
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 XQEWV8JjzdwG for <art@ietfa.amsl.com>; Tue, 16 Jul 2019 12:31:37 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A50512006A for <art@ietf.org>; Tue, 16 Jul 2019 12:31:37 -0700 (PDT)
Received: (qmail 80014 invoked from network); 16 Jul 2019 19:31:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1388c.5d2e2617.k1907; i=johnl-iecc.com@submit.iecc.com; bh=cVru8YqbiZGv6bcZzhf/lQlRH4zAcc8Mvm6ynhOyyzs=; b=O4kqLEh2GsTajXAJ7tY4rEXwNXwisk3ikSDZtM6/QMhUeUcmsKlenHNraFrAh03mnRz8qCGjF+1zV0lY9vFmgU7LiZE17UD7MWWiEI34GcrIBdGn2rnaWhcguFQWopvZDt2nmBQ51iKNxHf4RmJ3iXtgjmIS3BJIhkNvymCKXglf0DFZj1apvYEr4OXf8SIXRqIaKuituyGodrNsoR3H4IXyquM8Iyw9mwVS2WNaVkrlWzxIP4OmoPiOnEQG/+rw
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1388c.5d2e2617.k1907; olt=johnl-iecc.com@submit.iecc.com; bh=cVru8YqbiZGv6bcZzhf/lQlRH4zAcc8Mvm6ynhOyyzs=; b=Uid8zWVu1N0u96R+hIyyKGwXXxQD72EpvL1NKQBjWpm1Xv1bQeLcvpeuPhyIxAmyoMESzKPD6tNT3KFAzHqjQkB7UPgnG44sX+LawsdNfGrWVj/KXWxR7ywk95Rqv5Ff4hUq5ruG4IqgNbWgTmMp0SKNYtNVwe07cCMDtk/zZv2RW32edVhFdLDZB5cYexxVHSMwBIfzl9w19qLhBZw8orSqpmCJWIxBHJihK9yzKXP4OEVrv26xoy7ZqyBoURmp
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 16 Jul 2019 19:31:35 -0000
Date: Tue, 16 Jul 2019 15:31:34 -0400
Message-ID: <alpine.OSX.2.21.9999.1907161527040.58488@ary.qy>
From: John R Levine <johnl@taugh.com>
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: John Levine <johnl@taugh.com>, art@ietf.org
In-Reply-To: <emf7e4da87-5975-484c-8fe3-47863fb4cfd3@sydney>
References: <eme8317959-26f9-4a9d-b2be-d2f8cb0961f6@sydney> <20190716050506.BA8894C5D36@ary.qy> <emf7e4da87-5975-484c-8fe3-47863fb4cfd3@sydney>
User-Agent: Alpine 2.21.9999 (OSX 337 2019-05-05)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/23nK0V0HF5LBIfFrA-xYN4qUvpI>
Subject: Re: [art] Auto-configuring Email Clients via WebFinger
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2019 19:31:40 -0000

> The scheme you show is very similar to the WebFinger proposal.

Yes, I realize that.  But my point is that the scheme I show actually 
exists, whereas webfinger in MUAs does not.

> Another thing to consider is migration.  When a service provider needs to 
> move a bunch of users from one server cluster to another, would it make more 
> sense to write configs into the customer's /autoconfig/ directories or update 
> config files they maintain separately?

Neither, I'd say.  Any provider big enough for that to be a problem should 
be able to generate the config files on the fly from their main database 
as requested.  I presume you know that slashes in a URL need not have any 
connection to a file system on a server.

> Given the push-back I got about XML back then, too, it's probably best this 
> is in JSON format (though, again, I have no strong preference).

I don't care either, except that the MUA code that exists now uses XML.

R's,
John

>> More concretely, it seems to me that it would be better to make this a
>> profile of the existing autoconfigure scheme, which some MUAs
>> implement, rather than webfinger, which no MUAs implement.
>> 
>> The Mozilla design (over-design, really) looks up the configuration
>> for alice@example.com at
>> https://example.com/.well-known/autoconfig/mail/config-v1.1.xml or
>> https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=alice@example.com
>> 
>> On the theory that web servers generally ignore GET parameters that they 
>> don't understand, we can look up
>> 
>> https://example.com/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=alice@example.dom&password=swordfish
>> 
>> and it returns Alice's mail setup, possibly ignoring the address and 
>> password and returning a common
>> setup for all the mailboxes at example.com.  The password makes it harder 
>> for people who aren't
>> Alice to snoop on her mail setup.
>> 
>> This doesn't give you the extra Personal/Business level of
>> indirection, but I have no idea what it would mean to have two
>> different mail configurations for the same e-mail address.  I have
>> personal and business mail addresses, but they're different addresses
>> which I presumably know and configure either or both as needed.