From nobody Mon Jul 15 12:31:03 2019 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2909212027B; Mon, 15 Jul 2019 12:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com 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 1R8WmIVIelDB; Mon, 15 Jul 2019 12:31:00 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 E40341200F9; Mon, 15 Jul 2019 12:30:59 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1563219056; bh=2tP9S1OgIKlzXC+phO0Gv2g+B++K4iVJ/CcnaAtNw90=; h=From:To:Subject:Date:Reply-To; b=bmZ5ZlujlZqvlIaWjz3ji4JfouRy3gr0S7IFa8fT2iHXbcadbN2DG9VV+VMTQ/kQl PVWCsXaFJQVaJLIa+OlvddL77Jxehi6YAyykJXXSDe7KA7ZFhnrq4mtyh/vITaIoww mSma1MpnvAmRk81zsKaVbYc0Z4lQJ9R027yPJnYM= From: "Paul E. Jones" To: "art@ietf.org" , "webfinger@ietf.org" Date: Mon, 15 Jul 2019 19:30:53 +0000 Message-Id: Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.35595.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBE694187E-0E87-44E0-A852-6F7D14382D35" Archived-At: Subject: [webfinger] Auto-configuring Email Clients via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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, 15 Jul 2019 19:31:02 -0000 --------=_MBE694187E-0E87-44E0-A852-6F7D14382D35 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable ART folks, Several years ago when I was working on WebFinger, one of the use cases=20 I presented was using WebFinger to facilitate auto-configuring email=20 clients. It was and still is a problem I deal with today. For my own family, I have to manually configure several different=20 clients on several different platforms for each member of the family. =20 It's time consuming and really needs to be made simpler. My wife also has to deal with this issue where she works, because her=20 company, while just 100 or so employees, has offices in two different=20 countries and the mail server settings an employee uses depends on his=20 or her geographic location. To use standard IETF protocols, it means a=20 lot of manual provisioning. I see the same sort of challenges with service providers. If one wants=20 to have his or her own domain, but isn't technically savvy, they're in=20 for a lot of "fun" trying to figure out the various settings. Seriously,=20 no normal person should have to understand what SMTP or IMAP means, and=20 definitely what port numbers or security settings to fill in. While there has been a generic DNS-based method for email provision for=20 a while, it doesn't work for me. It doesn't work for my wife's company,=20 either. It also doesn't define everything one might need to define=20 (e.g., required security settings or policies). So we put together a very simple example to show how this might be done=20 with WebFinger. See the draft here: https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00 The example in that document should make it clear how we intend this to=20 work, though the detailed procedures and syntax are missing. We first=20 want to see what interest exists and if this general approach will work=20 for everyone before getting into too much detail. We'd love to have some dialog on this to see how we can address this=20 problem of auto-configuring email clients. Paul --------=_MBE694187E-0E87-44E0-A852-6F7D14382D35 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable ART folks,

Several years ago when I was working= on WebFinger, one of the use cases I presented was using WebFinger to facil= itate auto-configuring email clients. =C2=A0It was and still is a problem I = deal with today.

For my own family, I have to m= anually configure several different clients on several different platforms= for each member of the family. =C2=A0It's time consuming and really needs t= o be made simpler.

My wife also has to deal with = this issue where she works, because her company, while just 100 or so empl= oyees, has offices in two different countries and the mail server settings= an employee uses depends on his or her geographic location. =C2=A0To use st= andard IETF protocols, it means a lot of manual provisioning.

I see the same sort of challenges with service providers. If= one wants to have his or her own domain, but isn't technically savvy, they'= re in for a lot of "fun" trying to figure out the various settings. Serious= ly, no normal person should have to understand what SMTP or IMAP means, and = definitely what port numbers or security settings to fill in.
While there has been a generic DNS-based method for email pr= ovision for a while, it doesn't work for me. It doesn't work for my wife's= company, either. It also doesn't define everything one might need to define = (e.g., required security settings or policies).

So we put together a very simple example to show how this might be done wi= th WebFinger. =C2=A0See the draft here:

The example in that document should= make it clear how we intend this to work, though the detailed procedures an= d syntax are missing. =C2=A0We first want to see what interest exists and i= f this general approach will work for everyone before getting into too much = detail.

We'd love to have some dialog on this t= o see how we can address this problem of auto-configuring email clients.

Paul

--------=_MBE694187E-0E87-44E0-A852-6F7D14382D35-- From nobody Thu Jul 18 01:41:00 2019 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7DD12013C for ; Thu, 18 Jul 2019 01:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 xyE1QT_dwgLY for ; Thu, 18 Jul 2019 01:40:55 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8AF120111 for ; Thu, 18 Jul 2019 01:40:55 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id s49so29473320edb.1 for ; Thu, 18 Jul 2019 01:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=48WNc517EiATeSKxUkL5i9e4ragIT/RJrjdTfZ3O0A4=; b=HImZbvDhoO4KmXDj7FzVxDu0akJ7+JoL+Bi8xusrJUp3Ysney9uwgoTNPWP7mCNDFO MZNw0GJRLRzb5ltvsNP+pU4MaeCp8J2/cMC7DoZyHE0xPByMasKKsFUfiDgtlCcwlTUZ N32Y/fIDRBkyoB9f1AN9xx1vOFj62qXDicWx0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=48WNc517EiATeSKxUkL5i9e4ragIT/RJrjdTfZ3O0A4=; b=rjaORVCMUYhxVbtnjz+6jv/Z0uWIiz1oK3+doKqqN5BqTD/frYsJ4sivla7v2p5dys b+jYNj4XJihZPso30ow53N00FILwYqbqjNY+72RZWd7SD4W/nEPxTJ/J9YapbJKCopLj u79yuYQFWIezglsvq0/W9tD9+70GjKJZ18aOFDPHz5vLPzGOQP0o9Zoh2jCIRqglC2VJ 3QyzwmvzW2B+IW78gAgWDuI0Mjjmf1fCnHPPs1b5u6NdDQySlHi6XICQr7Bn36/WQV+2 tp7qP1EYPurt9xU3l2ml9eudQ9MYVa5JFZ2dFaIHo6GQ+mqSG4a0ITGJSSLX4DGqrHs9 IxkA== X-Gm-Message-State: APjAAAX4lTsDuU+oz7KkWIo8zeq23iTyIHWJlxgO5nTLGKFoQeN0IVzz /pSzrxaaQGsIcTsQvGcBO3heSAaBRSUEod+YPgoWJA== X-Google-Smtp-Source: APXvYqwi1lLMP9wfbQqYnVMsIhcFKtFCVqKBUPCCdEnHtSfHkX6Ou4kmGG8ip91mqQK2SXVqeIsfvP01tWeMYp2Rb5U= X-Received: by 2002:a17:906:11da:: with SMTP id o26mr35097937eja.64.1563439253899; Thu, 18 Jul 2019 01:40:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Cridland Date: Thu, 18 Jul 2019 09:40:41 +0100 Message-ID: To: "Paul E. Jones" Cc: "art@ietf.org" , "webfinger@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005b5eab058df091b3" Archived-At: Subject: Re: [webfinger] [art] Auto-configuring Email Clients via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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: Thu, 18 Jul 2019 08:40:59 -0000 --0000000000005b5eab058df091b3 Content-Type: text/plain; charset="UTF-8" Obviously I'd prefer ACAP. But also, please note the existence of RFC 6186. It's not widely deployed, but if we were to open this can of worms, and not simply reuse Thunderbird's autoconfig XML format (which, if I recall, is also supported by various other Open Source MUAs), then I'd be keen to get SRV up and running properly. Dave. On Mon, 15 Jul 2019 at 20:31, Paul E. Jones wrote: > ART folks, > > Several years ago when I was working on WebFinger, one of the use cases I > presented was using WebFinger to facilitate auto-configuring email > clients. It was and still is a problem I deal with today. > > For my own family, I have to manually configure several different clients > on several different platforms for each member of the family. It's time > consuming and really needs to be made simpler. > > My wife also has to deal with this issue where she works, because her > company, while just 100 or so employees, has offices in two different > countries and the mail server settings an employee uses depends on his or > her geographic location. To use standard IETF protocols, it means a lot of > manual provisioning. > > I see the same sort of challenges with service providers. If one wants to > have his or her own domain, but isn't technically savvy, they're in for a > lot of "fun" trying to figure out the various settings. Seriously, no > normal person should have to understand what SMTP or IMAP means, and > definitely what port numbers or security settings to fill in. > > While there has been a generic DNS-based method for email provision for a > while, it doesn't work for me. It doesn't work for my wife's company, > either. It also doesn't define everything one might need to define (e.g., > required security settings or policies). > > So we put together a very simple example to show how this might be done > with WebFinger. See the draft here: > https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00 > > The example in that document should make it clear how we intend this to > work, though the detailed procedures and syntax are missing. We first want > to see what interest exists and if this general approach will work for > everyone before getting into too much detail. > > We'd love to have some dialog on this to see how we can address this > problem of auto-configuring email clients. > > Paul > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --0000000000005b5eab058df091b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Obviously I'd prefer ACAP.

But also= , please note the existence of RFC 6186. It's not widely deployed, but = if we were to open this can of worms, and not simply reuse Thunderbird'= s autoconfig XML format (which, if I recall, is also supported by various o= ther Open Source MUAs), then I'd be keen to get SRV up and running prop= erly.

Dave.

On Mon, 15 Jul 2019 at 20:31, Pau= l E. Jones <paulej=3D= 40packetizer.com@dmarc.ietf.org> wrote:
ART folks,

Several years ago when I was working on = WebFinger, one of the use cases I presented was using WebFinger to facilita= te auto-configuring email clients.=C2=A0 It was and still is a problem I de= al with today.

For my own family, I have to manual= ly configure several different clients on several different platforms for e= ach member of the family.=C2=A0 It's time consuming and really needs to= be made simpler.

My wife also has to deal with th= is issue where she works, because her company, while just 100 or so employe= es, has offices in two different countries and the mail server settings an = employee uses depends on his or her geographic location.=C2=A0 To use stand= ard IETF protocols, it means a lot of manual provisioning.

I see the same sort of challenges with service providers. If one w= ants to have his or her own domain, but isn't technically savvy, they&#= 39;re in for a lot of "fun" trying to figure out the various sett= ings. Seriously, no normal person should have to understand what SMTP or IM= AP means, and definitely what port numbers or security settings to fill in.=

While there has been a generic DNS-based method f= or email provision for a while, it doesn't work for me. It doesn't = work for my wife's company, either. It also doesn't define everythi= ng one might need to define (e.g., required security settings or policies).=

So we put together a very simple example to show = how this might be done with WebFinger.=C2=A0 See the draft here:

The example in that = document should make it clear how we intend this to work, though the detail= ed procedures and syntax are missing.=C2=A0 We first want to see what inter= est exists and if this general approach will work for everyone before getti= ng into too much detail.

We'd love to have som= e dialog on this to see how we can address this problem of auto-configuring= email clients.

Paul

___= ____________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--0000000000005b5eab058df091b3-- From nobody Thu Jul 18 07:12:20 2019 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAB21202DA; Thu, 18 Jul 2019 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com 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 k8VaVZ6PYf1P; Thu, 18 Jul 2019 07:12:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 413B91202B0; Thu, 18 Jul 2019 07:12:09 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1563459126; bh=/2Bs3z93KD8e2z/OZcfMOboLjHiO5NjrrYHGB3i2SQM=; h=Date:In-Reply-To:References:Subject:To:CC:From; b=glteTCZ0vxgE2XhB0yPcL+LWqQVWXwIdNhYPAswx4rwRC++B+ORVuzwND6FsbbFZd 79zCRuWZpsKRA17gyB605ckcA4LJNEHR4Udj+FihZ+XaV/atpcF+AKlAmWAf/BQii4 YcNsQNLc8fkdFERHENlL1PZgRiN5m996spjTjtmo= Date: Thu, 18 Jul 2019 10:12:04 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----V0SNC6DDFAUB60JFU5YOYHYOCM96FP" Content-Transfer-Encoding: 7bit Autocrypt: addr=paulej@packetizer.com; keydata= mQQNBFHlwHIBIADPBuXxiC7IP3Acolod+D4BWYKBDGgyX90mexkDt6Wi6D2LJlpadGp99NgG9Oc4 m9QDEPPuhRHKvgexNAxAeILUZlOX6m/30n83VuwGNZagxjawN9/Kv4WrLlDI+HSZeKwfVf8GBus/ jB6c5WQtV6/L7LYCQLU08dWng8NlBi6dupyWC1rhtNWnPCqS4C3nINWJRx4grfIvkI5PbDMPca/B iluZxy0XntHuNWf51Gj4IIIAK2QNWQwDLaDnZ774Q1HfMTt4u4UwivsOt9Z49w92Q6FuN7/3sve7 DwrEVtp0xCKqaBQOX2354VVOTMh0bhHGLprQ1BL3QAWlyg/ZkTs+kopd3h+mJ0Mkg3Es66umcG8U YbH+edmZ7mHWqHuWmNieEycZgmah6kfrb7lUZeJnkkLfZ6SS3fhJIhJq3RwTKfvyF9LNvnZ7XXsO VSBKvVFPHWuDe3tbglTZCEYIcdFotgMcpZatdJF0ZPdLPGECc/XCZOgQpICGZ6b0dt/uJKOPC1OY RlFfIWc9bDgRCQY0MCqTsYiGevMNdQTlZHgTactm4h886bETFdbSoDniPls7LuI3cAr++iHmF56o hwh9Hl8KVzsv+uSL1mmrfE/X+lEaJnPUrQopByFQySE4D+hvOFLNh2iv7BHyXX9G0Dv9jDB6hW+6 1RYBf23GRZWSEVMyoYfbbU7Tg5JNrVRLU7nUMVbla2fGIKz9K3ejtCy/35QAjt7DIrVVe9k9J54r Z1yD8ZXfQXv869/q/mHGVzxdtgO+PcrIXJYck8R7jSDB2wIo3g5z+2P3Lt2gvB4w9UUSNZ4deE95 MNc6FvqqTMlBzoxzBf2E+SoUZKTl4i48XJhKI+Bk71NnMug2ER2NbyQIg6aH7l4t4t38mK6yt/cd 00f8UtKxp7z2EnqXJ+/kx0pq9zECp76oAPv9JlInntbcl89jRS4qMAMgZFEy6sYOMftfhVgDkci/ JR+2s4V65aUxcR6PLtXRHg3ZZ2F4hEBkBxJQt4LZ6lWzMXuWkCfjca032WOq/Zl+RMrs18dywVoh DXqSaYoSCzkfeCbzTE4cCuE8o9FUx7B/nS6g+h0wvrGDcLeGIwVWYO+Q0gf+vbLq2ZfykWjS5Fa3 ZKLdEOWaNas/8UlW33lU3u9nj84dJgMcP/VAugd8N9QWJ9NKszL8689NmwQnzoIU43+ucRd0WgCA WgXtV6MmG2WUpKN6y/ARqis6NvKTpl/t7SMznBxZGg2ZUC7pBpT/cq6vi18+tWP1ghRGJgJJ4t6v D64fBQTAaaN9MxU46OIlcWtjvf5zzL0pwebYOdInN/wA7YOOK3Q/wQsPaD5dvY+6H9yrCLMBwGyR l3TB/bsaYqtFABEBAAG0JVBhdWwgRS4gSm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbT6JBDgE EwECACIFAlOH4kACGy8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHropU4WcvKlpF4gAI34 iWlJY84nB8y12sqLldU0d9rSnk6euOYf7HIIJ8yHGCHVkQJUksjcwPOAr/zw4XjftSEv8JN3PDLp khvQ2snEIZ7UPFafUmbq3BQLPkN0Mpamx7br7vpLwpRMwbPyWYc4Z0+Ag4t6p/01troi++v3DLDN AjAov/Q526pL7qFkIJpadMcVcTEgr5XEsVVxw5TbGrqyDwam+aNIVcxDNxzOG4nFJ1bjUGAeoRcV Jnz0X0CQUFzxgMceyjuqI3Qyj5kp3gZkoibJyfZ6/6FFVV5dGAlHluL52H6KiUAkWPf0qbGo6ELu xsnSX9JPVUtr14B6HfZP8kWX740Hu2yBQTAxhsfhhsR4LNUxKcdNFSJ/Ozpo3i7fvek3CF+ash7l 25JAkI+1TH4kh7dYpndwTWwXDNqTMQR+I+JtsKgATpx/pBWaNK0zvWKuxjoM/CVn4NPWf9aqfdF3 wvTq5EMDarQ8Leou0LsKLKZsJHYYxFlMlD37/+q4UsIy5iPatNl8qm4YM4LykjvB+Ozsd3OZ3z+b uSdJ+6QwOnje21tPLhSI8dEIw8S+DKl+80I/2bEd3+wKptHcB0NU3OF9B3N1ClOp7wFIrgsQ0pTH A2pchxWyC9pngYhErJS6nZaQeWwrN7VH9RkS2SPPkAzf5N27ayky2rF8nDZrkO1OuXCaH9gyi2CQ fJEtbAPMXfAJo5Ls0trEMqQGDAW3/GxCo5NoX70bXjPd+NXBIYBaC9dc6Iyqei3xQJNsE2vtPEo3 glJaE3mFMpUOILqQkU8hjs3+J1rNkpkmaoenlvbDVUqM0TVGzHFJlPtLXR/DsDjgjk1uaS+xIlD0 exwLp3/Bgs4nXAQ1UYlPOLC/BokUPwAuSuUrCAYHfAzwsynIgI8j/EHeKgyjyuQ4f1uIlzy63rVd 8QVvGt6qV2hO0Bj4FzIMG9xG4KZ7cPziHmAh5tR0PbV35vJLww3HbmL6LzC5CaB2cYkLuOL4BuhU D+b20GiThhtYaPBQr49NBNViCB+RlhojKIS4Ou9+ngg2L4EWe6rY0yzR+BWPBvNtZNantozb49Pu IcYhfxzWFjK7Gt6zlQeUfsBGtdjR1p4emdH4c/VFdzj4bNPtKv56mkUrcFQpE1vym/PPYyvG3wBz UXF/d/W5NqojZmuQLO+GfMPo2sbT3V0LTELlfRfzOstA7SpdQgYpMoRQwErxIwn2lUVjt6DjXeaR oOkQgYAgQqHYLrWef6gYLy05xHEN6Ow6t7VDxuZOtjrJqQ3oyfcyR9EsyAET8CvSSaHABOaqWOiw E+TzU9/42ei0Qph08xL8BQMQVsnOJZLM8DMNWzWB3wVxCaVil+unNTnmw7mjClcPFuBjFyc= To: Dave Cridland CC: "art@ietf.org" , "webfinger@ietf.org" From: "Paul E. Jones" Message-ID: <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com> Archived-At: Subject: Re: [webfinger] [art] Auto-configuring Email Clients via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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: Thu, 18 Jul 2019 14:12:13 -0000 ------V0SNC6DDFAUB60JFU5YOYHYOCM96FP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave, RFC 6186 is the DNS-based one to which I referred below=2E Unfortunately, = it doesn't allow setting various configuration options and wouldn't work at= all for my wife's use case where employees use different mail servers base= d on the country in which they reside=2E Paul -------- Original Message -------- From: Dave Cridland Sent: July 18, 2019 4:40:41 AM EDT To: "Paul E=2E Jones" Cc: "art@ietf=2Eorg" , "webfinger@ietf=2Eorg" Subject: Re: [art] Auto-configuring Email Clients via WebFinger Obviously I'd prefer ACAP=2E But also, please note the existence of RFC 6186=2E It's not widely deploye= d, but if we were to open this can of worms, and not simply reuse Thunderbird's autoconfig XML format (which, if I recall, is also supported by various other Open Source MUAs), then I'd be keen to get SRV up and running properly=2E Dave=2E On Mon, 15 Jul 2019 at 20:31, Paul E=2E Jones wrote: > ART folks, > > Several years ago when I was working on WebFinger, one of the use cases = I > presented was using WebFinger to facilitate auto-configuring email > clients=2E It was and still is a problem I deal with today=2E > > For my own family, I have to manually configure several different client= s > on several different platforms for each member of the family=2E It's ti= me > consuming and really needs to be made simpler=2E > > My wife also has to deal with this issue where she works, because her > company, while just 100 or so employees, has offices in two different > countries and the mail server settings an employee uses depends on his o= r > her geographic location=2E To use standard IETF protocols, it means a l= ot of > manual provisioning=2E > > I see the same sort of challenges with service providers=2E If one wants= to > have his or her own domain, but isn't technically savvy, they're in for = a > lot of "fun" trying to figure out the various settings=2E Seriously, no > normal person should have to understand what SMTP or IMAP means, and > definitely what port numbers or security settings to fill in=2E > > While there has been a generic DNS-based method for email provision for = a > while, it doesn't work for me=2E It doesn't work for my wife's company, > either=2E It also doesn't define everything one might need to define (e= =2Eg=2E, > required security settings or policies)=2E > > So we put together a very simple example to show how this might be done > with WebFinger=2E See the draft here: > https://tools=2Eietf=2Eorg/html/draft-jones-webfinger-email-autoconfig-0= 0 > > The example in that document should make it clear how we intend this to > work, though the detailed procedures and syntax are missing=2E We first= want > to see what interest exists and if this general approach will work for > everyone before getting into too much detail=2E > > We'd love to have some dialog on this to see how we can address this > problem of auto-configuring email clients=2E > > Paul > > _______________________________________________ > art mailing list > art@ietf=2Eorg > https://www=2Eietf=2Eorg/mailman/listinfo/art > ------V0SNC6DDFAUB60JFU5YOYHYOCM96FP Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave,

RFC 6186 is the DNS-based one to whic= h I referred below=2E Unfortunately, it doesn't allow setting various confi= guration options and wouldn't work at all for my wife's use case where empl= oyees use different mail servers based on the country in which they reside= =2E

Paul


From: Dave Cridland <dave@cridland=2Enet>
Sent: July 18, 2019 4:40:41 AM EDT
To: "Paul E=2E Jones" <paulej@packetizer=2Ecom>
Cc: "art@ietf=2Eorg" <art@ietf=2Eorg>, "webfinger@ietf=2Eorg"= <webfinger@ietf=2Eorg>
Subject: Re: [art] Auto-configuring Email Clients via WebFinger

Obviously I'd prefer ACAP=2E

But also,= please note the existence of RFC 6186=2E It's not widely deployed, but if = we were to open this can of worms, and not simply reuse Thunderbird's autoc= onfig XML format (which, if I recall, is also supported by various other Op= en Source MUAs), then I'd be keen to get SRV up and running properly=2E

Dave=2E

On Mon, 15 Jul 2019 at 20:31, Paul E=2E = Jones <paulej=3D40packetizer=2Ecom@dmarc=2Eietf=2Eorg> wrote:
ART folks,

Several years ago when I was working on= WebFinger, one of the use cases I presented was using WebFinger to facilit= ate auto-configuring email clients=2E  It was and still is a problem I= deal with today=2E

For my own family, I have to m= anually configure several different clients on several different platforms = for each member of the family=2E  It's time consuming and really needs= to be made simpler=2E

My wife also has to deal wi= th this issue where she works, because her company, while just 100 or so em= ployees, has offices in two different countries and the mail server setting= s an employee uses depends on his or her geographic location=2E  To us= e standard IETF protocols, it means a lot of manual provisioning=2E

I see the same sort of challenges with service providers= =2E If one wants to have his or her own domain, but isn't technically savvy= , they're in for a lot of "fun" trying to figure out the various settings= =2E Seriously, no normal person should have to understand what SMTP or IMAP= means, and definitely what port numbers or security settings to fill in=2E=

While there has been a generic DNS-based method f= or email provision for a while, it doesn't work for me=2E It doesn't work f= or my wife's company, either=2E It also doesn't define everything one might= need to define (e=2Eg=2E, required security settings or policies)=2E
=

So we put together a very simple example to show how th= is might be done with WebFinger=2E  See the draft here:

The example= in that document should make it clear how we intend this to work, though t= he detailed procedures and syntax are missing=2E  We first want to see= what interest exists and if this general approach will work for everyone b= efore getting into too much detail=2E

We'd love to= have some dialog on this to see how we can address this problem of auto-co= nfiguring email clients=2E

Paul

_______________________________________________
art mailing list
art@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/art
------V0SNC6DDFAUB60JFU5YOYHYOCM96FP-- From nobody Thu Jul 18 09:03:15 2019 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D5F1207BD; Thu, 18 Jul 2019 09:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 HnkNHxWioSry; Thu, 18 Jul 2019 09:03:05 -0700 (PDT) Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A62F1207EE; Thu, 18 Jul 2019 09:03:05 -0700 (PDT) Received: by mail-ot1-f49.google.com with SMTP id s20so29593025otp.4; Thu, 18 Jul 2019 09:03:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D+ie+Ch58f+IOhc9Uc1evnctbltGjtb3uGI3DcdMryA=; b=ix2lHnLWITVwA+7AuI4MHT+8ngVfDvo9jPa5RtzrmENqPbg+2ce9UV0jKp8mqwQ0eD Zcme2sGmK7NAm0Cid+OpbOO9YIpfKlYXv2m9OgLgjW6BXZCjmJw9O7skXSo1V3qCO0dw rNJ/djPDF2VOX89BnwUdWJcvQCWpzu+0a+nuy675E9isN76UvJh7ufHHGfb1aUWzmrph DEkz+9kD2naReKIxkuxLqKHhUWcnzoCpgdhnnDYPDo9ZbWq2uHDSH7Q8PuSZ9cJ+S9sJ DA++P/8VNip2yJfWaqsgg77Lf1cIFDAt70QnCdICpNnp4I1D/bQG0cl/9M5m5eLDYbox uowA== X-Gm-Message-State: APjAAAU7NYdKZkNWlgFS0pa2K8wJBEmrAGvPnpjIQw/ARjXDEirDOPem RUoREpBO02Qo9UtqTR/UXEVWkeHM8ZFFAa16uFy4fA== X-Google-Smtp-Source: APXvYqyatqYUndTR/qEJeZi0UhDnWG3sFs7vnzMt/mOQ4AufS8MvQepq5+58OEC0N0q/KPaQgolYiHLzymqDFsrH90w= X-Received: by 2002:a05:6830:160c:: with SMTP id g12mr36934709otr.231.1563465784348; Thu, 18 Jul 2019 09:03:04 -0700 (PDT) MIME-Version: 1.0 References: <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com> In-Reply-To: <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com> From: Phillip Hallam-Baker Date: Thu, 18 Jul 2019 12:02:53 -0400 Message-ID: To: "Paul E. Jones" Cc: Dave Cridland , "art@ietf.org" , "webfinger@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1d5e2058df6bef9" Archived-At: Subject: Re: [webfinger] [art] Auto-configuring Email Clients via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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: Thu, 18 Jul 2019 16:03:07 -0000 --000000000000b1d5e2058df6bef9 Content-Type: text/plain; charset="UTF-8" Responding to Paul's point about his wife needing a country specific configuration, I think we need to think about this a bit differently. This is one example of an application configuration problem and a service discovery problem. What we need here is a scheme that is capable of supporting the general case. It makes no sense for any of the providers to change their existing schemes unless it is to move to a scheme that is more powerful because it is more general. Which means that at minimum it is supported by all the MUAs but ideally means it is supported by multiple applications as well. I have been thinking about this problem from the other side. I started what is now the Mathematical Mesh trying to work out how to automatically configure and maintain S/MIME and OpenPGP. While doing that, I suddenly realized that I could add in the SMTP configuration as well. So once Alice has configured her email service on one device, it is configured for them all. She will get her SUBMIT/IMAP/POP3 settings at the same time that she gets the S/MIME and OpenPGP keys to work on the device. I showed this to Dave Clark who asked for SSH as well (which is a real pig to configure as there is a bootstrap problem and a foul up may require someone to take a plane trip to a server to fix it). Being able to replicate the config across devices does not solve the problem of initial acquisition of course. But the replication mechanism should certainly use the same data structure (though translated to JSON probably). I have not thought about the Enterprise application of the Mesh in detail yet because I have to get it working for individual users first. But I am pretty sure that what we want here is single point onboarding (and terminations). So Alice joins example.com. She is issued a (new) company laptop and BYOB's her mobile. The onboarder checks the boxes for the corporate applications she is authorized for, email, ssh, etc. and the group encryption services for the teams she belongs to. The configulator then does all the rest. All that remains is to connect up Alice and her devices to these configurations. Which can be done in person via QR code or remotely via a Base32 fingerprint. It presents a workfactor of at least 2^112 either way. So from Alice's point of view, when she goes to the badge office to pick up her badge, she scans a QR code with her phone and that is it - she is all configured for email, chat, slack, slick, ssh, S/MIME and all the encrypted data she needs from the cloud. If she is working on some really sensitive stuff, her line manager or a VP might need to meet her in person to authorize adding her to certain groups. Termination should mean no more than unchecking the boxes. The cryptography I am using was discovered by Torben Pedersen and Matt Blaze in the mid 1990s. The reason it hasn't been applied was that it was too hard to use and until Robert Snowden came along, people thought the administrator of the key service in the cloud could be trusted. So I have made it really easy to use and administrate even in the case that we have separation of duties at the administrator level as well. On Thu, Jul 18, 2019 at 10:12 AM Paul E. Jones wrote: > Dave, > > RFC 6186 is the DNS-based one to which I referred below. Unfortunately, it > doesn't allow setting various configuration options and wouldn't work at > all for my wife's use case where employees use different mail servers based > on the country in which they reside. > > Paul > > ------------------------------ > *From:* Dave Cridland > *Sent:* July 18, 2019 4:40:41 AM EDT > *To:* "Paul E. Jones" > *Cc:* "art@ietf.org" , "webfinger@ietf.org" < > webfinger@ietf.org> > *Subject:* Re: [art] Auto-configuring Email Clients via WebFinger > > Obviously I'd prefer ACAP. > > But also, please note the existence of RFC 6186. It's not widely deployed, > but if we were to open this can of worms, and not simply reuse > Thunderbird's autoconfig XML format (which, if I recall, is also supported > by various other Open Source MUAs), then I'd be keen to get SRV up and > running properly. > > Dave. > > On Mon, 15 Jul 2019 at 20:31, Paul E. Jones 40packetizer.com@dmarc.ietf.org> wrote: > >> ART folks, >> >> Several years ago when I was working on WebFinger, one of the use cases I >> presented was using WebFinger to facilitate auto-configuring email >> clients. It was and still is a problem I deal with today. >> >> For my own family, I have to manually configure several different clients >> on several different platforms for each member of the family. It's time >> consuming and really needs to be made simpler. >> >> My wife also has to deal with this issue where she works, because her >> company, while just 100 or so employees, has offices in two different >> countries and the mail server settings an employee uses depends on his or >> her geographic location. To use standard IETF protocols, it means a lot of >> manual provisioning. >> >> I see the same sort of challenges with service providers. If one wants to >> have his or her own domain, but isn't technically savvy, they're in for a >> lot of "fun" trying to figure out the various settings. Seriously, no >> normal person should have to understand what SMTP or IMAP means, and >> definitely what port numbers or security settings to fill in. >> >> While there has been a generic DNS-based method for email provision for a >> while, it doesn't work for me. It doesn't work for my wife's company, >> either. It also doesn't define everything one might need to define (e.g., >> required security settings or policies). >> >> So we put together a very simple example to show how this might be done >> with WebFinger. See the draft here: >> https://tools.ietf.org/html/draft-jones-webfinger-email-autoconfig-00 >> >> The example in that document should make it clear how we intend this to >> work, though the detailed procedures and syntax are missing. We first want >> to see what interest exists and if this general approach will work for >> everyone before getting into too much detail. >> >> We'd love to have some dialog on this to see how we can address this >> problem of auto-configuring email clients. >> >> Paul >> >> _______________________________________________ >> art mailing list >> art@ietf.org >> https://www.ietf.org/mailman/listinfo/art >> > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --000000000000b1d5e2058df6bef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Res= ponding to Paul's point about his wife needing a country specific confi= guration, I think we need to think about this a bit differently.

This is one example of an applicati= on configuration problem and a service discovery problem. What we need here= is a scheme that is capable of supporting the general case.

It makes no sense for any of the provid= ers to change their existing schemes unless it is to move to a scheme that = is more powerful because it is more general. Which means that at minimum it= is supported by all the MUAs but ideally means it is supported by multiple= applications as well.

I = have been thinking about this problem from the other side. I started what i= s now the Mathematical Mesh trying to work out how to automatically configu= re and maintain S/MIME and OpenPGP. While doing that, I suddenly realized t= hat I could add in the SMTP configuration as well. So once Alice has config= ured her email service on one device, it is configured for them all. She wi= ll get her SUBMIT/IMAP/POP3 settings at the same time that she gets the S/M= IME and OpenPGP keys to work on the device. I showed this to Dave Clark who= asked for SSH as well (which is a real pig to configure as there is a boot= strap problem and a foul up may require someone to take a plane trip to a s= erver to fix it).

Being a= ble to replicate the config across devices does not solve the problem of in= itial acquisition of course. But the replication mechanism should certainly= use the same data structure (though translated to JSON probably).


I have not thought about the Enterprise app= lication of the Mesh in detail yet because I have to get it working for ind= ividual users first. But I am pretty sure that what we want here is single = point onboarding (and terminations).

So Alice joins example.com. = She is issued a (new) company laptop and BYOB's her mobile.=C2=A0
=

The onboarder checks the boxes= for the corporate applications she is authorized for, email, ssh, etc. and= the group encryption services for the teams she belongs to. The configulat= or then does all the rest.=C2=A0

All that remains is to connect up Alice and her devices to these co= nfigurations. Which can be done in person via QR code or remotely via a Bas= e32 fingerprint. It presents a workfactor of at least 2^112 either way.

So from Alice's point of= view, when she goes to the badge office to pick up her badge, she scans a = QR code with her phone and that is it - she is all configured for email, ch= at, slack, slick, ssh, S/MIME and all the encrypted data she needs from the= cloud. If she is working on some really sensitive stuff, her line manager = or a VP might need to meet her in person to authorize adding her to certain= groups.

Termination shou= ld mean no more than unchecking the boxes.


The cryptography I am using was discovered by Torben Pedersen and M= att Blaze in the mid 1990s. The reason it hasn't been applied was that = it was too hard to use and until Robert Snowden came along, people thought = the administrator of the key service in the cloud could be trusted. So I ha= ve made it really easy to use and administrate even in the case that we hav= e separation of duties at the administrator level as well.


On Thu, Jul 18, 2019= at 10:12 AM Paul E. Jones <paulej=3D40packetizer.com@dmarc.ietf.org> wrote:
Dave,

RFC 6186 i= s the DNS-based one to which I referred below. Unfortunately, it doesn'= t allow setting various configuration options and wouldn't work at all = for my wife's use case where employees use different mail servers based= on the country in which they reside.

Paul


From: Dave Cridland <dave@cridland.net>
Sent: July 18, 2019 4:40:41 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>
Cc: "art@ietf= .org" <art@ie= tf.org>, "webfinger@ietf.org" <webfinger@ietf.org>
Subject: Re: [art] Auto-configuring Email Clients via WebFinger

Obviously I'd prefer ACAP.

But also= , please note the existence of RFC 6186. It's not widely deployed, but = if we were to open this can of worms, and not simply reuse Thunderbird'= s autoconfig XML format (which, if I recall, is also supported by various o= ther Open Source MUAs), then I'd be keen to get SRV up and running prop= erly.

Dave.

On Mon, 15 Jul 2019 at 20:31, Pau= l E. Jones <paulej=3D40packetizer.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
ART folks,

Several years ago when I was working on = WebFinger, one of the use cases I presented was using WebFinger to facilita= te auto-configuring email clients.=C2=A0 It was and still is a problem I de= al with today.

For my own family, I have to manual= ly configure several different clients on several different platforms for e= ach member of the family.=C2=A0 It's time consuming and really needs to= be made simpler.

My wife also has to deal with th= is issue where she works, because her company, while just 100 or so employe= es, has offices in two different countries and the mail server settings an = employee uses depends on his or her geographic location.=C2=A0 To use stand= ard IETF protocols, it means a lot of manual provisioning.

I see the same sort of challenges with service providers. If one w= ants to have his or her own domain, but isn't technically savvy, they&#= 39;re in for a lot of "fun" trying to figure out the various sett= ings. Seriously, no normal person should have to understand what SMTP or IM= AP means, and definitely what port numbers or security settings to fill in.=

While there has been a generic DNS-based method f= or email provision for a while, it doesn't work for me. It doesn't = work for my wife's company, either. It also doesn't define everythi= ng one might need to define (e.g., required security settings or policies).=

So we put together a very simple example to show = how this might be done with WebFinger.=C2=A0 See the draft here:

The example in that = document should make it clear how we intend this to work, though the detail= ed procedures and syntax are missing.=C2=A0 We first want to see what inter= est exists and if this general approach will work for everyone before getti= ng into too much detail.

We'd love to have som= e dialog on this to see how we can address this problem of auto-configuring= email clients.

Paul

___= ____________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--000000000000b1d5e2058df6bef9-- From nobody Fri Jul 19 01:21:15 2019 Return-Path: X-Original-To: webfinger@ietfa.amsl.com Delivered-To: webfinger@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C3712015F for ; Fri, 19 Jul 2019 01:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 VcOtH42HH6AT for ; Fri, 19 Jul 2019 01:21:03 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C071201A2 for ; Fri, 19 Jul 2019 01:21:02 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id k8so33701539edr.11 for ; Fri, 19 Jul 2019 01:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LtRN1JhCsfjD3fJJtvF8I8J3SaZ4PrypSzuULm4HbWo=; b=XDcuaLeaSE4dbCydDmC32UiSJ7n6ptm5HnbAghnY9NG3a+QCTs+nzPYfre7V7OI10b JVI1U4n8n4JrTK3yFp2xrf79pZFbZtfvL2EHa8sINcoZFU+t8r6KiZCivgrNyKS4twVI pc8c8JFbBUGa6eGFkXMNZ/zCCgV02ZXRUoA/U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LtRN1JhCsfjD3fJJtvF8I8J3SaZ4PrypSzuULm4HbWo=; b=Ao3dg28iaqMcMEG3M/+cy94ynUMscJu2z9FhoKqBQ+7RakGK7TzqK+kqZM833mk+HL v13oFrN3nFkaXzKOE3aBo6UkVb7Ab3lyjsnNMYWnzU1RnRVPMAdxHGbhX2l+akU0IzLD f9a7g+0CP6lh/icCrxxBs5frjq6Hnwdi0fboDG9z+0BYx+d+Cem0QF4pLVCNJU/PLt+m fQT2xQX6bbWp/+u62wCKKaOKdVL7VJLP6WRjIdPxqgiLBaxN33sUh+AsjH3oahhJsWFi qGyu0iUCyU8jCjuCdcAipCHl3h5zZ6elkEZRvRXhSMUSusAlLvW9xQpIsDN7rwiUm5+8 7sGQ== X-Gm-Message-State: APjAAAVLhada3OyKcOmxsFc5YQ8IQ9Eyo4z0j743QY+PS1iByhjlXKc2 j6/BB7EfAC+QLKOAVerVhaTJZF3yF/h+OWJRWFDBKA== X-Google-Smtp-Source: APXvYqxLsX7O+m0IlKXFwDIx8AwzJHPGHUlSuU/R91VqpvlvEnIIhEEuHQb83BK2nYCwOw4aXvr8QIe3vEL49PtflLg= X-Received: by 2002:a05:6402:1557:: with SMTP id p23mr6278739edx.207.1563524461254; Fri, 19 Jul 2019 01:21:01 -0700 (PDT) MIME-Version: 1.0 References: <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com> In-Reply-To: <4BB105E1-0973-4416-8C2A-A729CD869C8A@packetizer.com> From: Dave Cridland Date: Fri, 19 Jul 2019 09:20:50 +0100 Message-ID: To: "Paul E. Jones" Cc: "art@ietf.org" , "webfinger@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001c6efb058e046816" Archived-At: Subject: Re: [webfinger] [art] Auto-configuring Email Clients via WebFinger X-BeenThere: webfinger@ietf.org X-Mailman-Version: 2.1.29 Precedence: list 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: Fri, 19 Jul 2019 08:21:05 -0000 --0000000000001c6efb058e046816 Content-Type: text/plain; charset="UTF-8" On Thu, 18 Jul 2019 at 15:12, Paul E. Jones wrote: > RFC 6186 is the DNS-based one to which I referred below. Unfortunately, it > doesn't allow setting various configuration options and wouldn't work at > all for my wife's use case where employees use different mail servers based > on the country in which they reside. > I'm not saying that additional information isn't needed, but it'd be nice to be able to use SRV alongside. I'd expect SRV to be used on every connection, whereas an auto configuration file would be used less, potentially only on initial provision. The Thunderbird config would need to be adapted anyway; it's not easily extensible, due to not using XML namespaces, for one thing. Dave. --0000000000001c6efb058e046816 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000001c6efb058e046816--