From nobody Tue Feb 2 09:47:49 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E48C1B2DE6 for ; Tue, 2 Feb 2016 09:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 TK_7ccVPQ9J0 for ; Tue, 2 Feb 2016 09:47:43 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76DF21B2DD3 for ; Tue, 2 Feb 2016 09:47:43 -0800 (PST) Received: (qmail 26259 invoked from network); 2 Feb 2016 17:47:42 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Feb 2016 17:47:42 -0000 Date: 2 Feb 2016 17:47:20 -0000 Message-ID: <20160202174720.68095.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <56B0A14E.7040101@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] [appsdir] quick review needed: draft-ietf-drprive-edns0-padding-02.txt X-BeenThere: apps-discuss@ietf.org 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: Tue, 02 Feb 2016 17:47:44 -0000 >Can I get a volunteer to review this draft? I have read through it and checked it against RFC 6891. It defines a new EDNS0 option that is ignored on receipt, to provide the ability to randomize the size and contents of DNS packets to deter traffic analysis. I don't see any problems with it. A DNS server is already supposed to ignore ENDS0 options it doesn't understand, so barring implmentation bugs it's unlikely to cause compatibility problems. R's, John From nobody Tue Feb 2 12:09:43 2016 Return-Path: X-Original-To: apps-discuss@ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 822581B3098; Tue, 2 Feb 2016 12:09:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160202200940.17569.20247.idtracker@ietfa.amsl.com> Date: Tue, 02 Feb 2016 12:09:40 -0800 Archived-At: Cc: appsawg-chairs@ietf.org, apps-discuss@ietf.org, The IESG , barryleiba@gmail.com, draft-ietf-appsawg-http-problem@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] Protocol Action: 'Problem Details for HTTP APIs' to Proposed Standard (draft-ietf-appsawg-http-problem-03.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 20:09:40 -0000 The IESG has approved the following document: - 'Problem Details for HTTP APIs' (draft-ietf-appsawg-http-problem-03.txt) as Proposed Standard This document is the product of the ART Area General Applications Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/ Technical Summary This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs. Review and Consensus The document originally appeared as an individual submission in July of 2012 and went through some evolution resulting in several revisions before being adopted by APPSAWG about a year ago. It has been largely stable since then. There has been cross-development between APPSAWG participants and W3C TAG. Development has stabilized since its WGLC, and implementations have matured with little change to the document. Perhaps noteworthy with respect to consensus is that the participants of APPSAWG cover a broad area of applications, and only some focus on HTTP work. However, that smaller group does tend to be active and thorough when they take up a work item in their specific interest area. With that in mind, consensus on the current content appears to be solid rather than rough. One of the document authors is both HTTPBIS chair and also the IETF liaison to the W3C, so there has been ample airing of this proposal on both sides of that particular fence. Personnel Murray Kucherawy is the document shepherd. Barry Leiba is the responsible Area Director. From nobody Thu Feb 4 10:30:44 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B551ACC8C for ; Thu, 4 Feb 2016 10:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.906 X-Spam-Level: ** X-Spam-Status: No, score=2.906 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, T_DKIM_INVALID=0.01] autolearn=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 1h28j_EsfiSQ for ; Thu, 4 Feb 2016 10:30:41 -0800 (PST) Received: from postoffice.gristmillmedia.com (unknown [96.30.18.196]) (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 E30E31ACC89 for ; Thu, 4 Feb 2016 10:30:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From; bh=hyUiFcqp52cO4Chsd4Maas66/W6uA7JMEgXtCVbmB2c=; b=cIQZZIQvZb9HbXKo3rtSnUjRxO+mQj6xYZoHjCRBQz1IvJCn6U4OiG7Ap1d3BqF0SKcYlD0PYV X+kmPSUENnE2ap6JWE2FoekIoMmPKgvhx6h2/HWBJhdt+Jv747AGM8PncrJu8AkfFzEBb6HwU+VEG Wz68DxfhVRLFTFd/O+6yjBeX4MDh/B+h1FXNJfvzLFhuWI/BYj4r8VoGa7Fira4Bonvarkj1Epx7i Bys3AxtqvYhsBl55ntVT3NUutviDo7HA+HTS7F/iTS+AQvdYBRSN+ylFqRKki3buEKPo/vd5sJx2v eZ11Im1kmPcti+dDVbyi44ou33+jpEc0uPt2g==; Received: from 108-67-65-66.lightspeed.sntcca.sbcglobal.net ([108.67.65.66]:57761 helo=[192.168.1.77]) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from ) id 1aROfw-0007AC-8m for apps-discuss@ietf.org; Thu, 04 Feb 2016 13:30:40 -0500 From: Erik Wilde To: "apps-discuss@ietf.org application-layer protocols" Message-ID: <56B398CF.6080404@dret.net> Date: Thu, 4 Feb 2016 10:30:39 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [apps-discuss] the use of registries X-BeenThere: apps-discuss@ietf.org 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: Thu, 04 Feb 2016 18:30:42 -0000 hello. i have started working on a draft that talks about the use of registries. it seems that discussions about why to use them, when to use them, and how to use them, are a recurring topic. personally, i think registries are a fascinating topic because they are a "specification pattern" that occurs on all levels in the networking stack. in some cases, people like to argue that registries (at least on the app level) are a thing of the past and we don't need them anymore, and most often they give two reasons: - the way the current registries are operated is a bit antiquated and a more modern approach (such as wikis, or maybe something a bit more structured) makes more sense. - for the application level, URIs can always be safely used as identifiers, eliminating the need for controlled namespaces. without discussing the merits of those arguments, i thought that it may make sense to try to summarize why, when, and how registries are used and can be used. this kind of document can serve as a reference for spec authors to decide on the use of registries, and maybe it can also serve as a reference for developers who want to better understand why a registry has been established. i have submitted a first draft which contains "why", "when", and "how" sections, but definitely could be more complete, and also probably needs to look at other topics as well. https://tools.ietf.org/html/draft-wilde-registries-01 it would be great to get some initial feedback from this list. the two main questions i have are: - is writing up such a document a worthwhile thing to do? is it likely to result in a document that helps specification writers? - judging from the current outline, are there any glaring omissions, either on the top level (why/when/how), or one level down in those sections? thanks a lot and kind regards, dret. ps: https://github.com/dret/I-D/tree/master/registries is where the draft lives, please feel free to submit issues or PRs. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Sun Feb 7 14:45:55 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A6C1A6F39; Sun, 7 Feb 2016 14:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.707 X-Spam-Level: X-Spam-Status: No, score=0.707 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 6uQQ57Vu_fsm; Sun, 7 Feb 2016 14:45:50 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 8ABFF1A6F53; Sun, 7 Feb 2016 14:45:50 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u17MjmWm004471 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 17:45:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454885149; bh=0D/O2XStpPzyyu8iXnKIvygZtF0LYFXdic5dWjI6jYw=; h=From:To:Subject:Date:Reply-To; b=BC6HG5xsgdf+IIhq1Sxsuwtiyp4t3VctfnI/aYgf2m3UhxfFM/hyz1zY2QjDTrrQD bUzbouY07+3hxwac1zntGb+r9Y9qcf+iutlCqLat682LcwHldtQhar8wa8UG2XrUrA UVEESLDR0bP83fQ6uRFigX8SJgVS4kwHI+LfgXis= From: "Paul E. Jones" To: apps-discuss@ietf.org, webfinger@ietf.org Date: Sun, 07 Feb 2016 22:46:17 +0000 Message-Id: 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 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 17:45:49 -0500 (EST) Archived-At: Subject: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2016 22:45:52 -0000 Folks, When we undertook the work on WebFinger, one of the use cases we had in mind was the ability to allow an email client to automatically provision itself. What we wanted was for a user to be able to enter an email address and password and for the email client to be able to determine via WebFinger exactly what protocols to use, what ports, the name of the SMTP server, and the name of the POP3 or IMAP server (or both). We did not have that fully described and it conflicted with work that others were doing on a more general aggregated services configuration solution. Namely, draft-daboo-aggregated-service-discovery-03. Unfortunately, that work did not progress. Still, I personally am frustrated with entering configuration data into my mobile phone, tablets, desktop, and laptop every time I install a new email client or get a new device. It's only made worse when I have to repeat the process for every member of the family. So, I'd really like a solution to this problem. I don't think I'm alone in having this need (or having this frustration). Every hosting company has to articulate in detail how customers go about configuring email for their hosted domains. Many (perhaps all) Universities do the same for students so they can access email, with some going to great lengths to detail the steps needed to be taken for every OS platform, popular clients, etc. RFC 6186 exists and it addresses much of what I want, though client support is lacking. That begs the question of "why?" Would defining something that builds on WebFinger encourage client developers to add support? A couple of issues with RFC 6186 are: 1) Information about services is exposed to the world and some prefer to not expose the names of servers, ports, protocols, etc., especially internal ones to a company 2) It does not allow for user-specific configuration: the entire domain is set to use the same information Issue (2) is an issue with larger enterprises that associate users to specific servers, as opposed to having some intelligent load balancing mechanism. However, there are smaller companies with distributed offices and servers wherein some users are configured to use servers in one geography and others in another geography. Issue (2) also presents challenges with hosting providers. DNS services are independent of email services. So, when a configuration change is made to email, it has to be coordinated with the DNS side of the house. If we use WebFinger, it does couple the web server with email, but the DNS server never has to change. Further, no additional change is required to the WebFinger service operating at the root of the domain. Thus, changes to the email configuration can happen in the back-end without impact on users and can be used to reconfigure clients when back-end services change. I'd like to suggest we tackle this one narrow email provisioning problem using WebFinger, but want to get feedback before spending time drafting a formal proposal. The idea is basically this: * User enters paulej@example.com into the email client and email=20 password * Email client queries=20 https://example.com/.well-known/webfinger?resource=3Dacct%3Apaulej%40exampl= e.com * The client would look for a link with a rel value of, say, "email-configuration". This might look like this: { "rel" : "email-configuration", "href" : "https://email.example.com/user/paulej" } * The client would then query the above URI and receive a JSON document that we would define in this proposed spec that conveys the server configuration information, including server names for SMTP/IMAP/POP3, transport required (e.g., TCP or TLS), port numbers, login information (username "paulej" vs. email ID, possibly different passwords for each service, and a display name), etc. * The above resource would be password protected using the email ID and password assigned to the user, with the data conveyed over TLS The client could be configured to re-fetch this information from time-to-time, such as when the client starts, when stored credentials are rejected, or on demand. I'd like to hear your thoughts. Do others feel this could be a valuable specification? Are there client developers interested in helping to solve this problem and willing to implement something here? Paul From nobody Sun Feb 7 15:13:47 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051861A8777; Sun, 7 Feb 2016 15:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 WaaaDbPwXmwI; Sun, 7 Feb 2016 15:13:39 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B34B1A8776; Sun, 7 Feb 2016 15:13:39 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aSYWO-000NxF-RJ; Sun, 07 Feb 2016 18:13:36 -0500 Date: Sun, 07 Feb 2016 18:13:31 -0500 From: John C Klensin To: "Paul E. Jones" , apps-discuss@ietf.org, webfinger@ietf.org Message-ID: In-Reply-To: References: 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-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Sun, 07 Feb 2016 23:13:44 -0000 --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones" wrote: > Folks, > When we undertook the work on WebFinger, one of the use cases > we had in mind was the ability to allow an email client to > automatically provision itself. What we wanted was for a user > to be able to enter an email address and password and for the > email client to be able to determine via WebFinger exactly > what protocols to use, what ports, the name of the SMTP > server, and the name of the POP3 or IMAP server (or both). >... > Still, I personally am frustrated with entering configuration > data into my mobile phone, tablets, desktop, and laptop every > time I install a new email client or get a new device. It's > only made worse when I have to repeat the process for every > member of the family. So, I'd really like a solution to this > problem. >... > RFC 6186 exists and it addresses much of what I want, though > client support is lacking. That begs the question of "why?" > Would defining something that builds on WebFinger encourage > client developers to add support? > > A couple of issues with RFC 6186 are: > 1) Information about services is exposed to the world and > some prefer to not expose the names of servers, ports, > protocols, etc., especially internal ones to a company > 2) It does not allow for user-specific configuration: the > entire domain is set to use the same information Paul, I wonder whether it is time to revisit ACAP. Its predecessor, IMSP, was specifically designed for the types of email cases you describe and it and/or ACAP were supported in a reasonable range of mail clients. Use of a 6186 mechanism to locate an ACAP server that required authentication (and, where appropriate, user identification so different information could be delivered) before giving out information would seem to mitigate the two issues identified above and use of an existing protocol (DHCP might be another candidate but has, IMO, never really taken off for application-layer client configuration and has issues when used across WANs on the public Internet). It seems to me that upgrading something with which we have significant experience might be a better alternative than deciding Webfinger is the latest hammer with which to hit all nails, especially nails that are not specifically web-related and that such an approach might be more easily accepted. > I'd like to suggest we tackle this one narrow email > provisioning problem using WebFinger, but want to get feedback > before spending time drafting a formal proposal. See above. > The idea is basically this: > * User enters paulej@example.com into the email client and > email password > * Email client queries > https://example.com/.well-known/webfinger?resource=acct%3Apaul > ej%40example.com >... Given all of the discussions we have been having about security and privacy lately, if enterprises are, as you suggest, sensitive about giving out information about how they are configured, developing a new system that depends on email addresses as identifiers and passwords for authentication seems unwise at best. Of course, ACAP would need examination and probably upgrading for serious security as well, but... >... > I'd like to hear your thoughts. Do others feel this could be a > valuable specification? Are there client developers > interested in helping to solve this problem and willing to > implement something here? Again, see above. This isn't a strong pitch for ACAP, but is just a thought about the possibility of a well-known tool with which we have significant experience as an alternate starting point. john From nobody Sun Feb 7 15:22:23 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6771A8998 for ; Sun, 7 Feb 2016 15:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 TiCCqMiTNwhY for ; Sun, 7 Feb 2016 15:22:20 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969111A8997 for ; Sun, 7 Feb 2016 15:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Ylq/PE7nkW3IFhNaYI/ZJfQ6C/G4LpS+c4kp3S/hQVw=; b=VhP1nFELvN0Ohb6zSqD6h3UAEpmHUrCkRgDn+1gTVHPb8iUg9xF64PqaJEAWkk80JtGfCN8FhzMnbrJkEq/pi94PxkZt/w0jsJYcJx17Kxkk8Ml6DVaQYx3HeLk+pLzjEISRh45KLRC22O4LhEKEohtW99MjDQPORuaVHvZptOc=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51011 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aSYek-0005Wh-8p for apps-discuss@ietf.org; Sun, 07 Feb 2016 15:22:20 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_BAFC42BE-304D-424B-90A9-151C780BFBC6"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: Date: Sun, 7 Feb 2016 18:22:14 -0500 Message-Id: <72EAB04F-DD51-428A-93F8-8C8E3F673B4F@standardstrack.com> References: To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Sun, 07 Feb 2016 23:22:22 -0000 --Apple-Mail=_BAFC42BE-304D-424B-90A9-151C780BFBC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I would second the ACAP suggestion. Of course, we would need to translate ACAP from IMAP-friendly PDU=E2=80=99= s to XML so we can translate that to JSON and then to YAML, so we can = hit all of the PDU format buzzwords of the week. > On Feb 7, 2016, at 6:13 PM, John C Klensin wrote: >=20 >=20 >=20 > --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones" > wrote: >=20 >> Folks, >=20 >> When we undertook the work on WebFinger, one of the use cases >> we had in mind was the ability to allow an email client to >> automatically provision itself. What we wanted was for a user >> to be able to enter an email address and password and for the >> email client to be able to determine via WebFinger exactly >> what protocols to use, what ports, the name of the SMTP >> server, and the name of the POP3 or IMAP server (or both). >> ... >> Still, I personally am frustrated with entering configuration >> data into my mobile phone, tablets, desktop, and laptop every >> time I install a new email client or get a new device. It's >> only made worse when I have to repeat the process for every >> member of the family. So, I'd really like a solution to this >> problem. >> ... >> RFC 6186 exists and it addresses much of what I want, though >> client support is lacking. That begs the question of "why?" >> Would defining something that builds on WebFinger encourage >> client developers to add support? >>=20 >> A couple of issues with RFC 6186 are: >> 1) Information about services is exposed to the world and >> some prefer to not expose the names of servers, ports, >> protocols, etc., especially internal ones to a company >> 2) It does not allow for user-specific configuration: the >> entire domain is set to use the same information >=20 > Paul, I wonder whether it is time to revisit ACAP. Its > predecessor, IMSP, was specifically designed for the types of > email cases you describe and it and/or ACAP were supported in a > reasonable range of mail clients. Use of a 6186 mechanism to > locate an ACAP server that required authentication (and, where > appropriate, user identification so different information could > be delivered) before giving out information would seem to > mitigate the two issues identified above and use of an existing > protocol (DHCP might be another candidate but has, IMO, never > really taken off for application-layer client configuration and > has issues when used across WANs on the public Internet). It > seems to me that upgrading something with which we have > significant experience might be a better alternative than > deciding Webfinger is the latest hammer with which to hit all > nails, especially nails that are not specifically web-related > and that such an approach might be more easily accepted. >=20 >> I'd like to suggest we tackle this one narrow email >> provisioning problem using WebFinger, but want to get feedback >> before spending time drafting a formal proposal. >=20 > See above. >=20 >=20 >> The idea is basically this: >> * User enters paulej@example.com into the email client and >> email password >> * Email client queries >> https://example.com/.well-known/webfinger?resource=3Dacct%3Apaul >> ej%40example.com >> ... >=20 > Given all of the discussions we have been having about security > and privacy lately, if enterprises are, as you suggest, > sensitive about giving out information about how they are > configured, developing a new system that depends on email > addresses as identifiers and passwords for authentication seems > unwise at best. Of course, ACAP would need examination and > probably upgrading for serious security as well, but... >=20 >> ... >> I'd like to hear your thoughts. Do others feel this could be a >> valuable specification? Are there client developers >> interested in helping to solve this problem and willing to >> implement something here? >=20 > Again, see above. This isn't a strong pitch for ACAP, but is > just a thought about the possibility of a well-known tool with > which we have significant experience as an alternate starting > point. >=20 > john >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_BAFC42BE-304D-424B-90A9-151C780BFBC6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWt9GnAAoJEORoZaSQsc1I+BUQAICsw98VG+RfedoJcPlp+hIs fbXmahwUnWTktTjs+ss/XurOdmW16wFc+425CEE6fyg+dxc0bdhcRDFIT3BqcXde 4jn76JSAlWoPplXFMReLOPMwLWlcvF4sQ8yzBNaV8YU9RmmdEFL1Re+MxM3H6K04 RLTXR4XV+HD6WYs167iWD3drMA7qO6x6h0wzcIk3Svlwe2Jwnjq5ts2x3F48vBwr lu/+PHvq50XbH2Hfjbfzp9UeVz/AmkqnshPjy/lsYkcTmkI0yDnFu+vfZUt6cRBc Xjcwkn8jZap0N3VH2g6KZKT4r29aNTLdARqF0Z2IQoI3+81KBHQLlZmHfVsB70bM e+arBd32j2ZCtlU/wEbdlqWmkHLcpqUYgs69Q/9X7y9E9vGJex+EwgVe5gt6kKev TuiKkqbVVpDg8mAquMtaYmQElvXpI2IHLOj+5XqNxHNFXh49IWLm+cx0nllEvT1t rFObW8dXlu8M1qM1T/bk1Dj952WFEJrxTd0Z7uis+RAVVjRzT3kgJJM0zC8G++u4 aSC9Yqebyjjtv5+gsHsLvMvSMYCnR1YzTpxSnI7eh2OQMSO5zJVS1FXK2uQw9hYi EpanL1TpgJxYAqB/tNW0e+TRZ9cc0nJ8FUWbr4ncZh6b4866yZQLl4rx5ZGDahwY IHinEz3lixoMMdjCxy7R =4Pyl -----END PGP SIGNATURE----- --Apple-Mail=_BAFC42BE-304D-424B-90A9-151C780BFBC6-- From nobody Sun Feb 7 16:44:59 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901981A8733; Sun, 7 Feb 2016 16:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 dWbhYlT0_Kzv; Sun, 7 Feb 2016 16:44:54 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 279921A8732; Sun, 7 Feb 2016 16:44:54 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u180iqa6014083 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 19:44:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454892293; bh=9sABXvTC2p/ZRAkqSmHdXkXDjTtqsb5daTRhd8ZFqwg=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=N05eDZMyPqK/Jz6EPdDQTwgDTy+zgSxw3JkaBmtSqKRvM3XJcBxzTGrIPhpv99k9C AGOyWLXSnA7JX1QtxLSmzKSrOd4FVj/ZN09geZnBL3tD3nC9zhjpkT1xS5l4JwRvcn f/fgIAxqsK74DWSR36zHBPPPAKuaX6Gik1cb+iPQ= From: "Paul E. Jones" To: "John C Klensin" , apps-discuss@ietf.org, webfinger@ietf.org Date: Mon, 08 Feb 2016 00:45:20 +0000 Message-Id: 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 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 19:44:53 -0500 (EST) Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 00:44:56 -0000 John, >> When we undertook the work on WebFinger, one of the use cases >> we had in mind was the ability to allow an email client to >> automatically provision itself. What we wanted was for a user >> to be able to enter an email address and password and for the >> email client to be able to determine via WebFinger exactly >> what protocols to use, what ports, the name of the SMTP >> server, and the name of the POP3 or IMAP server (or both). >>... >> Still, I personally am frustrated with entering configuration >> data into my mobile phone, tablets, desktop, and laptop every >> time I install a new email client or get a new device. It's >> only made worse when I have to repeat the process for every >> member of the family. So, I'd really like a solution to this >> problem. >>... >> RFC 6186 exists and it addresses much of what I want, though >> client support is lacking. That begs the question of "why?" >> Would defining something that builds on WebFinger encourage >> client developers to add support? >> >> A couple of issues with RFC 6186 are: >> 1) Information about services is exposed to the world and >> some prefer to not expose the names of servers, ports, >> protocols, etc., especially internal ones to a company >> 2) It does not allow for user-specific configuration: the >> entire domain is set to use the same information > >Paul, I wonder whether it is time to revisit ACAP. Its >predecessor, IMSP, was specifically designed for the types of >email cases you describe and it and/or ACAP were supported in a >reasonable range of mail clients. Use of a 6186 mechanism to >locate an ACAP server that required authentication (and, where >appropriate, user identification so different information could >be delivered) before giving out information would seem to >mitigate the two issues identified above and use of an existing >protocol (DHCP might be another candidate but has, IMO, never >really taken off for application-layer client configuration and >has issues when used across WANs on the public Internet). It I'm not opposed to revisiting anything, but what will it take to see=20 something actually deployed? ACAP is not a trivial protocol and it's=20 scope is broad. I'm not even aware of any client implementations today=20 and I've only seen some historical server implementations. Nonetheless,= =20 I'm not opposed to any solution that people will actually get behind and= =20 make happen. I would not recommend DHCP, because this is useful for hosting=20 providers. It's even not very useful for many enterprises, since not=20 everyone is behind the corporate firewall. >seems to me that upgrading something with which we have >significant experience might be a better alternative than >deciding Webfinger is the latest hammer with which to hit all >nails, especially nails that are not specifically web-related >and that such an approach might be more easily accepted. WebFinger is merely a defined place to go query via HTTPS to get a JSON=20 object that contains pointers to whatever data we're seeking, along with= =20 a specific syntax for what those pointers look like. Most of the world=20 has infinitely more experience with an HTTP GET request than virtually=20 anything else and processing a JSON object is a pretty trivial exercise.= =20 WebFinger is used for a few applications, though in only one standard = I=20 know at present: OpenID Connect. So, it's not quite the hammer you=20 suggest it is. However, it was designed specifically for discovering=20 information like this, not knowing anything but a "subject" and a=20 domain. Given we're just talking about a couple of HTTP queries, I=20 think the barrier to acceptance is going to be lower than most other=20 solutions we might devise. >> The idea is basically this: >> * User enters paulej@example.com into the email client and >> email password >> * Email client queries >> https://example.com/.well-known/webfinger?resource=3Dacct%3Apaul >> ej%40example.com >>... > >Given all of the discussions we have been having about security >and privacy lately, if enterprises are, as you suggest, >sensitive about giving out information about how they are >configured, developing a new system that depends on email >addresses as identifiers and passwords for authentication seems >unwise at best. Of course, ACAP would need examination and >probably upgrading for serious security as well, but... I am willing to bet that the majority of independent domain operators,=20 hosting providers, etc. will continue to use the username/password=20 combination for a very long time. That said, WebFinger (by virtue of=20 the fact it is nothing more than an HTTPS query) can use any HTTP-based=20 authentication scheme we want, including certificates,=20 username/passwords, or whatever else we night propose. I only suggest=20 username/password, as I have yet to personally encounter use of anything= =20 else. Whatever solution we devise that replaces the username/password,=20 though, will be supported in HTTP and, therefore, WebFinger. >>... >> I'd like to hear your thoughts. Do others feel this could be a >> valuable specification? Are there client developers >> interested in helping to solve this problem and willing to >> implement something here? > >Again, see above. This isn't a strong pitch for ACAP, but is >just a thought about the possibility of a well-known tool with >which we have significant experience as an alternate starting >point. If ACAP was going to take off, I think it would have by now. It did not= =20 and I doubt it will, but I'm absolutely not opposed if we were to=20 somehow get a bunch of major client developers on board. We'd need some= =20 server software that is well-supported, too. We either have to resign=20 to the fact that it's not going to solve the problem I think we should=20 solve, that nobody cares to solve this problem, or that we need=20 something simpler (e.g., a couple of HTTP queries to get config info). Paul From nobody Sun Feb 7 17:45:51 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED71A884C; Sun, 7 Feb 2016 17:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tK54vJC5czbD; Sun, 7 Feb 2016 17:45:47 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1441A884B; Sun, 7 Feb 2016 17:45:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5ED80BE4C; Mon, 8 Feb 2016 01:45:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlSyzNEYqKGn; Mon, 8 Feb 2016 01:45:43 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.42.24.160]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FCDBBE3F; Mon, 8 Feb 2016 01:45:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454895943; bh=W75Yno5oosrpzjvJh6bk59+5BGa9yHHVMP2qfQHekEc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=st4R4alWv9OCUraR9TSjR950umlsXNSPHEAbKGxF1BD5YjigOVH20kq4RYmLEwhBK uQiiuR1EURZ9BPjR13+E4Bd6GNk6nThJM7h+AZN6RDgRgfAEEKolaeI5zm8S4qqtsQ rC07GqSVAI7eIabqP79ZL5zbX6oKF7xVQcMHSAWI= To: "Paul E. Jones" , John C Klensin , apps-discuss@ietf.org, webfinger@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B7F345.9060505@cs.tcd.ie> Date: Mon, 8 Feb 2016 01:45:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 01:45:49 -0000 On 08/02/16 00:45, Paul E. Jones wrote: > > If ACAP was going to take off, I think it would have by now. That seems correct to me. I think solving this problem in isolation would be worthwhile if folks deployed a solution. (IOW, let's not generalise too much.) My own ask here is that the user not be expected to enter a password until after whatever automatable checks can be done, have been done. I really hate entering a password into a new device before I've gotten any feedback that that device is not going to send the password in clear over the network. And yes that may be a minority concern, but it is still I think one we ought not ignore, esp. as it should be quite possible to encourage good behaviour here (it's as easy as encouraging bad behaviour;-) S. From nobody Sun Feb 7 17:56:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643CB1A89FD; Sun, 7 Feb 2016 17:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtMkU0e4kb21; Sun, 7 Feb 2016 17:56:03 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 31E251A8872; Sun, 7 Feb 2016 17:56:03 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u181txaX020054 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Feb 2016 20:56:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1454896560; bh=N6seHTmtDd6J3hF2vP1dDCeMOGuiPIxWNC/kjIF838E=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=OYxeAJP7RJkoovu4ZIzuWlml/9oe9Ia75EKdQvM4l9Mw/WTMmEOSsnw5JWrbYnNP0 OLUnb2DcktpHxFedsqw1WX45RjHQA4Bqb+lzYKuonPwYxF9pHNoFihEG/+VB7zl0tz iEkNTOnEGQi2lvvvkRpqZSfVPcBuS9H90lZJ8Pj4= From: "Paul E. Jones" To: "Stephen Farrell" , "John C Klensin" , apps-discuss@ietf.org, webfinger@ietf.org Date: Mon, 08 Feb 2016 01:56:28 +0000 Message-Id: In-Reply-To: <56B7F345.9060505@cs.tcd.ie> 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 (dublin.packetizer.com [10.109.150.103]); Sun, 07 Feb 2016 20:56:00 -0500 (EST) Archived-At: Subject: Re: [apps-discuss] [webfinger] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 01:56:04 -0000 Stephen, >On 08/02/16 00:45, Paul E. Jones wrote: >> >> If ACAP was going to take off, I think it would have by now. > >That seems correct to me. > >I think solving this problem in isolation would be worthwhile >if folks deployed a solution. (IOW, let's not generalise too >much.) > >My own ask here is that the user not be expected to enter a >password until after whatever automatable checks can be done, >have been done. I really hate entering a password into a new >device before I've gotten any feedback that that device is not >going to send the password in clear over the network. And yes >that may be a minority concern, but it is still I think one >we ought not ignore, esp. as it should be quite possible to >encourage good behaviour here (it's as easy as encouraging >bad behaviour;-) In the case of WebFinger, all requests go over HTTPS only. That said, I= =20 think your suggestion is a good one. It's entirely possible that the=20 authentication mechanism might not be password based and we won't know=20 what that is until the query is made to the server hosting the=20 configuration document. Paul From nobody Sun Feb 7 19:00:37 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BA61A8A99 for ; Sun, 7 Feb 2016 19:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.873 X-Spam-Level: X-Spam-Status: No, score=0.873 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 v6Ur3klqjOSH for ; Sun, 7 Feb 2016 19:00:34 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943141A8A9B for ; Sun, 7 Feb 2016 19:00:34 -0800 (PST) Received: (qmail 89252 invoked from network); 8 Feb 2016 03:00:32 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Feb 2016 03:00:32 -0000 Date: 8 Feb 2016 03:00:10 -0000 Message-ID: <20160208030010.88340.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 03:00:36 -0000 >Paul, I wonder whether it is time to revisit ACAP. I see your point, but I think the answer is no. The only ACAP implementation I can find is one that Dave Cridland put on github in 2014, with a note saying it's work he did a decade earlier and it was extremely difficult to implement. There might be one in the commercial Communigate MTA which wouldn't surprise me because Mr. Communigate is the kind of guy who implements everything just to be complete, but if it exists, it's proprietary. I don't see any ACAP client libraries other than one that looks like an abandoned Java implementation from 2007. >> The idea is basically this: >> * User enters paulej@example.com into the email client and email password >> * Email client queries >> https://example.com/.well-known/webfinger?resource=acct%3Apaulej%40example.com Looking at the success of RDAP, it seems to be a good idea to put together pieces that people already have implemented. RDAP is easy because we already have https query libraries and JSON decoding libraries, and I'd say this would be too. For this application, I'd put in an extra level of indirection with an SRV or URI lookup, since many (most?) domains have their mail servers far away from the web servers, and the SRV or URI would give you some confidence that the server you were talking to would understand the question you were asking. I think the security issues are manageable. An https request with some sort of verification of the server certificate is more secure than what nearly all MUAs do to verify their imap and pop servers now. R's, John From nobody Mon Feb 8 00:16:07 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3241ACD39 for ; Mon, 8 Feb 2016 00:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VMXc39LD8A7z for ; Mon, 8 Feb 2016 00:16:04 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 494681ACD48 for ; Mon, 8 Feb 2016 00:16:04 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id 128so144067862wmz.1 for ; Mon, 08 Feb 2016 00:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jVQ7R4ahe+nt3LAhL1fYYyobR7LfDcFyTFRqhj4XbP4=; b=bzMSOA1fbWpBiMNCzVmaJT3xVsY6RBq+a8csAkemDUxrbk6DAjkU2QpKgjlSDNXstK xP4D8wIcInRGXTG7lVmViNRz78O9BlnNXg5ZBkGxNsGM4Mz/Z83OsBFzpA29d8FQ9YSJ 2r6SyaZFX37DEzi6t6y5rz4kdqbKg0/n6Aulo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jVQ7R4ahe+nt3LAhL1fYYyobR7LfDcFyTFRqhj4XbP4=; b=ki6uijdoidSETsXrZQmJSSIS/gt0au4Lh7OShPWTAUQtootK6rG/N2TZEI/dxus9wc jmv2812ed2WVeQqoUrqSd7E1GmWJ8KCep5fZF34apZCGAKwDaljC45bBciOyM8cEzI9b 0w2X8E+OyEsxC38WMbnwNeT3QWyme/OJNoSCFUINKn+W9PNV1fMe4mXyVwHqKPCgwYKY dOLJrUpLBryStplgdoAPSDAaig5SGoHEHOAiQIHss7QgMvGRJXatyGvWxJPJMs6XVTQ9 xp5y9sID/+TpkPy9nVl1xbbTqE0FA6zQG3PSSdZckQI2rK/33mbo6UHPCzWjk7C2wj+s u4nw== X-Gm-Message-State: AG10YORpGiySMAVgWRlACfOGok1xUls6GeDovRg7QYqv2236qhP20JDnwfE6t018KIGmc8VAsuBn0QdF8BSQq3zV MIME-Version: 1.0 X-Received: by 10.28.179.84 with SMTP id c81mr50028363wmf.30.1454919362802; Mon, 08 Feb 2016 00:16:02 -0800 (PST) Received: by 10.28.47.151 with HTTP; Mon, 8 Feb 2016 00:16:02 -0800 (PST) In-Reply-To: <20160208030010.88340.qmail@ary.lan> References: <20160208030010.88340.qmail@ary.lan> Date: Mon, 8 Feb 2016 08:16:02 +0000 Message-ID: From: Dave Cridland To: John Levine Content-Type: multipart/alternative; boundary=001a1145392ccc140c052b3dcf1e Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 08:16:06 -0000 --001a1145392ccc140c052b3dcf1e Content-Type: text/plain; charset=UTF-8 On 8 February 2016 at 03:00, John Levine wrote: > >Paul, I wonder whether it is time to revisit ACAP. > > I see your point, but I think the answer is no. The only ACAP > implementation I can find is one that Dave Cridland put on github in > 2014, with a note saying it's work he did a decade earlier and it was > extremely difficult to implement. There's also two CMU implementations, one in OCAML I think, and the other in C++. The former one works, but has issues; the latter one never did I think. I like to describe my implementation as the first working one. FWIW, much of the difficulty in implementation was my lack of experience in implementing publish/subscribe systems; I saw ACAP at the time as a kind of hierarchical database with these weird CONTEXT things; these days I think I'd implement it as a pub-sub system with a search function and probably get along better. In any case, ACAP has serious shortcomings - none of which are based on its syntax or essential capability. The primary issue is that the user on-boarding path has to start with an ACAP username and hostname. This derails everything else. > There might be one in the > commercial Communigate MTA which wouldn't surprise me because Mr. > Communigate is the kind of guy who implements everything just to be > complete, but if it exists, it's proprietary. I don't see any ACAP > client libraries other than one that looks like an abandoned Java > implementation from 2007. > The Communigate server is very limited in various interesting ways. As for libraries, I wrote one (and an entire MUA) in Python some time back. > > >> The idea is basically this: > >> * User enters paulej@example.com into the email client and email > password > >> * Email client queries > >> > https://example.com/.well-known/webfinger?resource=acct%3Apaulej%40example.com > > Looking at the success of RDAP, it seems to be a good idea to put > together pieces that people already have implemented. RDAP is easy > because we already have https query libraries and JSON decoding > libraries, and I'd say this would be too. > > For this application, I'd put in an extra level of indirection with an > SRV or URI lookup, since many (most?) domains have their mail servers > far away from the web servers, and the SRV or URI would give you some > confidence that the server you were talking to would understand the > question you were asking. > > I think the security issues are manageable. An https request with > some sort of verification of the server certificate is more secure > than what nearly all MUAs do to verify their imap and pop servers now. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a1145392ccc140c052b3dcf1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 8 February 2016 at 03:00, John Levine <johnl@taugh.com> wrote:
>Paul, I won= der whether it is time to revisit ACAP.

I see your point, but I think the answer is no.=C2=A0 The only ACAP<= br> implementation I can find is one that Dave Cridland put on github in
2014, with a note saying it's work he did a decade earlier and it was extremely difficult to implement.=C2=A0

The= re's also two CMU implementations, one in OCAML I think, and the other = in C++. The former one works, but has issues; the latter one never did I th= ink. I like to describe my implementation as the first working one.

FWIW, much of the difficulty in implementation was my lac= k of experience in implementing publish/subscribe systems; I saw ACAP at th= e time as a kind of hierarchical database with these weird CONTEXT things; = these days I think I'd implement it as a pub-sub system with a search f= unction and probably get along better.

In any case= , ACAP has serious shortcomings - none of which are based on its syntax or = essential capability.

The primary issue is that th= e user on-boarding path has to start with an ACAP username and hostname. Th= is derails everything else.
=C2=A0
There might be one in the
commercial Communigate MTA which wouldn't surprise me because Mr.
Communigate is the kind of guy who implements everything just to be
complete, but if it exists, it's proprietary.=C2=A0 I don't see any= ACAP
client libraries other than one that looks like an abandoned Java
implementation from 2007.

The Communiga= te server is very limited in various interesting ways.

=
As for libraries, I wrote one (and an entire MUA) in Python some time = back.
=C2=A0

>> The idea is basically this:
>>=C2=A0 =C2=A0* User enters pa= ulej@example.com into the email client and email password
>>=C2=A0 =C2=A0* Email client queries
>> https://exa= mple.com/.well-known/webfinger?resource=3Dacct%3Apaulej%40example.com
Looking at the success of RDAP, it seems to be a good idea to put together pieces that people already have implemented.=C2=A0 RDAP is easy because we already have https query libraries and JSON decoding
libraries, and I'd say this would be too.

For this application, I'd put in an extra level of indirection with an<= br> SRV or URI lookup, since many (most?) domains have their mail servers
far away from the web servers, and the SRV or URI would give you some
confidence that the server you were talking to would understand the
question you were asking.

I think the security issues are manageable.=C2=A0 An https request with
some sort of verification of the server certificate is more secure
than what nearly all MUAs do to verify their imap and pop servers now.

R's,
John

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss=

--001a1145392ccc140c052b3dcf1e-- From nobody Mon Feb 8 00:36:23 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885531ACD84 for ; Mon, 8 Feb 2016 00:36:22 -0800 (PST) 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] autolearn=ham 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 VGqcKjA8affZ for ; Mon, 8 Feb 2016 00:36:20 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49E61ACD85 for ; Mon, 8 Feb 2016 00:36:20 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 434F7FA007C; Mon, 8 Feb 2016 08:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1454920578; bh=UJ5VdOeZzGfOdewT1aKn2mTKutXaaJFzVI4/Ps1DgRs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZT8oey1+1ukuVucqACChpJVIYiAjzHuk/6mOBJC9uEd8ntC509QjpIZ8KiDUmG6jj 1wuSEkS23xRk57+FaCn4RgVCdQaPm9ITmiMACUisrj0Z6ZiOWNtdsNyfQrhA9EAvyD YVwYmKvrOu60qB2CQRFq+daY/Qr4l28V59fWmelI= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1454920577-28409-19604/11/5; Mon, 8 Feb 2016 08:36:17 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Mon, 8 Feb 2016 08:36:16 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: <13c2c0d0-60a6-4289-9a1d-df21bd43c5d8@gulbrandsen.priv.no> In-Reply-To: References: Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 08:36:22 -0000 John C Klensin writes: > Again, see above. This isn't a strong pitch for ACAP, but is > just a thought about the possibility of a well-known tool with > which we have significant experience as an alternate starting > point. I tried implementing ACAP in a client and suggest forgetting about it. Such is my experience. Arnt From nobody Mon Feb 8 00:42:18 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C551ACDA5 for ; Mon, 8 Feb 2016 00:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=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 9cTJSeSx_o1h for ; Mon, 8 Feb 2016 00:42:00 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 B470F1ACD9A for ; Mon, 8 Feb 2016 00:41:59 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id p63so104982407wmp.1 for ; Mon, 08 Feb 2016 00:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XaoGp6F6Vpjyv9pV1D8RU9/NrvwV2NEwt7qKJYzXhvI=; b=RIlNrIdyQc06aevnjetWKAjij7jrYHZDj9RinzPWwmE0HCiOxlLyDsBJfofsLwaEfj uPt2E86arCqbM56VEwLFNZ1ieKcf5qzyvZ1FcieEnoDP1vGpo3qti3VNtsAV/tOoTPlP 0Fvv72EhoZZWF4bu5szqVBTfCctwEH6R/QOVQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XaoGp6F6Vpjyv9pV1D8RU9/NrvwV2NEwt7qKJYzXhvI=; b=kfrC/iKSexbvURbIj54JHtIBXGwusGm39qEpG33U0L3KfokvgvZ2hYv0eawxjzC3rB 9SfdvXVw4AHz4/YVHDKAX5Nv15iR1aqrQZ/J1RiSslmlFiaY0TZb1kpnX8iudOLsdYs7 OpZWbieBtDv7+xctuGQnmkE9xZ1jzbA/ukPas/t7AmgL4EqTLrKNfrnLGY4S5pvEkZu+ iEO7DfwTplu1d1FU2arbIhhvTlloyW6Njlx9+J/AjrlC4wsbgmxrwoSCdFqNQ2k0CCsH 3pQ2yHs2WB6FmqN2TlIxwFfwC0fO80BkYd1VK/TnpVRjDIHS6LCsbnFxQ3RmTmkJCYrO q/ng== X-Gm-Message-State: AG10YOR5o/21lZKK5/uYd5iaL5iAj7ezkdLvuOn2hkBJEXVFRSo06BMsgFwQ4ctvotDYuZzdQg1XRkb2EkSW9ow6 MIME-Version: 1.0 X-Received: by 10.28.30.198 with SMTP id e189mr28057362wme.60.1454920918231; Mon, 08 Feb 2016 00:41:58 -0800 (PST) Received: by 10.28.47.151 with HTTP; Mon, 8 Feb 2016 00:41:58 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Feb 2016 08:41:58 +0000 Message-ID: From: Dave Cridland To: John C Klensin Content-Type: multipart/alternative; boundary=001a114b33de820c33052b3e2c83 Archived-At: Cc: "apps-discuss@ietf.org" , webfinger@ietf.org Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 08:42:02 -0000 --001a114b33de820c33052b3e2c83 Content-Type: text/plain; charset=UTF-8 John, I suspect that in this space, we run something of a risk of assuming the question is which hammer to use rather than deciding what nail we have. I'm mildly amused that criticisms of RFC 6186 are around exposure and per-user configuration, since I've never seen either be a problem - but we could, of course, declare these vital requirements. As a relative newcomer to email, having only spent a couple of decades on the subject, even I am well aware that there are as many niche requirements as grains of sand, and no solution will ever encompass them all. Instead, there are two extreme approaches we can usefully take, and there's middle ground as well: a) We prescribe a sane configuration. The MUA, given an email address, can programmatically determine the servers and authentication details without using the network. b) We define a discovery solution. The MUA uses network services to locate the servers and authentication details. An example of the middle-ground would be that we say servers should be able to use an email address as an authentication identifier, and that all services should use the same credentials, and that RFC 6186 records should be used for discovery. I think that just by adding RFC 6186 records, the vast majority of services will immediately work. (Many MUAs performing ad-hoc discovery essentially synthesize 6186 records where the MX is recognized, after all). If you want more, you'll need to add more infrastructure, and the costs here are quite high - especially since you need not only a new service at the server end, but changes in every client. There are, in existence, XCAP, ACAP, IMSP, and WebFinger in this space. You could also usefully add XMPP into the mix - it's never had problems with server discovery, the addresses and authorization identifiers it uses are compatible with the vast majority of email addresses out there, and it can provide a pub-sub based arbitrary data storage via its PEP functionality which is well deployed. Which one to use doesn't depend on syntax - though that might be, of course, a tie-breaker - it depends on exactly what user-experience we want to deliver. Dave. On 7 February 2016 at 23:13, John C Klensin wrote: > > > --On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones" > wrote: > > > Folks, > > > When we undertook the work on WebFinger, one of the use cases > > we had in mind was the ability to allow an email client to > > automatically provision itself. What we wanted was for a user > > to be able to enter an email address and password and for the > > email client to be able to determine via WebFinger exactly > > what protocols to use, what ports, the name of the SMTP > > server, and the name of the POP3 or IMAP server (or both). > >... > > Still, I personally am frustrated with entering configuration > > data into my mobile phone, tablets, desktop, and laptop every > > time I install a new email client or get a new device. It's > > only made worse when I have to repeat the process for every > > member of the family. So, I'd really like a solution to this > > problem. > >... > > RFC 6186 exists and it addresses much of what I want, though > > client support is lacking. That begs the question of "why?" > > Would defining something that builds on WebFinger encourage > > client developers to add support? > > > > A couple of issues with RFC 6186 are: > > 1) Information about services is exposed to the world and > > some prefer to not expose the names of servers, ports, > > protocols, etc., especially internal ones to a company > > 2) It does not allow for user-specific configuration: the > > entire domain is set to use the same information > > Paul, I wonder whether it is time to revisit ACAP. Its > predecessor, IMSP, was specifically designed for the types of > email cases you describe and it and/or ACAP were supported in a > reasonable range of mail clients. Use of a 6186 mechanism to > locate an ACAP server that required authentication (and, where > appropriate, user identification so different information could > be delivered) before giving out information would seem to > mitigate the two issues identified above and use of an existing > protocol (DHCP might be another candidate but has, IMO, never > really taken off for application-layer client configuration and > has issues when used across WANs on the public Internet). It > seems to me that upgrading something with which we have > significant experience might be a better alternative than > deciding Webfinger is the latest hammer with which to hit all > nails, especially nails that are not specifically web-related > and that such an approach might be more easily accepted. > > > I'd like to suggest we tackle this one narrow email > > provisioning problem using WebFinger, but want to get feedback > > before spending time drafting a formal proposal. > > See above. > > > > The idea is basically this: > > * User enters paulej@example.com into the email client and > > email password > > * Email client queries > > https://example.com/.well-known/webfinger?resource=acct%3Apaul > > ej%40example.com > >... > > Given all of the discussions we have been having about security > and privacy lately, if enterprises are, as you suggest, > sensitive about giving out information about how they are > configured, developing a new system that depends on email > addresses as identifiers and passwords for authentication seems > unwise at best. Of course, ACAP would need examination and > probably upgrading for serious security as well, but... > > >... > > I'd like to hear your thoughts. Do others feel this could be a > > valuable specification? Are there client developers > > interested in helping to solve this problem and willing to > > implement something here? > > Again, see above. This isn't a strong pitch for ACAP, but is > just a thought about the possibility of a well-known tool with > which we have significant experience as an alternate starting > point. > > john > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a114b33de820c33052b3e2c83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John,

I suspect that in this space, we = run something of a risk of assuming the question is which hammer to use rat= her than deciding what nail we have.

I'm mildl= y amused that criticisms of RFC 6186 are around exposure and per-user confi= guration, since I've never seen either be a problem - but we could, of = course, declare these vital requirements. As a relative newcomer to email, = having only spent a couple of decades on the subject, even I am well aware = that there are as many niche requirements as grains of sand, and no solutio= n will ever encompass them all.

Instead, there are= two extreme approaches we can usefully take, and there's middle ground= as well:

a) We prescribe a sane configuration.

The MUA, given an email address, can programmaticall= y determine the servers and authentication details without using the networ= k.

b) We define a discovery solution.
The MUA uses network services to locate the servers and authen= tication details.

An example of the middle-ground = would be that we say servers should be able to use an email address as an a= uthentication identifier, and that all services should use the same credent= ials, and that RFC 6186 records should be used for discovery. I think that = just by adding RFC 6186 records, the vast majority of services will immedia= tely work. (Many MUAs performing ad-hoc discovery essentially synthesize 61= 86 records where the MX is recognized, after all).

If you want more, you'll need to add more infrastructure, and the cost= s here are quite high - especially since you need not only a new service at= the server end, but changes in every client.

Ther= e are, in existence, XCAP, ACAP, IMSP, and WebFinger in this space.

You could also usefully add XMPP into the mix - it's = never had problems with server discovery, the addresses and authorization i= dentifiers it uses are compatible with the vast majority of email addresses= out there, and it can provide a pub-sub based arbitrary data storage via i= ts PEP functionality which is well deployed.

Which= one to use doesn't depend on syntax - though that might be, of course,= a tie-breaker - it depends on exactly what user-experience we want to deli= ver.

Dave.
On 7 February 2016 at 23:13, John C Klensin <= john-ietf@jck.com> wrote:
<= br>
--On Sunday, February 07, 2016 22:46 +0000 "Paul E. Jones"
<paulej@packetizer.com> = wrote:

> Folks,

> When we undertook the work on WebFinger, one of the use cases
> we had in mind was the ability to allow an email client to
> automatically provision itself.=C2=A0 What we wanted was for a user > to be able to enter an email address and password and for the
> email client to be able to determine via WebFinger exactly
> what protocols to use, what ports, the name of the SMTP
> server, and the name of the POP3 or IMAP server (or both).
>...
> Still, I personally am frustrated with entering configuration
> data into my mobile phone, tablets, desktop, and laptop every
> time I install a new email client or get a new device.=C2=A0 It's<= br> > only made worse when I have to repeat the process for every
> member of the family.=C2=A0 So, I'd really like a solution to this=
> problem.
>...
> RFC 6186 exists and it addresses much of what I want, though
> client support is lacking.=C2=A0 That begs the question of "why?&= quot;
> Would defining something that builds on WebFinger encourage
> client developers to add support?
>
> A couple of issues with RFC 6186 are:
>=C2=A0 =C2=A0 1) Information about services is exposed to the world and=
> some prefer to not expose the names of servers, ports,
> protocols, etc., especially internal ones to a company
>=C2=A0 =C2=A0 2) It does not allow for user-specific configuration: the=
> entire domain is set to use the same information

Paul, I wonder whether it is time to revisit ACAP.=C2=A0 Its
predecessor, IMSP, was specifically designed for the types of
email cases you describe and it and/or ACAP were supported in a
reasonable range of mail clients.=C2=A0 Use of a 6186 mechanism to
locate an ACAP server that required authentication (and, where
appropriate, user identification so different information could
be delivered) before giving out information would seem to
mitigate the two issues identified above and use of an existing
protocol (DHCP might be another candidate but has, IMO, never
really taken off for application-layer client configuration and
has issues when used across WANs on the public Internet).=C2=A0 It
seems to me that upgrading something with which we have
significant experience might be a better alternative than
deciding Webfinger is the latest hammer with which to hit all
nails, especially nails that are not specifically web-related
and that such an approach might be more easily accepted.

> I'd like to suggest we tackle this one narrow email
> provisioning problem using WebFinger, but want to get feedback
> before spending time drafting a formal proposal.

See above.


> The idea is basically this:
>=C2=A0 =C2=A0* User enters paulej= @example.com into the email client and
> email password
>=C2=A0 =C2=A0* Email client queries
> https://example.com/.well-known= /webfinger?resource=3Dacct%3Apaul
> ej%40example.com
>...

Given all of the discussions we have been having about security
and privacy lately, if enterprises are, as you suggest,
sensitive about giving out information about how they are
configured, developing a new system that depends on email
addresses as identifiers and passwords for authentication seems
unwise at best.=C2=A0 Of course, ACAP would need examination and
probably upgrading for serious security as well, but...

>...
> I'd like to hear your thoughts. Do others feel this could be a
> valuable specification?=C2=A0 Are there client developers
> interested in helping to solve this problem and willing to
> implement something here?

Again, see above.=C2=A0 This isn't a strong pitch for ACAP, but is
just a thought about the possibility of a well-known tool with
which we have significant experience as an alternate starting
point.

=C2=A0 =C2=A0 =C2=A0john


_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss=

--001a114b33de820c33052b3e2c83-- From nobody Mon Feb 8 06:55:06 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A7A1B2C8F; Mon, 8 Feb 2016 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 F1VBbOeWA89w; Mon, 8 Feb 2016 06:55:02 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E121B2C88; Mon, 8 Feb 2016 06:55:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 83C65337E3F8; Mon, 8 Feb 2016 09:54:59 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V7TnEtz7TFR; Mon, 8 Feb 2016 09:54:59 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 7E1A1337E3E5; Mon, 8 Feb 2016 09:54:58 -0500 (EST) Date: Mon, 08 Feb 2016 09:54:56 -0500 From: Cyrus Daboo To: "Paul E. Jones" , John C Klensin , apps-discuss@ietf.org, webfinger@ietf.org Message-ID: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=4847 Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 14:55:05 -0000 Hi, --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" wrote: > If ACAP was going to take off, I think it would have by now. It did not > and I doubt it will, but I'm absolutely not opposed if we were to somehow > get a bunch of major client developers on board. We'd need some server > software that is well-supported, too. We either have to resign to the > fact that it's not going to solve the problem I think we should solve, > that nobody cares to solve this problem, or that we need something > simpler (e.g., a couple of HTTP queries to get config info). As one of the few people who implemented ACP/IMSP and all of that stack I have to say ACAP's time has been and gone. It was way too complicated to implement at the time and nothing has changed. The same could be said of the IETF's original calendaring server effort - CAP (RFC4324) - and in the end a number of people took a more pragmatic approach of building a calendaring protocol using existing technology (HTTP/WebDAV) resulting in CalDAV (RFC4791) that has (at least from my standpoint) been pretty successful. As it turns out I replaced use of IMSP/ACAP in my mail/calendar/contacts client with a simple WebDAV solution - storing preferences on my personal WebDAV share. For the most part that has worked well and is trivial to implement - most of the short comings could be fixed through use of more modern capabilities - likely a JSON solution using HTTP PATCH (RFC5789) and JSON patch/merge (RFC7396). All that said, I do believe that the client account configuration setup is something that needs to be addressed. Indeed I tried to start such an effort at the IETF (via the AppsArea WG) and number of years ago. That was based on work done at the Calendaring and Scheduling Consortium (a group of users and vendors who recognised the need for a common configuration piece). At the time we titled that work "Aggregated Service Discovery" (which morphed into "Automated Service Configuration" (ASCOT) and the last draft for that (now expired) can be found here: . That draft used a webfinger-based lookup of a "service configuration document" that could list all relevant accounts a service provider had available for a user. At the time that work stalled partly because there was push back at the BoFs about the scope of the work, and because the stake holders ended up with other priorities that took precedence. Paul and I had an exchange about this prior to him starting this thread, and he felt new work on this should be tightly focussed on just email. I personally believe we need to solve the problem for multiple services, not just one. For email, calendaring and contacts we do currently have a light weight SRV-based account provisioning solution (RFC6186, RFC6764), which works on a per service basis (i.e., one set of requests for each account type). The calendaring/contacts piece of that has been deployed and used by a number of providers and clients. Unfortunately, the email piece has not - a number of major ISP do publish _imaps etc SRV records, but very few, if any, clients make use of that. I also think that since the original ASCOT work, the world has started moving in a slightly different direction - specifically more towards a device management solution. With the wild propagation of mobile devices into the enterprise a number of device management solutions are now available that allow configuring of not only accounts, but provisioning of settings (password policy, VPN certs etc) and applications, documents etc,. These solutions are fairly wide spread in enterprise environments today. Less so in the "personal" device scenario. 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. 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. PS As it turns out I use a device management tool (one available from my employer - Apple) for managing all my family devices, which includes the ability to push profiles specific to my kids devices for locking down parental control settings and the like. -- Cyrus Daboo From nobody Mon Feb 8 07:43:41 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210741B2D47 for ; Mon, 8 Feb 2016 07:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 yImkmUuLNdpf for ; Mon, 8 Feb 2016 07:43:38 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F83D1B2D4D for ; Mon, 8 Feb 2016 07:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=SVFuMc7JX01xlTn+o9Bp7nK4uEz2/hQHumnkimgjBAg=; b=RRz8FSnN06IKrkQnAtNJmSd8EBZH194Fx3yUBZj/yqTAcnkDTbVPsxi0rUvJG4C3ht0x3ewwZg+TAIfe1KMTKLS9JWn/ZXv43GaQCl8V1MyDdAc2hNVQGO9sSq8ztwzenAzBznCINwUi5tL6l4ty5SHMSwkzl/5ncrnylIPgJcM=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:50880 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aSnyS-0004Pb-B1 for apps-discuss@ietf.org; Mon, 08 Feb 2016 07:43:38 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_9CF04B92-977F-42FA-A5AE-566FE04F6EDE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> Date: Mon, 8 Feb 2016 10:43:34 -0500 Message-Id: <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 15:43:40 -0000 --Apple-Mail=_9CF04B92-977F-42FA-A5AE-566FE04F6EDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Perhaps an application-layer DHCP? > On Feb 8, 2016, at 9:54 AM, Cyrus Daboo wrote: >=20 > Hi, >=20 > --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" = wrote: >=20 >> If ACAP was going to take off, I think it would have by now. It did = not >> and I doubt it will, but I'm absolutely not opposed if we were to = somehow >> get a bunch of major client developers on board. We'd need some = server >> software that is well-supported, too. We either have to resign to = the >> fact that it's not going to solve the problem I think we should = solve, >> that nobody cares to solve this problem, or that we need something >> simpler (e.g., a couple of HTTP queries to get config info). >=20 > As one of the few people who implemented ACP/IMSP and all of that = stack I have to say ACAP's time has been and gone. It was way too = complicated to implement at the time and nothing has changed. The same = could be said of the IETF's original calendaring server effort - CAP = (RFC4324) - and in the end a number of people took a more pragmatic = approach of building a calendaring protocol using existing technology = (HTTP/WebDAV) resulting in CalDAV (RFC4791) that has (at least from my = standpoint) been pretty successful. As it turns out I replaced use of = IMSP/ACAP in my mail/calendar/contacts client with a simple WebDAV = solution - storing preferences on my personal WebDAV share. For the most = part that has worked well and is trivial to implement - most of the = short comings could be fixed through use of more modern capabilities - = likely a JSON solution using HTTP PATCH (RFC5789) and JSON patch/merge = (RFC7396). >=20 > All that said, I do believe that the client account configuration = setup is something that needs to be addressed. Indeed I tried to start = such an effort at the IETF (via the AppsArea WG) and number of years = ago. That was based on work done at the Calendaring and Scheduling = Consortium (a group of users and vendors who recognised the need for a = common configuration piece). At the time we titled that work "Aggregated = Service Discovery" (which morphed into "Automated Service Configuration" = (ASCOT) and the last draft for that (now expired) can be found here: = .= >=20 > That draft used a webfinger-based lookup of a "service configuration = document" that could list all relevant accounts a service provider had = available for a user. At the time that work stalled partly because there = was push back at the BoFs about the scope of the work, and because the = stake holders ended up with other priorities that took precedence. >=20 > Paul and I had an exchange about this prior to him starting this = thread, and he felt new work on this should be tightly focussed on just = email. I personally believe we need to solve the problem for multiple = services, not just one. >=20 > For email, calendaring and contacts we do currently have a light = weight SRV-based account provisioning solution (RFC6186, RFC6764), which = works on a per service basis (i.e., one set of requests for each account = type). The calendaring/contacts piece of that has been deployed and used = by a number of providers and clients. Unfortunately, the email piece has = not - a number of major ISP do publish _imaps etc SRV records, but very = few, if any, clients make use of that. >=20 > I also think that since the original ASCOT work, the world has started = moving in a slightly different direction - specifically more towards a = device management solution. With the wild propagation of mobile devices = into the enterprise a number of device management solutions are now = available that allow configuring of not only accounts, but provisioning = of settings (password policy, VPN certs etc) and applications, documents = etc,. These solutions are fairly wide spread in enterprise environments = today. Less so in the "personal" device scenario. >=20 > 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. >=20 > 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. >=20 > PS As it turns out I use a device management tool (one available from = my employer - Apple) for managing all my family devices, which includes = the ability to push profiles specific to my kids devices for locking = down parental control settings and the like. >=20 > -- > Cyrus Daboo >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_9CF04B92-977F-42FA-A5AE-566FE04F6EDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWuLenAAoJEORoZaSQsc1Ia2AQALqN6ZMwTbHxqLQ4hB2q2Bvr +EtB6Ze+L09ZwGM+QOaGWkAgk1dbyIO2jngkbVn6Qq5eRrJRouNXj347Mxdvnh9h UTNmkoAWgxiVzTnpNHXExv2ZB92b2fiDqgP1yZ5xyAPjHFLx0vU4JVwQARSTRbr/ J2slf/ftRJxDdUuO7oc1fflqNEzAt7ezMczw0Xr0Jr9iIvWbliPsj9kc62ieAt6w hHiGnzrtJglVa56SxtskMpZz4O0ECabhs1wvESDskn9rqLS0lEbpqBZCBV1YiWgH HAJkCBn7MEjkkxqKFIdj5UgywKEsVfkHBz5DZ5+pO6bwBIkSrTpVOBf5cofakFD4 V8iuyqifZ1vlxg2Y+jSIkOF33aLqBtYXtMLYZwtifzt5u86R20qExeA32OlOa9uT ssvlK1/EwqmMTxphODjMm2aZJtfr6rxclIoF6FR/3760zEDmrTG4TVTwzZXD2sGB EUa0ahYUFsGT2x1dKxEEFcN9l6rNT4fsWAdmVrczR9cnvgU4Ehov+58Scipm2WXE sf9COUF7SL2S0+dF73RsKqdf595PVhvOHas1/ciOcXQyeNzWRfTAYePfWtaAlGuQ ygS3+/RfD+TgsH6oWa/XUekccu2qpijehpq8d0tV96nrbXDRA7xSwKfFKN5Gxskh WtumBAf9kMFvCnu/wBrB =w5TM -----END PGP SIGNATURE----- --Apple-Mail=_9CF04B92-977F-42FA-A5AE-566FE04F6EDE-- From nobody Mon Feb 8 08:38:42 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447A61B2EE9 for ; Mon, 8 Feb 2016 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 T4N2MuDqmvVx for ; Mon, 8 Feb 2016 08:38:31 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869861B2EDD for ; Mon, 8 Feb 2016 08:38:31 -0800 (PST) Received: internal info suppressed Date: Mon, 8 Feb 2016 17:38:28 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Eric Burger In-Reply-To: <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> Message-ID: References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1454949509; bh=dqg034xKUITcAXf69J8eJhyU59/HNBjp2MhpXnziG5A=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=O5w25MosS8bUEJ/Cw6kbMhPu9Ov6gl0YK72T1mWj01MHKrJrTmD8HQXL26S+1SoS7 HtbBTq3TYs1SIm6uAIJAQNmdykDGxrpmvhvMTIreySeMST7Vv4RzwKMmKqS1ZeG+3a 786vXCJMgPdM7PjdHLXib1iJqj8igZo2Luhehp6o= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 16:38:38 -0000 On Mon, 8 Feb 2016, Eric Burger wrote: > Perhaps an application-layer DHCP? ... or something like the "autoconfig tool" used for eduroam wireless service (CAT - Configuration Assistant Tool) ? https://cat.eduroam.org/?lang=it it detects which device you are using, you select where you "belong to" (which provider/organization/...) and you get your correct configuration pushed down to the device... > >> On Feb 8, 2016, at 9:54 AM, Cyrus Daboo wrote: >> >> Hi, >> >> --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" wrote: >> >>> If ACAP was going to take off, I think it would have by now. It did not >>> and I doubt it will, but I'm absolutely not opposed if we were to somehow >>> get a bunch of major client developers on board. We'd need some server >>> software that is well-supported, too. We either have to resign to the >>> fact that it's not going to solve the problem I think we should solve, >>> that nobody cares to solve this problem, or that we need something >>> simpler (e.g., a couple of HTTP queries to get config info). >> >> As one of the few people who implemented ACP/IMSP and all of that stack I have to say ACAP's time has been and gone. It was way too complicated to implement at the time and nothing has changed. The same could be said of the IETF's original calendaring server effort - CAP (RFC4324) - and in the end a number of people took a more pragmatic approach of building a calendaring protocol using existing technology (HTTP/WebDAV) resulting in CalDAV (RFC4791) that has (at least from my standpoint) been pretty successful. As it turns out I replaced use of IMSP/ACAP in my mail/calendar/contacts client with a simple WebDAV solution - storing preferences on my personal WebDAV share. For the most part that has worked well and is trivial to implement - most of the short comings could be fixed through use of more modern capabilities - likely a JSON solution using HTTP PATCH (RFC5789) and JSON patch/merge (RFC7396). >> >> All that said, I do believe that the client account configuration setup is something that needs to be addressed. Indeed I tried to start such an effort at the IETF (via the AppsArea WG) and number of years ago. That was based on work done at the Calendaring and Scheduling Consortium (a group of users and vendors who recognised the need for a common configuration piece). At the time we titled that work "Aggregated Service Discovery" (which morphed into "Automated Service Configuration" (ASCOT) and the last draft for that (now expired) can be found here: . >> >> That draft used a webfinger-based lookup of a "service configuration document" that could list all relevant accounts a service provider had available for a user. At the time that work stalled partly because there was push back at the BoFs about the scope of the work, and because the stake holders ended up with other priorities that took precedence. >> >> Paul and I had an exchange about this prior to him starting this thread, and he felt new work on this should be tightly focussed on just email. I personally believe we need to solve the problem for multiple services, not just one. >> >> For email, calendaring and contacts we do currently have a light weight SRV-based account provisioning solution (RFC6186, RFC6764), which works on a per service basis (i.e., one set of requests for each account type). The calendaring/contacts piece of that has been deployed and used by a number of providers and clients. Unfortunately, the email piece has not - a number of major ISP do publish _imaps etc SRV records, but very few, if any, clients make use of that. >> >> I also think that since the original ASCOT work, the world has started moving in a slightly different direction - specifically more towards a device management solution. With the wild propagation of mobile devices into the enterprise a number of device management solutions are now available that allow configuring of not only accounts, but provisioning of settings (password policy, VPN certs etc) and applications, documents etc,. These solutions are fairly wide spread in enterprise environments today. Less so in the "personal" device scenario. >> >> 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. >> >> 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. >> >> PS As it turns out I use a device management tool (one available from my employer - Apple) for managing all my family devices, which includes the ability to push profiles specific to my kids devices for locking down parental control settings and the like. >> >> -- >> Cyrus Daboo >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; http://www.cert.garr.it/pgp/garr-cert-pgp-keys From nobody Mon Feb 8 11:00:00 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578891B31AB; Mon, 8 Feb 2016 10:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZqFYrJC4n8Z; Mon, 8 Feb 2016 10:59:58 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (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 DB3EF1B319E; Mon, 8 Feb 2016 10:59:57 -0800 (PST) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (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; d=packetizer.com; 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" , apps-discuss@ietf.org, webfinger@ietf.org Date: Mon, 08 Feb 2016 19:00:16 +0000 Message-Id: In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> 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 (dublin.packetizer.com [10.109.150.103]); Mon, 08 Feb 2016 13:59:48 -0500 (EST) Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" 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 18:59:59 -0000 Cyrus, >Right now it is not clear to me that an ASCOT-like solution would be=20 >adopted given the use of device management. Before embarking on this we= =20 >need to take a careful look at whether any solution is likely to be=20 >adopted (with the biggest burden likely being on clients/OS vendors to=20 >support it). Given the device management solutions already out there, I= =20 >suspect there would be little value to m,ost of those folks to actually= =20 >support ASCOT. I completely agree that we should try to get a sense of the likelihood=20 of success. Within the enterprise -- especially the larger ones -- you are entirely=20 correct that device management systems provide a good solution for most=20 of the employees. However, I interact with a lot of smaller businesses= =20 that do not use such systems. Many of them have a web hosting company=20 host their domains and do not have IT staff to help them on a daily=20 basis. I'm skeptical that a device management system would help that=20 class of users, so arming hosting providers with tools they can deploy=20 to their customers would help, I think. There are also a number of individuals who have their own domains, many=20 hosted on the many, many web hosting providers out there. Same issue=20 for most of them. So, I think there is a market need. I suspect if we were to create a=20 solution, hosting providers were to deploy it, and client developers=20 were to support it, people would use it. However, that's a string of=20 "ifs". I think it starts with the client developers. If there were=20 people interested to solve the problem, I think the rest falls into=20 place. All that said, if client developers are uninterested, there's little=20 point working to solve this problem. >As an alternative, the IETF might want to take a more serious look at=20 >the overall device management solutions, and see if there might be=20 >scope for standards in that area. That would allow us to build off=20 >something that is already deployed (in a number of proprietary=20 >solutions) but is today solving the problem of account setup. I think your suggestion is worthwhile independent of whether we solve=20 the problem for smaller businesses and individual users of hosted=20 domains. It would good if the same solution or would address those=20 needs of smaller businesses and individuals, but if it didn't, it's=20 still a step forward. Paul From nobody Mon Feb 8 11:26:40 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346491B3230; Mon, 8 Feb 2016 11:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rJaKt--rjFk; Mon, 8 Feb 2016 11:26:38 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DBA1B322C; Mon, 8 Feb 2016 11:26:38 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aSrSD-0007yY-2w; Mon, 08 Feb 2016 14:26:33 -0500 Date: Mon, 08 Feb 2016 14:26:28 -0500 From: John C Klensin To: Cyrus Daboo , "Paul E. Jones" , apps-discuss@ietf.org, webfinger@ietf.org Message-ID: <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com> In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> 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-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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:26:40 -0000 Cyrus, Thanks for stepping in on this. A few comments and clarifications below... --On Monday, February 08, 2016 09:54 -0500 Cyrus Daboo wrote: > Hi, > > --On February 8, 2016 at 12:45:20 AM +0000 "Paul E. Jones" > wrote: > >> If ACAP was going to take off, I think it would have by now. >> It did not and I doubt it will, but I'm absolutely not >> opposed if we were to somehow get a bunch of major client >> developers on board. We'd need some server software that is >> well-supported, too. We either have to resign to the fact >> that it's not going to solve the problem I think we should >> solve, that nobody cares to solve this problem, or that we >> need something simpler (e.g., a couple of HTTP queries to get >> config info). > > As one of the few people who implemented ACP/IMSP and all of > that stack I have to say ACAP's time has been and gone. It was > way too complicated to implement at the time and nothing has > changed. >... While I was (deliberately) vague, my "look at ACAP" comment was not intended as "go adopt ACAP". My own view of ACAP comes from a different perspective than Cyrus's, but is consistent with the above and some of his other remarks: it seemed to me to be far too "flexible" and complicated for the actual requirements and generally to suffer from a bad case of second system effect. However, I agree with Cyrus that it would be helpful to look at configuration for some class of applications that we can configure in a reasonable way --not just email but also not "everything". I mentioned ACAP because I think looking at it from a "what works, what is needed, and what is unnecessary or harmful decoration" perspective might provide a better real-world starting point than, to paraphrase another comment, starting with Webfinger and whatever buzzwords and formats are in fad at the moment. Perhaps Webfinger (with or without ASCOT) or, as Cyrus suggested in passing, WebDAV, will turn out to be the right answer (I really don't have an opinion) but I think there would still be a lot to learn from the ACAP experience... starting from "no more complex and option-laden than absolutely necessary". >... > For email, calendaring and contacts we do currently have a > light weight SRV-based account provisioning solution (RFC6186, > RFC6764), which works on a per service basis (i.e., one set of > requests for each account type). The calendaring/contacts > piece of that has been deployed and used by a number of > providers and clients. Unfortunately, the email piece has not > - a number of major ISP do publish _imaps etc SRV records, but > very few, if any, clients make use of that. And, as Paul and others have pointed out, SRV-based approaches are not particularly well-suited for environments in which the configuration information itself may raise privacy issues or in which per-user or per-device, rather than per-domain, configurations may be needed. SRV approaches might, however, be used to bootstrap the right configuration tools even if they are not those tools. >... > 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. Agreed for either device management or potentially per-user application management, but I'm also suggesting that part of such an effort should be to examine the many approaches we have adopted or tried to adopt to this general class of problems and see what we can learn from them, at least to the extent of avoiding repeating those mistakes. Of course, if there are a collection of almost-good-enough proprietary solutions out there, the two other questions that should be asked are (i) whether, and how, the IETF can actually add value to the situation and (ii) whether those vendors would shift to a standardized, interoperable, mechanism rather than continuing to push their proprietary ones with whatever advantages keeping them proprietary bring. best, john From nobody Mon Feb 8 11:49:26 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE41B2E9F for ; Mon, 8 Feb 2016 11:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFsFuHOgUlkM for ; Mon, 8 Feb 2016 11:49:24 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6F121A1A6A for ; Mon, 8 Feb 2016 11:49:23 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com 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 , apps-discuss@ietf.org Message-ID: In-Reply-To: <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> 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-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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. john From nobody Mon Feb 8 11:56:52 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7A51B3265; Mon, 8 Feb 2016 11:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 FhJ0CscMrQ9Y; Mon, 8 Feb 2016 11:56:50 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 6F80A1B3263; Mon, 8 Feb 2016 11:56:49 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id l143so102615075lfe.2; Mon, 08 Feb 2016 11:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n/cLDg1R2/MlflJKLZaHmYjL4l8ZSnwoBth69fCiqds=; b=GNw1w3m3kvzJgZIUDZ1Fbz4JTMBR2fxpuwOSoXTzxzcf+1eLFcsY614dqaH5gVwmuS QT2FQ3eDJAS2cB9bwbWGxmfYgF0HRJYJ+/Xgqz26BDFqp2naQufVYXHjUCBMlJeTJb5H moOa7SkiOjAUN7sozb7fjUAUKPd80Nx3dTuc0Mi0sriAMgpJv3rroEgcghvFGlvZybZp N/E4nQcAqD3gjhXRvoirZcGSiTlLyRmIB1gxWO65w172Izq4YzCHuytqy1GrTH4rHdb2 7/reGIyTvFgL/miRHSXv0czKCyEpsyGKWUwRSVPv2VFec8poEfXLk3uvFM6eeviJKy/P Kohg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=n/cLDg1R2/MlflJKLZaHmYjL4l8ZSnwoBth69fCiqds=; b=fyVe+oALFx93MpzzWjDHU9CjrYVg5b2BYnyWCV8qPmYv3wCS5qSrDNxAzZWRp4wRRv 2H+/dtKqhGm/cRRdOtEElC8I/1tBHWM+SLBUsY126LxQsLkz0CRumLIYz4u7CV72cXlO 9ceKrfuLX5JgNHS4M1FYcoHUUI2eEV3lqCwTIeSgwBc12c2PXwKoV42J2A7xVXskubNi xyX1TmcV9sOHb8gHglq1eTKrKiNf2juFo2++jjS5QyAFFLnCGT5sU4GcxSrSStFa+T9x pseRI4xWcR4MPKQlb9UNfMu0JO2qWwWVIKjc6J5JKjcOTqlQFScrwbjlOxknNNVWMv41 zjDA== X-Gm-Message-State: AG10YOShkXL48TK0uNLcbS2X4AoMAiDfeMOcEunAOBr0dzTBmjr3VIwGmVFO4BPka8L25XYltlEKtcatsIp/GA== MIME-Version: 1.0 X-Received: by 10.25.22.231 with SMTP id 100mr12255009lfw.153.1454961407614; Mon, 08 Feb 2016 11:56:47 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 11:56:47 -0800 (PST) In-Reply-To: <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com> References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com> Date: Mon, 8 Feb 2016 14:56:47 -0500 X-Google-Sender-Auth: 87u2sKOLypbGurb4TvpdjrMsw1U Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols , webfinger@ietf.org Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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:56:51 -0000 On Mon, Feb 8, 2016 at 2:26 PM, John C Klensin wrote: > Cyrus, > > Thanks for stepping in on this. A few comments and > clarifications below... > > --On Monday, February 08, 2016 09:54 -0500 Cyrus Daboo > wrote: >> For email, calendaring and contacts we do currently have a >> light weight SRV-based account provisioning solution (RFC6186, >> RFC6764), which works on a per service basis (i.e., one set of >> requests for each account type). The calendaring/contacts >> piece of that has been deployed and used by a number of >> providers and clients. Unfortunately, the email piece has not >> - a number of major ISP do publish _imaps etc SRV records, but >> very few, if any, clients make use of that. > > And, as Paul and others have pointed out, SRV-based approaches > are not particularly well-suited for environments in which the > configuration information itself may raise privacy issues or in > which per-user or per-device, rather than per-domain, > configurations may be needed. SRV approaches might, however, be > used to bootstrap the right configuration tools even if they are > not those tools. We keep going round in circles in these arguments. We really need some authoritative source for the Internet architecture. I agree with John's conclusion but with an older argument. Namely that people have tried to use DNS for account type information since RFC1035 was published and none have been successful. In my view, the DNS is the Infrastructure that maps DNS names onto current descriptions of services. So extending the use of the DNS for DANE like purposes with respect to TLS is certainly within scope of the DNS. Attempting to use the DNS for account based information has consistently failed. John's raising of the privacy argument seems to me to be the capstone of this argument because all of the reasons people have given me for not making information in LDAP or X.500 directories publicly accessible are essentially privacy arguments. The concern that head hunters would use the company directory to cold call people is a form of privacy argument. The reason I thought I would flag this is that if we are going to build such an infrastructure, we should probably start from the idea that privacy is a paramount concern and plan accordingly. I do have some code that might be relevant to this problem in the Mathematical Mesh but it is not a problem that I have considered except in the abstract so far. It seems to me that any mechanism that would allow contact information to be shared would have to leverage two separate principals 1) Social media style 'friend' links 2) Progressive disclosure (aka kimono protocol). My email information is online but not my telephone number. I really, really want to get rid of the telephone number ASAP because I am getting half a dozen spam calls a day now. Even with nomorobo in place, each spam call still causes one ring and that is starting to be a hassle. So if we are looking to support features like calendaring, instant messaging, VOIP, etc. We really need to have some sort of concept of a hierarchy of introductions. Something like: 1) Can send me a contact request 2) Can send me an ordinary length text email 3) Can send me large emails and emails with potentially dangerous attachments. 4) Can request voice / video / chat 5) Can put items onto my calendar 6) Can interrupt my work with notifications The last of course is something that I am going to probably expect to be paid for. As I keep saying, there is no problem in providing a cryptographic infrastructure that supports all these needs in end-to-end security and in multilayer security models. Give us a clear description of the requirements, and the crypto is not too hard. The hard part is being clear about the requirements. >> 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. > > Agreed for either device management or potentially per-user > application management, but I'm also suggesting that part of > such an effort should be to examine the many approaches we have > adopted or tried to adopt to this general class of problems and > see what we can learn from them, at least to the extent of > avoiding repeating those mistakes. +1 > Of course, if there are a collection of almost-good-enough > proprietary solutions out there, the two other questions that > should be asked are (i) whether, and how, the IETF can actually > add value to the situation and (ii) whether those vendors would > shift to a standardized, interoperable, mechanism rather than > continuing to push their proprietary ones with whatever > advantages keeping them proprietary bring. I think there is a very clear area where IETF can add value, we can provide a mechanism that puts the user in control rather than being designed to bind them to one proprietary service provider. In theory I can use proprietary mechanisms to transfer my email settings from one device to another. In practice these only work for the limited set of devices a vendor supports and these in turn tend to be allowing me to move to the hardware/software of the provider. There is also a real problem with platform providers who 1) Force me to perform regular software updates 2) Think nothing of trashing my personal settings during an update. Right now I have an iPhone whining because it hasn't been connected to the iCloud account I don't use and don't want. I have a Windows desktop that shuts itself off after 10 minutes despite my repeated disabling of the power saver mode because one of its functions is as a server. I also have a large collection of bookmarks that I collected using the Google Toolbar that I can't properly access from Google Chrome without the use of a third party plug in that almost certainly will add malware in a future revision. From nobody Mon Feb 8 12:10:05 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286561B3299 for ; Mon, 8 Feb 2016 12:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 fuNe4nCFheB8 for ; Mon, 8 Feb 2016 12:09:55 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 7C1B61B3296 for ; Mon, 8 Feb 2016 12:09:55 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id l143so102839059lfe.2 for ; Mon, 08 Feb 2016 12:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kCfDQ6jwjrsh9pEVnPsNFr6x2i/NwF0RPQ6AgT8fl78=; b=VQByMcApndOAcvEbYgHNcUiiH1QbsATGPR2ObYPHMWy0u/gTr4846MS2OGTsAcZDQk scEKFcRCVoZ5xGVDbTgspNIIykPR17JWQiovCIZPBqbRwCk32PRu8aH9K3lIdrf4Ic0N ja/7T1YTbvpO45FvgQBLktuZ1OocQV0EXQuXYF1MTO214RuF3d6dWa8xcCik5DDT85bf qJQ5oyCPPg+iA2gb3yd+m77viNqgIUmuu7JLr5qaBZT/GtbE8XO3wFQTMtW1uW8ts9fS lX4+4S2Nd5rscntVf/cVXj1umLqaG0ArYNHCu6/StfOcFVpeHvUz8XGSl0pZ/9YwugB5 fROQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kCfDQ6jwjrsh9pEVnPsNFr6x2i/NwF0RPQ6AgT8fl78=; b=I8W+PSAF3+h+Z9uvRr5mA+SKELlkOF1L0emayQi3tDX59jaEI3XcGesHy2BCvurdYV 9iMuxYugvWL+DNc1UZBM7pKhhwAyMF5FkVClG3zwWtdmctg2gFQgeczAAX8YcEKcwUZi rvnnzRIJky7H608WCWI02edGmgRaj4ri1kQ8zv1uxYdY9uumxe8c10du5/5V2C6QCZJi YADv5WjsGGkSmlo3WxG5jYkLNqm2Oa87s4exzoo/AUxlzlh5zhymZqTIjzSmYjL3BC7k 5uKk5mPU8HyFhAzUHEsOEYvfdntF7YF5qIYWp4BnNXnArAl9dIlNUN8JJoxTFtuwkNde J2+Q== X-Gm-Message-State: AG10YOSSTWkHPxTpShVlEiFaewqN4G1qEG/90zvh64am3V6OcbY4U2UQkoHj9D7D+RMp/W92N0MfyvkkL9GCMw== MIME-Version: 1.0 X-Received: by 10.25.213.196 with SMTP id m187mr7504647lfg.67.1454962193606; Mon, 08 Feb 2016 12:09:53 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 12:09:53 -0800 (PST) In-Reply-To: References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <8D50E1C3-46FB-4341-B06A-86902B984AEC@standardstrack.com> Date: Mon, 8 Feb 2016 15:09:53 -0500 X-Google-Sender-Auth: Lb9DBzQwoRdkP4mHRq8qAWTI1l0 Message-ID: From: Phillip Hallam-Baker To: John C Klensin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 20:09:57 -0000 On Mon, Feb 8, 2016 at 2:49 PM, John C Klensin wrote: > > > --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. I may have a solution. There is another problem I see with ACAP, like the typical Internet application of its day, it starts with a protocol description and then it tries to add security. The Mathematical Mesh is an infrastructure I have designed, build and demonstrated: https://www.youtube.com/watch?v=6vM6vxtQzGg http://www.prismproof.org/ [Yes, there are Internet drafts and the source is MIT license] The approach in the Mesh is the reverse of the ACAP approach. It was originally designed as a mechasnism to allow me to easily move public and private key material around to allow a single user to control multiple devices connected to a 'profile'. It was designed to support S/MIME, OpenPGP, SSH, TLS and the like. It was only after I was writing code to store S/MIME keys in the Mesh that I suddenly realized that I could just as easily store all the email configuration data in the Mesh. The Mesh itself is configured as an untrusted service. In the demonstration, the server for the Mesh is actually located inside the dalek you can see in the background. The point being that if you use strong end-to-end security, you don't need to worry about where your endpoints lie. Now one major caveat here is that privacy is a much harder problem than email encryption and not the problem I set out to solve. At the moment the Mesh protocols deliberately leave information accessible that I would like to obfusticate later on because trying to debug a system in which every identifier is anonymized is probably going to be a #@($%*#@$(%!!! > 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. +1 If someone can give me a clear description of 'the' problem, solving it is easy. What I am trying to do right now is to provide a solution to the problem we claimed to have solved in 1998/1999 but hadn't. From nobody Mon Feb 8 12:23:00 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEACD1B3242; Mon, 8 Feb 2016 12:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 GMDdhKxvz1Gv; Mon, 8 Feb 2016 12:22:56 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 7E63E1B32AE; Mon, 8 Feb 2016 12:22:56 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id l143so103049479lfe.2; Mon, 08 Feb 2016 12:22:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Rl3BwJddE82/NqsqMZ3Mk7vdOMgNv62oE5CrcONew/4=; b=QEN4YTQqek0YGaEj49ZkU+aHAVsFmi3d5pdBy9iIR/9OJLfArP1CXt5bYBQsR3s/qc 9qF7tCnQwZM+vHkz1j2h4oNLSfpy2IuFedFNf+bz5PCEEUFhF8ohiCVIF4LQ19a9gKlB yItE5njzxnsawWZKQCOF50pV6Rcez3kBKpSPwfzVvYLeElmNeOt5aTSZoPI3mza/g+H5 OT9FST+9VAk+6nryYrZz5BTrgPOt7EdTK2F5o5N6kY01K+CI+onLFXsHUlbywwCZvZcy VY8DdntGTwwQjsVgviHr8+YzEmSOCEhBdYiJ1wOIsl8h77scYLBu23kGtBrKmqr92B0W k+kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rl3BwJddE82/NqsqMZ3Mk7vdOMgNv62oE5CrcONew/4=; b=L9CdW+J1Pj/EKBFgGZLCuFcORAYFB0DMogt0MA1jKFO/h/iCkkDKeLqdSqVzREDeTH JuPrHbr6YUxBwRqNPokK1ekOFHU+s/Q/uof08303xxRFX4J3gLzfaGgXy11yQ0AkIoei 5ElKPf0vAc3scAtjRSJO49KUtN1aJwQrhyNOz3g305ogjFP1Zii4oLUZwxR802E6iGFu bY8uc4fyJnMi/7+SxiVHHZC0nPnRjrjRAWBLO9AALqaRc6QUODEA0q9R3nagqfGFkK50 hb/v6gJwwxucl6KVekfmnL4/ZAP2xIk7my00XdQ8KuTkocCSLk4HfZaqho8gpBrfi76f W+Ow== X-Gm-Message-State: AG10YOSDiW1SCUe3XI+1NAoDEKDV7loNQTv0V3Fx8E6ZiKCLIEfaYbVc5sqYHJJk7fLtKCeH+/Z8Ucvy4HB8Xg== MIME-Version: 1.0 X-Received: by 10.25.205.7 with SMTP id d7mr4820324lfg.70.1454962974806; Mon, 08 Feb 2016 12:22:54 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 12:22:54 -0800 (PST) In-Reply-To: <56B7F345.9060505@cs.tcd.ie> References: <56B7F345.9060505@cs.tcd.ie> Date: Mon, 8 Feb 2016 15:22:54 -0500 X-Google-Sender-Auth: t_h3vjd3BZXXX_DfZNkKXBlNOwg Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols , webfinger@ietf.org Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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 20:22:58 -0000 On Sun, Feb 7, 2016 at 8:45 PM, Stephen Farrell wrote: > > > On 08/02/16 00:45, Paul E. Jones wrote: >> >> If ACAP was going to take off, I think it would have by now. > > That seems correct to me. > > I think solving this problem in isolation would be worthwhile > if folks deployed a solution. (IOW, let's not generalise too > much.) > > My own ask here is that the user not be expected to enter a > password until after whatever automatable checks can be done, > have been done. I really hate entering a password into a new > device before I've gotten any feedback that that device is not > going to send the password in clear over the network. And yes > that may be a minority concern, but it is still I think one > we ought not ignore, esp. as it should be quite possible to > encourage good behaviour here (it's as easy as encouraging > bad behaviour;-) PLEASE No more password based protocols. Passwords are not the way to solve this problem except in the hopefully very rare case of catastrophe recovery. 'We believe in strong cryptography and reviewed code' The problem with passwords is that a human cannot be expected to remember any piece of information that is secure enough to be unguessable. Remember when the requirement to have mixed case and a punctuation mark in a password came in? That was in response to Crack published in 1991 which was a dictionary based search running on machines that could do 35 password tests a second. Four years ago, someone lashed together 20 GPU cards discarded by the bitcoin miners and built a machine that could do 350 billion tests a second. It isn't a dictionary attack and so the password restrictions actually reduce the search space and make the problem easier. Passwords are done, they are dead. If we want to have an application configuration protocol it should be capable of configuring cryptographic authentication credentials. Now we might optionally encrypt those credentials with a PIN, but that is a local security matter, not something that travels over the network. From nobody Mon Feb 8 17:12:41 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC03C1B3EE5 for ; Mon, 8 Feb 2016 17:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 60Jb9mJDgRqp for ; Mon, 8 Feb 2016 17:12:39 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468E21B3EDB for ; Mon, 8 Feb 2016 17:12:36 -0800 (PST) Received: (qmail 64233 invoked from network); 9 Feb 2016 01:12:35 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Feb 2016 01:12:35 -0000 Date: 9 Feb 2016 01:12:13 -0000 Message-ID: <20160209011213.92948.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 01:12:40 -0000 >Within the enterprise -- especially the larger ones -- you are entirely >correct that device management systems provide a good solution for most >of the employees. There are plenty of people using mail systems on networks not under the same management as the mail server. I'd think that most smartphone users would be in that situation. R's, John From nobody Mon Feb 8 17:14:59 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47661B2D4D for ; Mon, 8 Feb 2016 17:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 dVnQiDkTBbYr for ; Mon, 8 Feb 2016 17:14:56 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 88E5D1B3EE2 for ; Mon, 8 Feb 2016 17:14:56 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id j78so106657695lfb.1 for ; Mon, 08 Feb 2016 17:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cnKflwnRqMWOs/oCzWBaEqmEaNJWpYb6lR8wpuKE77Y=; b=pvazA4G+vbtdi7tMwHDAXFOqa8vIw1rjR3UCr6I2llUDeHImC6ZK3S2nMgUc8HmZyn RbbOzfcywaAKr3x1O0o7dMlCeibWIl/YgGGgghgkDFL3XbqM3A8NDoY8k9HfFt7ikzr6 dXCu1CbUGvZY/sB+7O4Yh0LpLpRaNwsrJk+UrX0e8oj3dTHcE1XE/rUtkA3LtbXtbgK/ +sjL5OwBQFZlSR+ig65hcAiK5ywXsCqyTmtwz6H2tHSw80vC/UlQ2rIft0fNrddOKwOY 4+qZ8nH6Zc0mpCRWWTRHcZ+b7rqqzyhcxROegyCTa8HjHe8EqzXGjUIuH8W/TJWFDWfZ xgKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cnKflwnRqMWOs/oCzWBaEqmEaNJWpYb6lR8wpuKE77Y=; b=UGrQYdVYQZHcMnnBID45Qa91VHwPvnJjpDhsovJuzSeBctqDEAX82ckb0pGGZ3xnJj BRLSg3mO54FqC0zD1oVw8EsTTdOsKh7L1nPBy0A4wyEtzEqZqDRTT1Dpq8oRMyUcqnJB stB3/MOiqII9dZ6i9gceEhw9O4yFaSJFwZRPD48IV2akuYtVYb/aQQkiZnl3NroaILf2 3BVPvsvx0X2h/aElAxQ8qSj7FE1rUSrR3e6tWEFFOazNo9+RPkM2sMgKoNa16DGaC9eI b5DA8AJydX7ptteHAgNZXb5hTvB+WON12GztPbevDq1mv/YK0z2/3AeNDxew5ANz2Zd9 CgPg== X-Gm-Message-State: AG10YOTiRSi+vJxw6O5e6CKjiR3bmmhCURIENxlHPe3+j7dJnkyYe7wDhO/BvCfAcWTP2j9fT/kbjewvWy9/Kg== MIME-Version: 1.0 X-Received: by 10.25.22.231 with SMTP id 100mr12697842lfw.153.1454980494843; Mon, 08 Feb 2016 17:14:54 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 17:14:54 -0800 (PST) In-Reply-To: <20160209011213.92948.qmail@ary.lan> References: <20160209011213.92948.qmail@ary.lan> Date: Mon, 8 Feb 2016 20:14:54 -0500 X-Google-Sender-Auth: ei8H_Np8F3zjd8nJS21aWM7T55Y Message-ID: From: Phillip Hallam-Baker To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 01:14:57 -0000 On Mon, Feb 8, 2016 at 8:12 PM, John Levine wrote: >>Within the enterprise -- especially the larger ones -- you are entirely >>correct that device management systems provide a good solution for most >>of the employees. > > There are plenty of people using mail systems on networks not under > the same management as the mail server. I'd think that most > smartphone users would be in that situation. BYOD is now the name of the game. And you don't have an email app configuration solution unless you can configure S/MIME and OpenPGP. From nobody Tue Feb 9 00:32:35 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132D71A6FC3 for ; Tue, 9 Feb 2016 00:32:34 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 slTLthLNp-cH for ; Tue, 9 Feb 2016 00:32:32 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989431A6FC5 for ; Tue, 9 Feb 2016 00:32:32 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 55643FA005C; Tue, 9 Feb 2016 08:32:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1455006750; bh=2zSfuXh2EPsB7IBEaRZux/Wd3yKzoDuMjAVy9JhAqZs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LPIRK5/PR6hA2dV1dkxgu0uLzt8J0d5/9eWzyHm+h+38xGFCcfIanHzzPnoCtrC5+ DvgUeW76PznaTz89x4y1pt9+O06C5Pd2g4+fXtUXMUqumNuRd5+/6L/MuusziAWSll AG+K7SsOBuuepuFqjHD+UHTd1BHptkLqRjRkZah0= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1455006749-19608-19604/11/7; Tue, 9 Feb 2016 08:32:29 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Tue, 9 Feb 2016 08:32:28 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: <1a51a22d-712b-43d2-b8ea-10ee0e5f2a18@gulbrandsen.priv.no> In-Reply-To: References: <20160209011213.92948.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 08:32:34 -0000 Phillip Hallam-Baker writes: > And you don't have an email app configuration solution unless you can > configure S/MIME and OpenPGP. Wait, what? Solving the problem for the 99.995% who don't use PGP isn't worthwhile? Arnt From nobody Tue Feb 9 03:10:51 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE071A8902 for ; Tue, 9 Feb 2016 03:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 MHWJqKv0LuRa for ; Tue, 9 Feb 2016 03:10:48 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809B81A88FF for ; Tue, 9 Feb 2016 03:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w4cGyxQLWZXmR7+f+u4FVSYTh/2DNyubRgd4nVjjcro=; b=iW3H8joMdvLZTA2MK8bIEZfmd47OeuyZXLLv+xch4AH3aEOGvM3TvZGpMoxgkh8N5HLdMgOdj0VGSuSaP/aWDq+cbEgOmIjqSEFJoNmVxYnJIHbfKePFj5RBSpxd4wz28J6bxk0vCOFuCrscMgkOiCv/W8Q51sa5TSDxqtUOtZ8= Authentication-Results: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.185.87.133) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.396.15; Tue, 9 Feb 2016 11:10:24 +0000 Message-ID: <006801d1632a$048bc4a0$4001a8c0@gateway.2wire.net> From: t.petch To: Phillip Hallam-Baker References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <41CEFD2751A79CA0424C9D3F@JcK-HP8200.jck.com> Date: Tue, 9 Feb 2016 10:49:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.185.87.133] X-ClientProxiedBy: DB3PR05CA0082.eurprd05.prod.outlook.com (25.163.44.50) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB050; 2:HjNP8q8Tz4tW+xuhJrhAXp+ISnhqj4BUeYVPIINvGBsdhbkfGKdwMLDqD4whD3RwTCD4wOzHKWb2dYYCTNubAyETSCxMmIj3W/gpWnH153nKsUKthZERiIiRy4lOtoVEXFk7qHzMF/jrUkPnI3IZGQ==; 3:sUzomd7+Akrkam9wN/9bJ+Kjovcyz8zjkw33owD3VNGdE+SExEwI88ocTLiP3K7MF1/GEkDRiMe4y7a7qjuTPOYHmSvhJ8o5qOPpPL7qRyXPnaSkGPTvp/B24jRoLzfc; 25:52snkfIuo6FRD/mEDxHLkb0yPWSz9f9PgLS/yMl5IKf1xh5/nhzh4yVtQHrrhHHebkzM1a1py5x920LNAeQFI+MNh47HeJgSaCGt28fBm86GScE0jTR1/elBDI6MVfchgKInZZuwBjMOReI1QYECFf/mPC6/3ef3tg28xG+6C6MX6nueUU5ZE/x8jW3a2WqGY3d/awdyGlT8kx9g3i9UmI+px5V3f39oeeGxlgFFlvQdhsZvUUvVGG0SDkLd/n6LmfoOUOtpdh5FNLfGgVY98RYWLlBKFAzNpxncTFIhoQg1A/ETuwVDXCVyOdv4ser3 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB050; X-MS-Office365-Filtering-Correlation-Id: a7e1dd99-3a3f-4118-af69-08d331419bb9 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB050; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB050; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB050; 4:n2ZR3OvqjvdgWZT3ZruaM5taWxSUCoen6hc80r4mln/ywxQeSTw3HxA+1DT+BE/AOiDM8OLu3fOuteF2hpsxU1ltq+55WKrX9kta8cM5I49TnR7syBTpG16rFd8N2DYXNw9hmSygwyiwHYp66X3wVVToCiX+oDLSFz2ruUSqDxuLFI9CsNfJu5MDJ9AkW7uUdqEinK6QN11GGNHM0Iwwgl4dVz5d7QtK75ibtFwyDfexYoqAvuaVSAJWlRUJ6JoTCMDpdCFDySKHaB48iLtFXQPBoYIy0OLhFwXxGJInm9x4viOqAkne87WuPERvZ4z+a3ccXT3NFADtnBCYepWVPwWrtkB3wbSCH/vhLQhDTX6yaxlY1iaYh3PkHgDy6vQ1 X-Forefront-PRVS: 08476BC6EF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(52604005)(377454003)(13464003)(81816999)(19580405001)(5008740100001)(6116002)(23756003)(19580395003)(92566002)(2906002)(4326007)(50466002)(229853001)(86362001)(5004730100002)(1456003)(40100003)(122386002)(116806002)(77096005)(33646002)(110136002)(66066001)(42186005)(44736004)(76176999)(50986999)(81686999)(93886004)(3846002)(5001960100002)(87976001)(1096002)(230700001)(189998001)(586003)(44716002)(47776003)(1556002)(50226001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB050; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; AMSPR07MB050; 23:/Ct0XLnodX16tH65cb1hRaoLTHiqqx7LareVkn0H?= =?iso-8859-1?Q?y65DUbkA5n2vOg+jFC5/dF2rjPP6tyYigfqs0Bhet8b+V/I1XH2a29CT6Q?= =?iso-8859-1?Q?sxXVVgLfvfHpCOvqrUWia1RnG+r1Y0uK/wXJ2tL/DUX8y0mlNLy95Lwcjb?= =?iso-8859-1?Q?9j9AukOlp7UtcZImLltlefndgf8MHwicWh366dFz71PfFkjMZZf4acK73V?= =?iso-8859-1?Q?aPDQ8jNuNmUdejZNQo8xF9r+F82+LENS7Ualgq9hBkR8l02CSrlaD7AyQb?= =?iso-8859-1?Q?tgw+LpFllqrOYFdpw+M7GDPuQawx5T+INa7wXV1unDVCr6UyviFb+GKMyo?= =?iso-8859-1?Q?gnvP2D3mM+up5KJUqYGgzhDpVPiabUF+2sRHwQ8fllGJE7OpgyUVnkHIge?= =?iso-8859-1?Q?oDsGQD61ckvVUWHICuxn0whhXFAR9JZOdyTKblgPKCS2PmS9HFRrlIt2hT?= =?iso-8859-1?Q?N3FtpeE3NHoOxU4b0tiLKEOmjQdPA5f9ZNzhkDszjP/sEh29DVDDMY1WL2?= =?iso-8859-1?Q?ysyzv9U8HMCHhkFrr/z4H2csVvjvUBai8GVufHFl/1yxcJR+Uw5zuM7PDL?= =?iso-8859-1?Q?FHbQCq0sNvj9GFUobiuOvJFXszrYKCgqIS7yKEY/xp72mZ8Aqog3vBxfu1?= =?iso-8859-1?Q?esA4vwEpZcKG0d+Hpx/Q7h/cLJhgTNw8A3cUcm5cn4PTuy1BZBN1ySuwpJ?= =?iso-8859-1?Q?TRlnRZEDVh3itdafK6siCdeiW2BJQURKh3H9G520W3OccQ+raXl0LYFQt+?= =?iso-8859-1?Q?k2JUVftG/lrRPpaU9VF++eGRIDYwpgdv6INEy4rq5MtnCsl99NbYeGryTp?= =?iso-8859-1?Q?+mT3BCe7bRKe5V/qC6Ok2GaiFIV1pVS9CktabL7bop7M8o+TK+DV+8p7oH?= =?iso-8859-1?Q?+cVd9GKMwWz2snTlKe+7ajqdJWGR/kWXrDofXLVANPVNLNKDO1jGWocX9P?= =?iso-8859-1?Q?+qmBfPE9nwre/Uh8G5akuhn81yWNvzUYO1e2BjD7M7q2vDT4pbS6LAo47o?= =?iso-8859-1?Q?hmmh/fyic8+q/PicpiaHgfLO5VTr+AzoWx18RaLXNPI/5X02rVELKSGckk?= =?iso-8859-1?Q?bWtqiIxmex+T6eyRl7r7xp0iI7mskSRLJd5GrxPm+gL/KbU2JuStHTTmkR?= =?iso-8859-1?Q?bnLJOFWuo/9jeUisAMlHETNPFzsVfGXIMKOK6XKS9LUE+yIdHCvGxiXBnI?= =?iso-8859-1?Q?sGW2fQMBcDlgqdf2yogVVFINXTy61NNA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB050; 5:R0TBdRrtonhThpKPA6bSsnIXHHTDbpOOmp0FOPVgw8oOlQvc+/tyA5wuuV85ezh5Ku4m7iVxcb+mwBzp+M/3CworwNsd4W2lIgcvSwLekrAvpkp8EZnMZqYA4qSvprz09Sxp4m6YE9j8g+il8Cylnw==; 24:CjNWVIIt69wI5HP43UY1iF0R4aLVS/61A9nC1XQA9nFCR9Y+F6wLZse8ca0z4X8QoMX4FK0e9ztSWcbPtVgO8JPBQPzlla8YTnb5tde0XH4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2016 11:10:24.2148 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB050 Archived-At: Cc: General discussion of application-layer protocols Subject: [apps-discuss] call blocking was Re: Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 11:10:50 -0000 ----- Original Message ----- From: "Phillip Hallam-Baker" To: "John C Klensin" Sent: Monday, February 08, 2016 7:56 PM > On Mon, Feb 8, 2016 at 2:26 PM, John C Klensin wrote: > > Cyrus, > > > > Thanks for stepping in on this. A few comments and > > clarifications below... > > > > --On Monday, February 08, 2016 09:54 -0500 Cyrus Daboo > > wrote: > > I agree with John's conclusion but with an older argument. Namely that > people have tried to use DNS for account type information since > RFC1035 was published and none have been successful. > > In my view, the DNS is the Infrastructure that maps DNS names onto > current descriptions of services. So extending the use of the DNS for > DANE like purposes with respect to TLS is certainly within scope of > the DNS. Attempting to use the DNS for account based information has > consistently failed. > > John's raising of the privacy argument seems to me to be the capstone > of this argument because all of the reasons people have given me for > not making information in LDAP or X.500 directories publicly > accessible are essentially privacy arguments. The concern that head > hunters would use the company directory to cold call people is a form > of privacy argument. > > The reason I thought I would flag this is that if we are going to > build such an infrastructure, we should probably start from the idea > that privacy is a paramount concern and plan accordingly. > > I do have some code that might be relevant to this problem in the > Mathematical Mesh but it is not a problem that I have considered > except in the abstract so far. > > It seems to me that any mechanism that would allow contact information > to be shared would have to leverage two separate principals > > 1) Social media style 'friend' links > 2) Progressive disclosure (aka kimono protocol). > > My email information is online but not my telephone number. I really, > really want to get rid of the telephone number ASAP because I am > getting half a dozen spam calls a day now. Even with nomorobo in > place, each spam call still causes one ring and that is starting to be > a hassle. Phillip I have a CallBlocker which suppresses all rings, and the difference it makes is magic. The phone still logs a call, giving time, number and a flashing red light which I notice only when I am willing to be interrrupted. The box is American so I imagine it will work with half the world's networks. The weakness is the lack of data entry, not even a web interface, so I cannot add numbers to its directory except by catching a call and pressing a button while it is in progress so I am still hassled by those that ring when I am out and fill up my VoiceMail. And, crooks are smarter than phone companies so they are now using forged source addresses - no RPF for the phone - to bypass the blocks so the effectiveness of the blocking is diminishing. Thank heavens for e-mail (even if I have to configure it:-). Tom Petch > From nobody Tue Feb 9 03:45:30 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AC81A8946 for ; Tue, 9 Feb 2016 03:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 J8styT5wFIvM for ; Tue, 9 Feb 2016 03:45:28 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3831A8940 for ; Tue, 9 Feb 2016 03:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=hNAtwpvUjv0Q2lZ6NB0U2GlvEZ4mS8JxsdA3aD/vek0=; b=CczJ6tKfcN/3HpRkYJ4e1MSoM19FdqmCYeOkR6BidwOjpGJU7bXjhtMzAEMq+M/Cpx4yTmA1Yei2LxbCknP7+yJuOjhyevE5P6GxV12H4rG4NwgMCidgi/eizOSblxRU9YNKT1Q4HPUbZcgXwipESEn7DsO8MZVMSd5I+wvuHAQ=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:51243 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aT6jU-00045v-0A for apps-discuss@ietf.org; Tue, 09 Feb 2016 03:45:27 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_2BFF098F-DF21-476B-84E9-5DEE469F5B8B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Pgp-Agent: GPGMail 2.6b2 From: Eric Burger In-Reply-To: <1a51a22d-712b-43d2-b8ea-10ee0e5f2a18@gulbrandsen.priv.no> Date: Tue, 9 Feb 2016 06:45:22 -0500 Message-Id: <3FD5A7FB-DF78-468F-B7CD-84E5023D7D2B@standardstrack.com> References: <20160209011213.92948.qmail@ary.lan> <1a51a22d-712b-43d2-b8ea-10ee0e5f2a18@gulbrandsen.priv.no> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 11:45:29 -0000 --Apple-Mail=_2BFF098F-DF21-476B-84E9-5DEE469F5B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Would I not accept an automatic mail configuration protocol that does = not configure S/MIME or PGP? No. Would I not try really, really hard to create an automatic mail = configuration protocol that does configure S/MIME or PGP? = ***ABSOLUTELY*** In 2016, it would be criminal to not provide a solution for the 99.995% = of users who cannot spell PGP or S/MIME. I agree with PHB=E2=80=99s = sentiment here: we have to try, and we have to try really hard, to make = the security configuration a major purpose for the effort. For that matter, one can argue that without security configuration, the = market has passed us by. My current experience is with MacOS. If you use = Gmail, iCloud mail, Yahoo! mail, AOL, or Exchange, your mail = configuration magically happens. If you are using a raw IMAP or POP3 = server, more especially if you are using a real submit server at a = different address, too bad for you. However, I=E2=80=99ll bet 99.995% of = typical users are using one of the big providers and would ask =E2=80=9Cwh= y is the IETF working on how to configure Gmail? It just works already. = The IETF is solving yesterday=E2=80=99s problems.=E2=80=9D If we say, = =E2=80=9Cbecause you get security,=E2=80=9D 99;995% of people would say, = =E2=80=9Cthe IETF is great!=E2=80=9D > On Feb 9, 2016, at 3:32 AM, Arnt Gulbrandsen = wrote: >=20 > Phillip Hallam-Baker writes: >> And you don't have an email app configuration solution unless you can >> configure S/MIME and OpenPGP. >=20 > Wait, what? Solving the problem for the 99.995% who don't use PGP = isn't worthwhile? >=20 > Arnt >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_2BFF098F-DF21-476B-84E9-5DEE469F5B8B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWudFSAAoJEORoZaSQsc1IKHwP/AziTFqv7zvshLBC84yG8pIm oE5kfn0Gi2GT9wi1PsRkjUWxX634fLDzNyLwYHTV8FqsMJRIDt9yDoMCOEF+T18G +01iDJJJGgS+RP5fdQKg06eZN4rkOYumM+M5qJbkXy3TKhzMqH400j3zvNce0LVZ 35pDEcJH8tEwRQhwG7hQ0mvGw6vwAgOXH5MuwRRdPRW5EjGoW05ZY/o05iwNo2Qg i4kMPd30eDHMKVO+R/aBsInS2KKPCUqCa1xsBYynJe5bKTkfuv9eN0Pzrodbakvi BTXM8STUoSIjNEqdI4xqE5n4Rp8bHa2I132Nj3wi4iMVUfummV1jtWx1+kN9OTvO eYbvYTLKp8kKfLQcNce71+ZgdyR+SozV6CfSMEXgyXt7U9i3eVbZ/RJpDPYEvYcM xcxeyOAlLZEateVG8gt7bgTT0y7JYxKrvUD7JeYDY2PFFdbJH9LqLXMQtCEcHZ21 fYSWmf/ZqFXUf7w6fbmc4M3VejEwCrkL4ykwmy0P+DAa0pxGsgYJStql2ar5qiR5 jjOgS6kiMqQWEZO8ubwzbx9G3PNw5RSujl/MDD//sL6Q0vjF467KfzZR/4U49yXA Tp3EN/9D4dCR/DiLt2ti+z3FnY73oJNLHk4JSbzwvIldjAl8GV0TmIob+x+m31ph +smSl4q50MKSdwD5eE7I =6jJE -----END PGP SIGNATURE----- --Apple-Mail=_2BFF098F-DF21-476B-84E9-5DEE469F5B8B-- From nobody Tue Feb 9 04:49:11 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7B1A8A75 for ; Tue, 9 Feb 2016 04:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 5PRuprlpSAVN for ; Tue, 9 Feb 2016 04:49:07 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2DA1A8A6D for ; Tue, 9 Feb 2016 04:49:06 -0800 (PST) Received: internal info suppressed Date: Tue, 9 Feb 2016 13:49:04 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Eric Burger In-Reply-To: <3FD5A7FB-DF78-468F-B7CD-84E5023D7D2B@standardstrack.com> Message-ID: References: <20160209011213.92948.qmail@ary.lan> <1a51a22d-712b-43d2-b8ea-10ee0e5f2a18@gulbrandsen.priv.no> <3FD5A7FB-DF78-468F-B7CD-84E5023D7D2B@standardstrack.com> User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-2139066162-1455022145=:538" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1455022145; bh=KRGUCE/67cqbZDUUY31i0+OVAnVd4q0MEbvQvqvZshE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=T8x0gjRG8EQdcyuEFy8UH0FqRNzl++F+vxNP7HCq2Ax3PShtTqJ7sBvWfdKTCtl95 HQayAlN9n8AM7hDneIcv48LiK4i/xowpvDuXAu+IT+I477VtvBBTHR811JfjBHVxGs E2/hBD99SoKgrcLufnYvAyBKNvlaHZfM3zJhMAG8= Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 12:49:10 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2139066162-1455022145=:538 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 9 Feb 2016, Eric Burger wrote: > For that matter, one can argue that without security configuration, the > market has passed us by. My current experience is with MacOS. If you use > Gmail, iCloud mail, Yahoo! mail, AOL, or Exchange, your mail > configuration magically happens. If you are using a raw IMAP or POP3 > server, more especially if you are using a real submit server at a > different address, too bad for you. However, I’ll bet 99.995% of typical > users are using one of the big providers and would ask “why is the IETF > working on how to configure Gmail? It just works already. The IETF is > solving yesterday’s problems.” If we say, “because you get security,” > 99;995% of people would say, “the IETF is great!” +1 ! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; http://www.cert.garr.it/pgp/garr-cert-pgp-keys --0-2139066162-1455022145=:538-- From nobody Tue Feb 9 13:39:03 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121F51B2A66 for ; Tue, 9 Feb 2016 13:39:02 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 CF2aNp3sqvkK for ; Tue, 9 Feb 2016 13:39:00 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 85D8C1B2A61 for ; Tue, 9 Feb 2016 13:39:00 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id x65so240376pfb.1 for ; Tue, 09 Feb 2016 13:39:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=77Lpr4BXu/u33N66IxVzwwPTKxfNmNeQ8z/EBNly77Y=; b=bvRrniy1StbYxvI82L1yTucvwZjw+lQ5MFLCVCmHhMaNueSMG3IzvTEo7hVekdOJDs l9p2GOdbIynA9RjHOsD1j49nvjg4sRksWEF1Wrb7di5uf+pJBKIgLhm4VA8fgeirXn/X 8Z/w3lQ5KGi6wdJROMONr0E1LeIJ/e1scihWXKD1M3wD2RmVPFjusm+J0DdMfB3Xhzll ZmMiXrkDF2yyA3PI7CSK/D5SBmz1xqzQr5ToMnYrgFaiivZTgq7YZBlse6HhpnY5RoId mAN6GJlQAsHeAQTvyvCjM33ltGp8OVVLb6CDtONXD1UAt03fX/Z+NLOiU70zpsPLErF6 WMcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=77Lpr4BXu/u33N66IxVzwwPTKxfNmNeQ8z/EBNly77Y=; b=W1JIZ4vFSJzOm+WW1s/7dbBdh+kPirLtW9BycmoE5zlBNoKutfc9636rTMTJ2EcmQn q1fv4Xsm0G3rLMtmPf72dlz41MS72fe+b+JbM5CxM7CNAZYCjxCdjz0yEiaahMSmnIjf 9Q7NyApCfwWFvxbxq6QGmI2QAincV7ocgOgUSpzTtRjhp0uK9Mg0CtJCkO+4h5pkQTdF BllsPiNlSApJ+44sibTFMEm0L6orCpm3m+wLMjI/ZJej2kwxWRPeWu6FGm8rcXoslxRt tcNVNU/r3WEGtNqwF+AEtdVvSoySxLjaiKDLFwNbxHg62tkK4n3XB2cmPrIMYX9asAWl bS5w== X-Gm-Message-State: AG10YOTIMODRNWW1scR/sYDkA2ZvjLFA1PfeMD60CY3JgsbMPR0JmIW2AfEBm4xF76kNOQ== X-Received: by 10.98.43.151 with SMTP id r145mr21328398pfr.4.1455053940191; Tue, 09 Feb 2016 13:39:00 -0800 (PST) Received: from [192.168.1.4] ([75.174.2.244]) by smtp.googlemail.com with ESMTPSA id tp3sm4095pac.16.2016.02.09.13.38.59 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Feb 2016 13:38:59 -0800 (PST) To: apps-discuss@ietf.org References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <56BA5C72.7050708@gmail.com> Date: Tue, 9 Feb 2016 14:38:58 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003030703050906030704" Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Tue, 09 Feb 2016 21:39:02 -0000 This is a cryptographically signed message in MIME format. --------------ms050003030703050906030704 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maybe the there are two separate issues. - How to containerize and standardize passing of configuration information from service provider to consumer. Maybe a MIME type with sub-registration of protocol (email, calendar, VOIP, ...), and mandating it be sent encrypted. - How to transport that information across whatever transport is available. SRV record to MIME blob URL, sent in email, HTTP/FTP download, ... --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms050003030703050906030704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGwwggYwMIIFGKADAgECAgMNobowDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA0MDgwMTMzMzNaFw0xNjA0MDgxNzI3NDdaMEgxHzAd BgNVBAMMFmRvdWdsYXNyb3llckBnbWFpbC5jb20xJTAjBgkqhkiG9w0BCQEWFmRvdWdsYXNy b3llckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDV8lDK8TLv Lwjma4Lba4qcO6REc6G72ykoP585+CFo2otxTqfyg6m/mmynOkEupL7EM2JvsPOppaHeoNXq k2bia0pZevG6zLazQxGGlTMyle9qumru51INuyVVdPwlyJ6TuhvZVU7zuIinRWaIZgPmRQ+j mT8Abdpj0BZP+3cmDTUhkSEtsAHF11I0hQcyuI/LYWf1EBNujN3p9tzwxY5JKI0JHBDtiz4e N53nT4QQeKo2aBrCJXVIT0zxb5IzxPzvKPyi20HUrigtFpYlAT6/Kwopm3IuWRmQrEnTP8g4 JmacOtxGgnrPZvNskjbnwqtXBHlyVaoD3eL0j7Cfy/ShAgMBAAGjggLcMIIC2DAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFDn7j56P25uHeE2AeTdYArnzSW7hMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCEGA1UdEQQaMBiBFmRvdWdsYXNyb3llckBnbWFpbC5jb20wggFMBgNVHSAEggFDMIIB PzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBv c2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYD VR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADI7gAqJwpHOgbiMxyRp2K qmxAIpubAd9vgYPlrjsBmTvztSm2PiJFUF2uGqCGKkvTAVWVGMoV0QDfthU1GnFm3YgmZnTZ 7Ab/gqXTrl+ggUQXVjHcbzLqwyJ38tKaXHRgnvNwzHU9pBYuwO7ZEs+4pB6fcnyjgkbqigfu /FdxTPCmJwNaC2S1sYcesVz6iZEXGbAgmkuDW3alC9M2XCcT4jYrrCMsKhBrK5f+Hp/atvYH TSVJx5syilcplHOQ+Mg2fgCDFVVvDL1G+YEUUA0aLyD2uGLtPGF9E57kYDe/diEmprNz2wLZ R4F1PzCVPF55NaokjfEyrREj/uShZCyFMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYD VR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYB BAGBtTcBAgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6 rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWC tosmAOT4OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTut R08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eD F1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKE Q/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzx d2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulc NJ8tKmVtjYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapS n+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9 dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPt MIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMNobowDQYJ YIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDIwOTIxMzg1OFowLwYJKoZIhvcNAQkEMSIEIBnio7uQiRKlRMm2GKarTBv4KydJ 8T6StpQdCICbi3TlMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMNobowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2hujANBgkqhkiG9w0BAQEFAASCAQBp8nGm7p1C 6fgNkPVnflUljvZmyNXGYVMeSFs6Pp39PVHD6hpTTEcEIhccogLAyOhUkV46mS2EkMoZTRTh Qml7vNiYd/Fs+80DIdfMPAgbZRi2KbYQwSXRygl0cemcCwkeZpBoj+vUgNwuVKYeReCyaJKD HxwkJ1TGnDHp/g4g0G9oO5GEbqG4+qtUuRmGrXscvwDuAwSHRpKY2zNU2S3kePHJMRZIyMTs jfRjo0hI2qttUzDE+5moj0auhAMrd0drZRNnpuF4/J5w8JoR+ytbpFm9squQlHwGXDRekFmd mcJtfrvjD5ksq+Y5t+ARO+lZtPS8me6vzEht+GTO5GooAAAAAAAA --------------ms050003030703050906030704-- From nobody Tue Feb 9 19:00:01 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D18F1B3577 for ; Tue, 9 Feb 2016 19:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 yr3aT0dDe11J for ; Tue, 9 Feb 2016 18:59:59 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636941B35B4 for ; Tue, 9 Feb 2016 18:59:59 -0800 (PST) Received: (qmail 41015 invoked from network); 10 Feb 2016 02:59:57 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 02:59:57 -0000 Date: 10 Feb 2016 02:59:35 -0000 Message-ID: <20160210025935.98561.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <56BA5C72.7050708@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: douglasroyer@gmail.com Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 03:00:00 -0000 >Maybe the there are two separate issues. > > - How to containerize and standardize passing of configuration information ... > - How to transport that information across whatever transport is available. I'm a big fan of not inventing stuff if we don't have to. First I'd like to understand why mail clients don't implement RFC 6186. It seems to me that for a whole lot of mail users, it provides all the configuration info they need. I realize there are mail systems where the e-mail address isn't the user ID, and systems where users in a single domain are assigned to different servers, but there sure are a lot of systems including the very largest where that's not a problem. If the answer is anything other than inertia, that might give us some guidance as to what a better design would look like. If, as I suspect, the answer really is inertia, a new design is unlikely to be any more successful. R's, John From nobody Wed Feb 10 01:12:36 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C201A0364 for ; Wed, 10 Feb 2016 01:12:20 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 wYU3fGY5ObpO for ; Wed, 10 Feb 2016 01:12:19 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9091A036B for ; Wed, 10 Feb 2016 01:12:18 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5C8F5FA007C; Wed, 10 Feb 2016 09:12:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1455095536; bh=cW1hRGW7CORIl9DUjHJL+Fgq0deq4uqw9iwYEoulcos=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ke/S5pxvmFlmIkzc8+BeeLRECBtVOJk8TmApnmMT7c8ECAAfDuHc1FrO1QovESBqN /HsbGBtFz92013l1vbwwgXDsgaK6/GK5kNfg1hkNHl6TZciwOp/Z//X9/4kZEIUm/H 5i8ukY8AFAxM9BK59i8a5lb2dd9AT7x4WkWxnG2Y= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1455095535-19606-19604/11/15; Wed, 10 Feb 2016 09:12:15 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Wed, 10 Feb 2016 09:12:15 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: <34649d36-5bf5-4778-a9c6-e61f0c3a70a0@gulbrandsen.priv.no> In-Reply-To: <20160210025935.98561.qmail@ary.lan> References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <56BA5C72.7050708@gmail.com> <20160210025935.98561.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 09:12:20 -0000 X-List-Received-Date: Wed, 10 Feb 2016 09:12:20 -0000 John Levine writes: > First I'd like to understand why mail clients don't implement RFC > 6186. a) Client support for SRV is oddly poor, to the point where I've seen XMPP clients not do SRV lookups. b) There's another way that achieves better results for comparable effort (accessing a mozilla-maintained database). c) ... I'm sure there's more. Arnt From nobody Wed Feb 10 09:05:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBAB1B2CE4 for ; Wed, 10 Feb 2016 09:05:09 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 P5TvoaRJhqvH for ; Wed, 10 Feb 2016 09:05:08 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 E6F431B2CE2 for ; Wed, 10 Feb 2016 09:05:07 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id dk10so1382467pac.1 for ; Wed, 10 Feb 2016 09:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=LlYE1zD62p5m3uoExjDw5cp1SkqLI+dsViXb5PKHh+s=; b=jjaxB2it86Ee0UgBxQu4zaqSH3oA0tf2Z2Wg+268FFJX2x3AZYmxCmqhpYpWowxDfq 0ksqRjp9+FPkZxycknp6p/Doo3ODyegWLYfVubi7YeliUGf2/Opz8FWG0vOlctUJdMF6 b/MzFvLdp6XMNr1gHnQmZIH0UEwDoM97oNra1HZK8faMKUHnRobzwrXAxbc24MtceetH EslqXWOxuvEVcaz0HTksGWRJV9NWc+uSvKnCKuv+bEkZdhCOiRhWcAq4kmwi1aoLWaXp dhjATwZrvYUeRXmErhhCUgChzTkSlJCd0VUJi/V5AojDAwqahGfqqZpL/lR07zSHi4d6 erNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=LlYE1zD62p5m3uoExjDw5cp1SkqLI+dsViXb5PKHh+s=; b=LTybghtuCcGSXTJamnkEqA7hrEaaUaw+ocq/d/0Z9oSP8FHJmx7jBXRT0+Mh+V2+kn 6U8a2RJe0IhZuV/+NohpSUtLYpZO/8Ob7/c1/WztclRt0Hcdla6kZs5jsAKOO4cEQ4fG zKy7lY8Vw1YupOLUFccYadDGwpCpRHMhUGzhNJos0OvEl1rCznGmeEMQjlxFVkF/LDzi I8Xp3JdVgJkBERfLKhSNpCpspbzJFyDcR/PAsL+OJmiEurMLHkX1PFkBoxpw3aqnkCYh loTZFaVrgmJQut12p6VhY7C9IjNWRGqTFftbdbYr1PSeuLyLaCUquLSfgVx+mkpv+VxZ A5bg== X-Gm-Message-State: AG10YOTYYZt+DM1ChyPusQgMZiC4C/jl7zQJQbI8UCxbqcUZJv4erSPUjHw19ll69ytPfw== X-Received: by 10.66.100.163 with SMTP id ez3mr60100612pab.5.1455123907617; Wed, 10 Feb 2016 09:05:07 -0800 (PST) Received: from [192.168.1.4] (184-99-102-85.boid.qwest.net. [184.99.102.85]) by smtp.googlemail.com with ESMTPSA id r77sm6471521pfa.47.2016.02.10.09.05.06 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 09:05:06 -0800 (PST) To: apps-discuss@ietf.org References: <20160210025935.98561.qmail@ary.lan> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <56BB6DC1.9040709@gmail.com> Date: Wed, 10 Feb 2016 10:05:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160210025935.98561.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000902050201070006030401" Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 17:05:09 -0000 This is a cryptographically signed message in MIME format. --------------ms000902050201070006030401 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/09/2016 07:59 PM, John Levine wrote: >> Maybe the there are two separate issues. >> >> - How to containerize and standardize passing of configuration informa= tion ... >=20 >> - How to transport that information across whatever transport is avail= able. >=20 > I'm a big fan of not inventing stuff if we don't have to. >=20 > First I'd like to understand why mail clients don't implement RFC > 6186. It seems to me that for a whole lot of mail users, it provides > all the configuration info they need. I realize there are mail > systems where the e-mail address isn't the user ID, and systems where > users in a single domain are assigned to different servers, but there > sure are a lot of systems including the very largest where that's not > a problem. (1) I just checked GMAIL, YAHOO, AOL, HOTMAIL, and my ISP. Only GMAIL seems to -mostly- provide the correct information. Gmail SRV returns: _submission._tcp.gmail.com. 86400 IN SRV 5 0 587 smtp.gmail.com. Yet I have to use port 465 (not 587 in the SRV record). 587 simply fails for me - I did not care why. (2) Some ISP's want your email address in all lower case when authenticating, others want it as you entered it. When I setup with my isp, it asked what email address I wanted: I entered "DougRoyer", so that is how I entered my account name. I have to use DougRoyer (and not dougroyer@isp, DougRoyer@isp, or dougroyer) as the authentication name. It took me an hour or so to figure that out. Some accounts have nothing to do with the email address. Your authentication is your phone number, account number, or some unrelated string. (3) Password type is not Not in 6186: Plain, Encrypted, Kerberos/GSSAPI, NTLM, TLS-Certificate, or OAUTH. Some MUA's ask, users do not understand the question. (4) And with Kerberos most users have no clue how to setup their email. (5) With TLS-Certificate, it fails, until they get their certificate, so they don't push SRV records, they just provide the user with the connection information. (6) Different IMAP/POP and submission servers per user, as in: I want my east coast users to use imap.east.example.com, and the west coast users to use imap.west.example.com. Engineering uses IMAP on UNIX, sales uses POP3 as they use an exchange server because it works with their sales tools. Load balancing, some users use smtp.host-a, others smtp.host-b... So they do not push any SRV records. > If the answer is anything other than inertia, that might give us some > guidance as to what a better design would look like. If, as I > suspect, the answer really is inertia, a new design is unlikely to be > any more successful. It looks like lack of inertia and confusion. I helped a friend with an ISP that offers POP3 free. If you want IMAP, you pay extra. That ISP considers the 'preferred' service IMAP. You can connect with IMAP, but get no email if you expected the free service. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms000902050201070006030401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGwwggYwMIIFGKADAgECAgMNobowDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA0MDgwMTMzMzNaFw0xNjA0MDgxNzI3NDdaMEgxHzAd BgNVBAMMFmRvdWdsYXNyb3llckBnbWFpbC5jb20xJTAjBgkqhkiG9w0BCQEWFmRvdWdsYXNy b3llckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDV8lDK8TLv Lwjma4Lba4qcO6REc6G72ykoP585+CFo2otxTqfyg6m/mmynOkEupL7EM2JvsPOppaHeoNXq k2bia0pZevG6zLazQxGGlTMyle9qumru51INuyVVdPwlyJ6TuhvZVU7zuIinRWaIZgPmRQ+j mT8Abdpj0BZP+3cmDTUhkSEtsAHF11I0hQcyuI/LYWf1EBNujN3p9tzwxY5JKI0JHBDtiz4e N53nT4QQeKo2aBrCJXVIT0zxb5IzxPzvKPyi20HUrigtFpYlAT6/Kwopm3IuWRmQrEnTP8g4 JmacOtxGgnrPZvNskjbnwqtXBHlyVaoD3eL0j7Cfy/ShAgMBAAGjggLcMIIC2DAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFDn7j56P25uHeE2AeTdYArnzSW7hMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCEGA1UdEQQaMBiBFmRvdWdsYXNyb3llckBnbWFpbC5jb20wggFMBgNVHSAEggFDMIIB PzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBv c2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYD VR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADI7gAqJwpHOgbiMxyRp2K qmxAIpubAd9vgYPlrjsBmTvztSm2PiJFUF2uGqCGKkvTAVWVGMoV0QDfthU1GnFm3YgmZnTZ 7Ab/gqXTrl+ggUQXVjHcbzLqwyJ38tKaXHRgnvNwzHU9pBYuwO7ZEs+4pB6fcnyjgkbqigfu /FdxTPCmJwNaC2S1sYcesVz6iZEXGbAgmkuDW3alC9M2XCcT4jYrrCMsKhBrK5f+Hp/atvYH TSVJx5syilcplHOQ+Mg2fgCDFVVvDL1G+YEUUA0aLyD2uGLtPGF9E57kYDe/diEmprNz2wLZ R4F1PzCVPF55NaokjfEyrREj/uShZCyFMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYD VR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYB BAGBtTcBAgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6 rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWC tosmAOT4OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTut R08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eD F1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKE Q/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzx d2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulc NJ8tKmVtjYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapS n+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9 dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPt MIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMNobowDQYJ YIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDIxMDE3MDUwNVowLwYJKoZIhvcNAQkEMSIEINcj5pu6o8yF4rq4H3ftds3JRmSq o4KHghxqEHpnhskaMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMNobowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2hujANBgkqhkiG9w0BAQEFAASCAQAEYFzDZAS/ g3LK2fKVbKLNTDOBHtoqQgiBLKKS9DkaajIf+X23IqQ2rMb31P8HL7gsjQpBEB5ylRnYrsZm 1AIi23qw5z16dvVY7KGyTxUzRU9FHgoWzSoz6CuFYqylkeQQBNStqTDoWZnAXsok+kgznRdc ZDJdjgcw8eJZ8sHt9elR4KzlI2jY8OMwbgCammbbCqRrrIUywEnbaV+tgn2Cxko/8HyTSIJ3 BtHQOknOhyf9XSVXLwpHpMQvXBiq1FUHHrJU1QFarU/iz/LUwDQ/xe7TYOoeYJYRaQ0nTHho iUkub6pcmvYFOAtgf2SUCfeTOHbwjQHu0Ap/MCC3F2cJAAAAAAAA --------------ms000902050201070006030401-- From nobody Wed Feb 10 09:43:01 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F631B2D8E for ; Wed, 10 Feb 2016 09:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.012 X-Spam-Level: X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=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 rUFkSiYi9rV7 for ; Wed, 10 Feb 2016 09:42:58 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E091B2D84 for ; Wed, 10 Feb 2016 09:42:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=In-Reply-To:To:References:Date:Subject:Mime-Version:Message-Id:Content-Type:From; bh=0SuOLZQTEzrBxjjI1PsXHKqsljfu1yy+zjrYxR7tFss=; b=Z83lowoyRfH4ifxzzz1kUN9WHfgvBf6MUzvQZO79EXJ6ve2wT+dCLFpOxhfgsHbO8bVfVIig0kwjZD5UBJ2ab6tBctdoFlDeNEITr2O2BDCEN4wQJ/lVT7bRB63vN+dbUfs4sEp7cgpOb551SloV2ciBQei1XznI2HKpJNtoiwY=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:49364 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1aTYn0-0003BR-WB for apps-discuss@ietf.org; Wed, 10 Feb 2016 09:42:56 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_407DFB5A-0733-4D66-AD44-8A5B7EFF2B72"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Wed, 10 Feb 2016 12:42:53 -0500 References: <20160210025935.98561.qmail@ary.lan> <56BB6DC1.9040709@gmail.com> To: apps-discuss@ietf.org In-Reply-To: <56BB6DC1.9040709@gmail.com> X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 17:42:59 -0000 --Apple-Mail=_407DFB5A-0733-4D66-AD44-8A5B7EFF2B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am pleasantly surprised - you have an ISP that respects the RFC that = states the user part *is* case sensitive. Most ignore that. Oh well. > On Feb 10, 2016, at 12:05 PM, Doug Royer = wrote: >=20 > (2) Some ISP's want your email address in all lower case when > authenticating, others want it as you entered it. When I setup with my > isp, it asked what email address I wanted: I entered "DougRoyer", so > that is how I entered my account name. I have to use DougRoyer (and = not > dougroyer@isp, DougRoyer@isp, or dougroyer) as the authentication = name. > It took me an hour or so to figure that out. --Apple-Mail=_407DFB5A-0733-4D66-AD44-8A5B7EFF2B72 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKAjCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUswggQzoAMCAQICEDgWOMX3+9J1/6GS/3sX20UwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTEwMjIwMDAwMDBaFw0xNjEw MjEyMzU5NTlaMCsxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1UrYlNk4PJUOGquyc812REEGppnhhkoMvXJb KkvETnoDwRTwG5OEflXiA6KfdPMwdLN8aSlSMW1FnXYN5pzyv3fC7h0nL06FsznuLrC959J2J8a2 XHITJHEDZ3L8GaOXnAW6P9m4VP3lxCdvpQrk2nDY5P+CIEQXaD1a1EtFnTttnWXoBBwBVoVgEV+H 0ZtJ9ej+N1PmA1cAIIfWJ0kK5sscl9l2Ea1n3oIuPRQMdCjDXGUoMbarPjueGYhcP+ynsm8oIfsb ky3DiTJw6u3IIzIWpvjGsH5cWYMOfRsgr/MEdM0cpMGpzv4pvTEkpFo9SxoLeKx75jMG5JkMmZOF pwIDAQABo4IB+DCCAfQwHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYE FJwfBGiMmQE92q6NOIBH8x0apIhyMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1Ud JQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8w PTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5l dC9DUFMwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hB MjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEE gYMwgYAwWAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQsFAAOCAQEAEw0iIyTMKof6LCMDOBoszR8FWwVA0sdljpuTZQtsBf9EacYz 0RetOohwfgzLhDnfDGeSw9RXIokjaqDjJgs96PXsSZp0G89sL9QGHizbjXd2MlVS/OiIt8jQavZz Wy2fttDyj/jCuOLYzfJBV0QLk14nS6c/cVdolMf2lYIbu+dwMCiN/0VC4ROSHAZBiRenW8cDsxDQ lKtoGn/uXnw3mDY7Iv2SQVLCURNIbvBDRoOwvn8Gev873NFmNwvuT6xrlN1ieWY4d2xxZVRG9vC6 sSdO4AR9lBfRmI3Jk8+dvwTOK5ItpMJs92DDmIX6E0leRm7ajUuTF8iy0UbT4KXnNDGCA8MwggO/ AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RP IFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDgWOMX3 +9J1/6GS/3sX20UwCQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTYwMjEwMTc0MjUzWjAjBgkqhkiG9w0BCQQxFgQUwLI40YGU/yJwbM22J8RG 3gqddVwwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhA4FjjF9/vSdf+hkv97F9tFMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhA4FjjF9/vSdf+hkv97F9tF MA0GCSqGSIb3DQEBAQUABIIBAKcgHIUec2MZaSM5r4wdBPG5cQRsQhaqyjIQ3sIT7z7MBjs6kw9F pbU8kDhSOKFZkxFkblxBcltUQo8fpYgtXzFEcy2ZXbTeXiiofcB+bWCFyp1pbgQGQ8lAUyCCbKeC LhfguPzA4pmgcl3XcI+yJkbRIVogWb3xWWow+C76Ro3ggK8IEjvK/r7v0vz3A8zmq2ep91q+iQnO GIpvc6jnwm7VwUu5yxt4K9Xbs0V/u9Q5U3zfrP457zMtCAifBjEu6OaaFrHVMXYRm0w4PN0EM+PF 7c5WWlSAW4YZjMQwWs0CtoMN4FLMFARDJi2x6Zb8KcHbC6HMQzR/oFF5wrrEcfgAAAAAAAA= --Apple-Mail=_407DFB5A-0733-4D66-AD44-8A5B7EFF2B72-- From nobody Wed Feb 10 10:07:10 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD4C1B2E5B for ; Wed, 10 Feb 2016 10:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lkd43ZsluahQ for ; Wed, 10 Feb 2016 10:07:07 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0E001B2E59 for ; Wed, 10 Feb 2016 10:07:07 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1aTZAQ-000DX9-Av; Wed, 10 Feb 2016 13:07:06 -0500 Date: Wed, 10 Feb 2016 13:07:01 -0500 From: John C Klensin To: Doug Royer , apps-discuss@ietf.org Message-ID: <08FAFF5DC9CAADC88965B7F1@JcK-HP8200.jck.com> In-Reply-To: <56BB6DC1.9040709@gmail.com> References: <20160210025935.98561.qmail@ary.lan> <56BB6DC1.9040709@gmail.com> 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-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 18:07:09 -0000 --On Wednesday, February 10, 2016 10:05 -0700 Doug Royer wrote: >... > (1) I just checked GMAIL, YAHOO, AOL, HOTMAIL, and my ISP. > Only GMAIL seems to -mostly- provide the correct information. > > Gmail SRV returns: > > _submission._tcp.gmail.com. 86400 IN SRV 5 0 587 > smtp.gmail.com. > > Yet I have to use port 465 (not 587 in the SRV record). 587 > simply fails for me - I did not care why. > > (2) Some ISP's want your email address in all lower case when > authenticating, others want it as you entered it. When I setup > with my isp, it asked what email address I wanted: I entered > "DougRoyer", so that is how I entered my account name. I have >... Doug, I learned a few things from your note, most of which, sadly, I had already guessed at. One is a reminder about where at least some of the complexity of ACAP comes from (I think there is more than is necessary, but that is another question). Unless we are going to change a lot of habits, conventions, and operational decisions that make perfectly good sense in their own environments, we need a system that is flexible enough to deliver configuration information to different users (and their MUAs/ Clients) based on location (sometimes "normal", sometimes "right now"), on user or client identifier (which may or may not be connected to a mailbox name in an obvious way), on properties of the client software, etc. In some, probably most, cases, the server from which the information comes will make the decisions and send out only the specific information needed to configure the client but there will be cases where it would be better to send out information that gives the client choices that only it can evaluate. For some situations, it will need to receive the request and send the response in encrypted form; for others that may be unnecessary, undesirable, or worse. To the extent to which the location or client software are involved in the decision about what to send out, whatever is done will have to work despite our best efforts to obscure the information in the interest of privacy, leading to some of the use cases for sending out a lot of information and letting the client choose. Now, while I still think ACAP is too complex and probably includes fundamental design flaws, the above fairly strongly suggests that a DNS record or two, or even invocation of WebFinger or something else popular, might be part of the solution, but are, at best, only a small part... and might encourage sloppy thinking that fails to cover a lot of important cases. If we do want to include those cases, this isn't going to be an easy problem, and that brings us back to John Levine's question about inertia (among others). john From nobody Wed Feb 10 10:18:48 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9281A1B2E64 for ; Wed, 10 Feb 2016 10:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=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 yD6qQqgcrGhT for ; Wed, 10 Feb 2016 10:18:46 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155291AC40E for ; Wed, 10 Feb 2016 10:18:45 -0800 (PST) Received: (qmail 5046 invoked from network); 10 Feb 2016 18:18:44 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 18:18:44 -0000 Date: 10 Feb 2016 18:18:22 -0000 Message-ID: <20160210181822.1369.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <56BB6DC1.9040709@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: douglasroyer@gmail.com Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 18:18:47 -0000 >(1) I just checked GMAIL, YAHOO, AOL, HOTMAIL, and my ISP. Only GMAIL >seems to -mostly- provide the correct information. > >Gmail SRV returns: > >_submission._tcp.gmail.com. 86400 IN SRV 5 0 587 smtp.gmail.com. > >Yet I have to use port 465 (not 587 in the SRV record). 587 simply fails >for me - I did not care why. I just tried it, port 587 and STARTTLS works fine. Perhaps your MUA doesn't know that port 587 needs STARTTLS rather than doing the TLS at connection time, a bug that should be easy to fix. Gmail does require that you create a separate per-app password on their web site for every device that logs into gmail, but automating that seems rather beyond what we're looking at here. Yahoo, Hotmail, and AOL also all have single servers per service (pop, imap, submit) with the address as the username, so RFC 6186 would work if they published the SRV records. So do Comcast and Time-Warner and Verizon and AT&T. Comcast even publishes the SRV records. >(2) Some ISP's want your email address in all lower case when >authenticating, others want it as you entered it. Really? Can't ever remember that being a problem. In any event, you'd have exactly the same problem with webfinger and anything else if they want to be picky about upper/lower case. >Some accounts have nothing to do with the email address. Your >authentication is your phone number, account number, or some unrelated >string. Yes, I know. This is not a 100% solution, nothing is. The question is whether it is a 95% solution that's worth encouraging people to implement. >(3) Password type is not Not in 6186: Plain, Encrypted, Kerberos/GSSAPI, >NTLM, TLS-Certificate, or OAUTH. Some MUA's ask, users do not understand >the question. Then the MUAs are broken, since the MSA tells them what kind of auth they can use, at least amoung plain, encrypted, and GSSAPI. If we invented something new, they'd probably get that wrong, too. >(6) Different IMAP/POP and submission servers per user, as in: > >I want my east coast users to use imap.east.example.com, and the west >coast users to use imap.west.example.com. Yes, for the umpteenth time, RFC 6186 is not a 100% solution. But it sure seems like a 95% solution to me. R's, John PS: >That ISP considers the 'preferred' service IMAP. >You can connect with IMAP, but get no email if you expected the free >service. We definitely can't cure stupid. From nobody Wed Feb 10 10:24:40 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD531B2E97 for ; Wed, 10 Feb 2016 10:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.964 X-Spam-Level: *** X-Spam-Status: No, score=3.964 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, MANGLED_TEXT=2.3, SPF_PASS=-0.001] autolearn=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 ePPiZtxSbN2n for ; Wed, 10 Feb 2016 10:24:31 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C691B2E5B for ; Wed, 10 Feb 2016 10:24:30 -0800 (PST) Received: (qmail 5916 invoked from network); 10 Feb 2016 18:24:29 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 18:24:29 -0000 Date: 10 Feb 2016 18:24:07 -0000 Message-ID: <20160210182407.1404.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 18:24:35 -0000 >I am pleasantly surprised - you have an ISP that respects the RFC that states the user >part *is* case sensitive. Most ignore that. Oh well. No, that's not what the RFC says. It says it's up to the mail system to decide what the local part means. It's perfectly valid for a mail system to treat ASCII case variants of the local part of its mailboxes as equivalent, and I have to say it's been a long time since I've seen one that doesn't. I wonder what system Doug is using that cares, and how old its code is. R;s, John PS: Where it gets a lot hairier is with optional characters like dots in gmail names, optional suffixes like user+ext@domain or user-ext@domain, and the whole world of EAI and UTF-8 where I am sure there are all sorts of things that are obviously equivalent in some languages and not in others. From nobody Wed Feb 10 10:34:29 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A9F1B2E74 for ; Wed, 10 Feb 2016 10:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TEXT=2.3] autolearn=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 2Q18PjuC4drI for ; Wed, 10 Feb 2016 10:34:26 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4621ACE31 for ; Wed, 10 Feb 2016 10:34:26 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5743EFA007C; Wed, 10 Feb 2016 18:34:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1455129264; bh=mqdmhmrhrw95INCf1M2f7hMF3Mmw0S/Ziy+BuPUaix0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Y56vMpsgwgwLuSyYnnPVd54uCUKXhF6yAYBUDYPJABGDrd6Svrqx/9LJEaM7kjJJf /bWa2x+fGAOV4bp+Mx9qZ9UrTsWRHo9CByTXVDb7H7NOVhwSKFubL4vgU2EnUwFf/N pMDJWIm9PrPL8Rrfv7t4Sv9SZ3BEC7JkyIFN0bSs= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1455129262-19608-19604/11/8; Wed, 10 Feb 2016 18:34:22 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Wed, 10 Feb 2016 18:34:22 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: <5e3d7843-b3c8-4baa-b2da-2683fc36df84@gulbrandsen.priv.no> In-Reply-To: <20160210182407.1404.qmail@ary.lan> References: <20160210025935.98561.qmail@ary.lan> <56BB6DC1.9040709@gmail.com> <20160210182407.1404.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 18:34:27 -0000 John Levine writes: > PS: Where it gets a lot hairier is with optional characters like dots > in gmail names, optional suffixes like user+ext@domain or > user-ext@domain, and the whole world of EAI and UTF-8 where I am sure > there are all sorts of things that are obviously equivalent in some > languages and not in others. The EAI situation is better than you probably think, mostly because the unicode committee does very good work and the rest of the world is lucky that it does. Arnt From nobody Wed Feb 10 10:37:01 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A221ACE31 for ; Wed, 10 Feb 2016 10:37:00 -0800 (PST) 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] autolearn=ham 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 6_7O-dJ1IOiI for ; Wed, 10 Feb 2016 10:36:58 -0800 (PST) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F861B2E70 for ; Wed, 10 Feb 2016 10:36:57 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4C761FA007C; Wed, 10 Feb 2016 18:36:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1455129416; bh=RfjNAQBLA0yy9GuLk1F+ObRTyGCTldpalDUKUDljiks=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iV1A7+TBD7EqcE6+WzyC1C8hNG8w6Bk3JgeXHhpXwBBYvHqCKUs96wqP4OE70xoCP AKb9v+6/lffUldogvdhc0n9Te6sQQEzqOPVErMpop3ANHIBYwQoCETOKVPFGpTeqRX NZCyJ4HfRo9vxqs/78qqBRRK187kZ1yibulBJXpk= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1455129415-28409-19604/11/7; Wed, 10 Feb 2016 18:36:55 +0000 From: Arnt Gulbrandsen To: apps-discuss@ietf.org Date: Wed, 10 Feb 2016 18:36:54 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Debian GNU/Linux 8.2 (jessie) Mime-Version: 1.0 Message-Id: <909b1eba-e886-4369-89c6-d310b9dfe504@gulbrandsen.priv.no> In-Reply-To: <20160210181822.1369.qmail@ary.lan> References: <20160210025935.98561.qmail@ary.lan> <56BB6DC1.9040709@gmail.com> <20160210181822.1369.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 18:37:00 -0000 John Levine writes: > Gmail does require > that you create a separate per-app password on their web site for > every device that logs into gmail, but automating that seems rather > beyond what we're looking at here. That's not entirely true. If you don't do that, you're at mercy of per-user configuration, but my account worked fine without any changes that I can remember. >> (2) Some ISP's want your email address in all lower case when >> authenticating, others want it as you entered it. > > Really? Can't ever remember that being a problem. In any event, you'd > have exactly the same problem with webfinger and anything else if they > want to be picky about upper/lower case. IIRC Thunderbird used to probe about 140 combinations of things just-localpart or whole-thing, lower-case vs exact, various default names, ports 25 vs 587. All very boring really. Arnt From nobody Wed Feb 10 10:57:08 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016E51B2ECE for ; Wed, 10 Feb 2016 10:57:06 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 cDHu_Yt8avi6 for ; Wed, 10 Feb 2016 10:57:04 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (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 882861B2ECD for ; Wed, 10 Feb 2016 10:57:04 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id yy13so15974456pab.3 for ; Wed, 10 Feb 2016 10:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=TMWYVZh8bDsezGFciW8OkI7eo0VMTdiQITLLuHfQiE0=; b=pkEWx5Tod3Bj6HfJNOzSn8p60ea4YTmz7U6Ssd0vKprIZXFSdIqQ6K5xSDPKCeL59y K1sSQvwRIHL46D3fZcLJkpAwnJz/bOvL0yIHe7jHNUvgEtZ7UUvO8r9C4/toay0UGpiO P5xVmltSUHmfycoGonmpdKhcmCgAEfUZrw50pO/N+lIy/GmJc6rGpQHZ5tkFg/j4SOkU 8tnbeApa6VFuK91xyxdz/D/lTG/Q8XETyMu/WZN3LsGA9RZM5gMC3iutZOq6zK5YLzYd m/MZry+SgEWVbUre8k7+fdHGXF1SdbyY1A4ZYy+yiz0a8tzxi1hXXu5ioRwnh0MO5Q3y D9BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=TMWYVZh8bDsezGFciW8OkI7eo0VMTdiQITLLuHfQiE0=; b=EU6ZlAu5jsu41xlsDpPfSGhBZwT4yEGwKatYPzO+PWIVcG3T9she0Dv7s89DryJcyb 5R5Kk27J/nDIk5nSncdoPaRC9tq+UduwV/qHrFTPuLvSYanrqHNQJS4eiY2CYSymUr5a 0mhKBMr2IAzpPiv71mlX/7/EBeNHm1EkkYDWQNReRsdfZ+p82YyC22mxQmmh682Jb0mf t/PQMxHV0jiumewxN8dukRFRJav9BQ/TLrXRwRPsDSem0ExOGrauAr2NxUrpC3Bmmdgr gfSB/gdk5LG/ETNKtk+22ylPq3E0AXxeHbv4K1LTYyCGn+XgepbVSywIYHYUG8FSG7Lo pBUw== X-Gm-Message-State: AG10YORZ/2Nn0wIsad+HYRFrpApgxPc+ha1N9BOdbrV9yhBH4jSbBZ+Gxk/gHVa2wLNbfQ== X-Received: by 10.66.150.170 with SMTP id uj10mr16568781pab.73.1455130624170; Wed, 10 Feb 2016 10:57:04 -0800 (PST) Received: from [192.168.1.4] (184-99-102-85.boid.qwest.net. [184.99.102.85]) by smtp.googlemail.com with ESMTPSA id 6sm6876935pfo.58.2016.02.10.10.57.03 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 10:57:03 -0800 (PST) To: apps-discuss@ietf.org References: <20160210181822.1369.qmail@ary.lan> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <56BB87FE.3070703@gmail.com> Date: Wed, 10 Feb 2016 11:57:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160210181822.1369.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070902040707050205000005" Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 18:57:06 -0000 This is a cryptographically signed message in MIME format. --------------ms070902040707050205000005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/10/2016 11:18 AM, John Levine wrote: > ... >=20 > Yes, for the umpteenth time, RFC 6186 is not a 100% solution. But it > sure seems like a 95% solution to me. I know, I just wanted to list the issues found over the last few years. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms070902040707050205000005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGwwggYwMIIFGKADAgECAgMNobowDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA0MDgwMTMzMzNaFw0xNjA0MDgxNzI3NDdaMEgxHzAd BgNVBAMMFmRvdWdsYXNyb3llckBnbWFpbC5jb20xJTAjBgkqhkiG9w0BCQEWFmRvdWdsYXNy b3llckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDV8lDK8TLv Lwjma4Lba4qcO6REc6G72ykoP585+CFo2otxTqfyg6m/mmynOkEupL7EM2JvsPOppaHeoNXq k2bia0pZevG6zLazQxGGlTMyle9qumru51INuyVVdPwlyJ6TuhvZVU7zuIinRWaIZgPmRQ+j mT8Abdpj0BZP+3cmDTUhkSEtsAHF11I0hQcyuI/LYWf1EBNujN3p9tzwxY5JKI0JHBDtiz4e N53nT4QQeKo2aBrCJXVIT0zxb5IzxPzvKPyi20HUrigtFpYlAT6/Kwopm3IuWRmQrEnTP8g4 JmacOtxGgnrPZvNskjbnwqtXBHlyVaoD3eL0j7Cfy/ShAgMBAAGjggLcMIIC2DAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFDn7j56P25uHeE2AeTdYArnzSW7hMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCEGA1UdEQQaMBiBFmRvdWdsYXNyb3llckBnbWFpbC5jb20wggFMBgNVHSAEggFDMIIB PzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBv c2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYD VR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADI7gAqJwpHOgbiMxyRp2K qmxAIpubAd9vgYPlrjsBmTvztSm2PiJFUF2uGqCGKkvTAVWVGMoV0QDfthU1GnFm3YgmZnTZ 7Ab/gqXTrl+ggUQXVjHcbzLqwyJ38tKaXHRgnvNwzHU9pBYuwO7ZEs+4pB6fcnyjgkbqigfu /FdxTPCmJwNaC2S1sYcesVz6iZEXGbAgmkuDW3alC9M2XCcT4jYrrCMsKhBrK5f+Hp/atvYH TSVJx5syilcplHOQ+Mg2fgCDFVVvDL1G+YEUUA0aLyD2uGLtPGF9E57kYDe/diEmprNz2wLZ R4F1PzCVPF55NaokjfEyrREj/uShZCyFMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYD VR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYB BAGBtTcBAgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6 rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWC tosmAOT4OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTut R08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eD F1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKE Q/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzx d2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulc NJ8tKmVtjYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapS n+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9 dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPt MIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMNobowDQYJ YIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDIxMDE4NTcwMlowLwYJKoZIhvcNAQkEMSIEIFT2HRe0GCSazyR/P5lrEMxMPG59 8H3SulsX002BuxQKMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMNobowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2hujANBgkqhkiG9w0BAQEFAASCAQBkU86PEpwP eEneRCgMvKwv0pc4cArH+CqbAoNZdURgiErTAcvFWEwhPfke8r8pwy+9HRu+hqTV3l6yILsj 34ag+HXywjEkgvyp+PaRqOsLHBZIdVLwjEk7gDy60tCqbZQYgd1ZUJWovctInpH/HzXEIull 3rHRwzomV/Hf+mSAvl40KNE9weltliFUh6Zsg28xDrJIeSRGAljrzBDOX0Fvi6Zad0TzJdFl d9ozQLftJUhHU9crH2Vbikrr7YiTH9keSIBHbG5st2DVf4TIaGguGs0V7NiI5uYmgYbuchP4 l11y3HQ8zFKBtmmgG3gUy+0/F6L8xwy1QxVavNnuiiktAAAAAAAA --------------ms070902040707050205000005-- From nobody Wed Feb 10 11:10:54 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3B61B2EDE for ; Wed, 10 Feb 2016 11:10:52 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 4WpLScGmj9Gv for ; Wed, 10 Feb 2016 11:10:50 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 B6E9A1B2ED7 for ; Wed, 10 Feb 2016 11:10:50 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id q63so16443888pfb.0 for ; Wed, 10 Feb 2016 11:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=ETz0n5Q5xPzIqlWzwxdQE7Imxlk36bnPhhsstTahZ0w=; b=1D2OTSxStxhQuFdaDFzNIDw9ZS/1YLC0ocvnhzflyzQx4A5y5rBmNig+qxo/lkX6SY SzQYNfqnUq7MKsITyOinXIipKC0zA4+UkQhz1aYOpBCpYZr41sDZoUngTVhSiMMInNWy S/T93MVAnqbOTVlodlOqXzpfvs5vPSO6ycMSABVHmDCNTzBP2sAgACMK55n7w2wAps0F KKyJ8p/Qas47mdUsgoYd5WdyBc0wRGtYQOsB9MdFS/YusYjPmcXCuQFQnPCR0X2CVn11 rlXM/N9E07jDx5x+R6hc7FN2Rj32wfilZPSYFC8lZiKcu08eVeBIz72IBRgeWPN+ZYDY 7Vrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=ETz0n5Q5xPzIqlWzwxdQE7Imxlk36bnPhhsstTahZ0w=; b=Ud86v5CLI5bBEmjtTFQ35jWL35UeikF3GZJgCksGZ4gC0QARZsezJb54hwZjrlmcwd S1Vs1l+AabmLMMjuPFL3E2d/cLpS9hAqWzLbFMgzptkHEzhxzafBEDCvoVTEio3ennhA UqXzTWOTUjKKwUpDwJRz5o/McR1c1RhkOP4tJJEPfpaGJBCH1t3MTs/l2tcPn/k95AyM e2s+JBvaVzdPzfa0d7zcPE6BPyJNeZiU5IPEyVWN59A/jnIZ/Nr5qNYswKQdVJxoSlPm R+A+2EOT8bJyZa2vaRtg1ljNTfqXmF+LjfcETbA9EOf9WNIRIHbpb1PsyJ5EgEgRJPa/ 1uyQ== X-Gm-Message-State: AG10YOQg/oJOivU/tcFRNr9+D1Lxrl8mWBIvDXbdR6sOXN6++50dZ6HwVIWArFGdnysVQw== X-Received: by 10.98.33.135 with SMTP id o7mr60219342pfj.158.1455131450380; Wed, 10 Feb 2016 11:10:50 -0800 (PST) Received: from [192.168.1.4] (184-99-102-85.boid.qwest.net. [184.99.102.85]) by smtp.googlemail.com with ESMTPSA id wh9sm6948805pab.8.2016.02.10.11.10.49 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 11:10:49 -0800 (PST) To: apps-discuss@ietf.org References: <20160210181822.1369.qmail@ary.lan> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <56BB8B39.4080408@gmail.com> Date: Wed, 10 Feb 2016 12:10:49 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160210181822.1369.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020405060107090205080008" Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 19:10:52 -0000 This is a cryptographically signed message in MIME format. --------------ms020405060107090205080008 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/10/2016 11:18 AM, John Levine wrote: > PS: >=20 >> That ISP considers the 'preferred' service IMAP. >> You can connect with IMAP, but get no email if you expected the free >> service. >=20 > We definitely can't cure stupid. Different issue. They provide 2 services POP-free and IMAP-pay, and DNS/SRV has no way to do smart 'preferred'. (per user again) If they make IMAP preferred, then their free users get no email. If they make POP preferred, then their pay users get told to use POP and not the IMAP they pay for. RFC 6186: section 3.4, " ...When an MUA supports both IMAP and POP3, it SHOULD retrieve records for both services and then use the service with the lowest priority value. ..." and first paragraph on page 2 "... The priority field of the SRV record can also be used to indicate a preference for one message store access protocol over another. ... For users that upgrade, would have to manually update their MUA. I would hope that a configuration standard would allow for update data that does not tell them to use the wrong store/port. They choose the option that makes their per-users happy. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms020405060107090205080008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGwwggYwMIIFGKADAgECAgMNobowDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA0MDgwMTMzMzNaFw0xNjA0MDgxNzI3NDdaMEgxHzAd BgNVBAMMFmRvdWdsYXNyb3llckBnbWFpbC5jb20xJTAjBgkqhkiG9w0BCQEWFmRvdWdsYXNy b3llckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDV8lDK8TLv Lwjma4Lba4qcO6REc6G72ykoP585+CFo2otxTqfyg6m/mmynOkEupL7EM2JvsPOppaHeoNXq k2bia0pZevG6zLazQxGGlTMyle9qumru51INuyVVdPwlyJ6TuhvZVU7zuIinRWaIZgPmRQ+j mT8Abdpj0BZP+3cmDTUhkSEtsAHF11I0hQcyuI/LYWf1EBNujN3p9tzwxY5JKI0JHBDtiz4e N53nT4QQeKo2aBrCJXVIT0zxb5IzxPzvKPyi20HUrigtFpYlAT6/Kwopm3IuWRmQrEnTP8g4 JmacOtxGgnrPZvNskjbnwqtXBHlyVaoD3eL0j7Cfy/ShAgMBAAGjggLcMIIC2DAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFDn7j56P25uHeE2AeTdYArnzSW7hMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCEGA1UdEQQaMBiBFmRvdWdsYXNyb3llckBnbWFpbC5jb20wggFMBgNVHSAEggFDMIIB PzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBv c2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYD VR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADI7gAqJwpHOgbiMxyRp2K qmxAIpubAd9vgYPlrjsBmTvztSm2PiJFUF2uGqCGKkvTAVWVGMoV0QDfthU1GnFm3YgmZnTZ 7Ab/gqXTrl+ggUQXVjHcbzLqwyJ38tKaXHRgnvNwzHU9pBYuwO7ZEs+4pB6fcnyjgkbqigfu /FdxTPCmJwNaC2S1sYcesVz6iZEXGbAgmkuDW3alC9M2XCcT4jYrrCMsKhBrK5f+Hp/atvYH TSVJx5syilcplHOQ+Mg2fgCDFVVvDL1G+YEUUA0aLyD2uGLtPGF9E57kYDe/diEmprNz2wLZ R4F1PzCVPF55NaokjfEyrREj/uShZCyFMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYD VR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYB BAGBtTcBAgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6 rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWC tosmAOT4OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTut R08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eD F1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKE Q/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzx d2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulc NJ8tKmVtjYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapS n+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9 dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPt MIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMNobowDQYJ YIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDIxMDE5MTA0OVowLwYJKoZIhvcNAQkEMSIEINAOF8SlNBRTG6RuYln77kqsKd2A iC9lxHVCW6lnSqpuMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMNobowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2hujANBgkqhkiG9w0BAQEFAASCAQC2LoLmFO7u G/U00oo+HvuhGLTKnrrNdAYbz6McpsAucZYWapoOHukSvQzz3UxlSAlfYE7C7b956Whgdf0S 90SbksLhkWswys8vc/fPbPKVQdFwB+tCwEli0fGjpOUbS3nkJlbBBlmiO84QspmLmF99bQky OQfBG+AA6cQcXk+42/BneFMNS916E5VCkDoPm6wD1aHsiaoBwGShXAzYp/+yIFqTK5Ebvxa6 /hgybx41bhgoIlOxvpxwTPqYtVA1WV4UzAHXOecr3O434hbDDO6dwrB2ZH0BaWIAXefEfg+S qCb6ybQIxn7Cu5K+PCxhOC7yZ3fLKhKSUHoPibYrLj2lAAAAAAAA --------------ms020405060107090205080008-- From nobody Wed Feb 10 11:29:05 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D501B2ED0 for ; Wed, 10 Feb 2016 11:29:04 -0800 (PST) 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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 FSLvu1-Wup1l for ; Wed, 10 Feb 2016 11:29:03 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (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 3E2EF1B2EFA for ; Wed, 10 Feb 2016 11:29:03 -0800 (PST) Received: by mail-pa0-x22d.google.com with SMTP id ho8so16421771pac.2 for ; Wed, 10 Feb 2016 11:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=dLbvE3t4dS6LjgiWtyeRSEHJTHvtQIjYe7OWoK/J91w=; b=pXA8m2eNNeTZtwkoTPfQOym/W/qtfV4rsHeFKJwWYYsrrzKboJgz0ZtXNPvQC0Llpu VQhKdwE1EFwhUFKJOqe0C1vyNcOzSFcjCJsqTGLTx+tiWdc0Aw9aaAuuqkd77OrfhJGW kXiLa1k06dU5A4UoOzP7ll3EqbLRKx3zxYgHextFi2RnxvlYeUJqKS7HCbaJxDQe9Jhi dlQIENe7obJRKh9v+QSlP25mDW3l+PtoAdmcSCdsnHEwHOXOHAvE0yd9+ZUEIBiVTeti JIRnx52EnVy39peaGqQPeRWIg4q3wwMDuyzIIK55DwhdrAKwHt2KpHBBJVjzbOYkAXgG AXNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to:content-type; bh=dLbvE3t4dS6LjgiWtyeRSEHJTHvtQIjYe7OWoK/J91w=; b=ifrg34nQehcBVDoKro4aiHfn9ZfM2W4cteCjir8RqS4g/IGJVDpZPJXoe1CuW5VhMJ 1Qg+PtNAMgfNhBH67aWXTFXKJCVy/BXj3upyBZ1TDD5heQmHRpi8c+xcb2QzenQA4hWw Z+P6T2Rq6Wkw25uYwQ4x+wwRZzbBtIEVHTqK1tIkfIw8v0f/PmHN5+2ox85dalwMyhwi pbzXaHTNKxapDAzMDHwobbrjVo5Z27h8e8sKSl626qmp+KUd7143uFK0Pzw44uMVoeay tAtdacCXYfA7EEJy7+mXJtKAOvbEQ5L6gCb84McE4WjcvInWfj+9sF6m+7RED6XLwt/w tvDw== X-Gm-Message-State: AG10YOSxJPSJ0UwcPafyM4vM24JtmqQvv+jgcXIjJLLeXaTgVKiIF1aaty7NRRTIosGouw== X-Received: by 10.66.63.8 with SMTP id c8mr44669657pas.147.1455132542906; Wed, 10 Feb 2016 11:29:02 -0800 (PST) Received: from [192.168.1.4] (184-99-102-85.boid.qwest.net. [184.99.102.85]) by smtp.googlemail.com with ESMTPSA id x88sm6970701pfi.66.2016.02.10.11.29.02 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Feb 2016 11:29:02 -0800 (PST) To: apps-discuss@ietf.org References: <20160210181822.1369.qmail@ary.lan> From: Doug Royer Organization: http://SoftwareAndServices.NET Message-ID: <56BB8F7D.3010306@gmail.com> Date: Wed, 10 Feb 2016 12:29:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160210181822.1369.qmail@ary.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000601010407080407070208" Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 19:29:04 -0000 This is a cryptographically signed message in MIME format. --------------ms000601010407080407070208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/10/2016 11:18 AM, John Levine wrote: > I just tried it, port 587 and STARTTLS works fine. Perhaps your MUA > doesn't know that port 587 needs STARTTLS rather than doing the TLS at > connection time, a bug that should be easy to fix. Gmail does require > that you create a separate per-app password on their web site for > every device that logs into gmail, but automating that seems rather > beyond what we're looking at here. >=20 More oddities, IPv6 vs IPv4. =46rom Home ISP (defaults to IPv6 after 2 minute timeout, it tries IPv4 -= really ODD results as it still fails): telnet smtp.gmail.com 587 Trying 2607:f8b0:400e:c04::6d... (wait 2 minutes - time out) Trying 74.125.28.108... (wait 2 minutes - time out) Trying 74.125.28.109... (wait 2 minutes - time out) ... yet, if I telnet directly using IPv4: telnet -4 smtp.gmail.com 587 Trying 74.125.28.108... (note this is the same IPv4 as above) Connected to gmail-smtp-msa.l.google.com. Makes me think (and unrelated). Are their ISPs that only provide IPv4 vs IPv6 services? The SRV records point to a host name, not an IP address. WORKS from Texas: So I ssh'd into a Texas system that I manage and - everything works, both IPv4 and IPv6 on port 587. traceroute IPv4 fails for me to port 587. Must be my ISP oddities. I think my ISP is busted. --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 --------------ms000601010407080407070208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DGwwggYwMIIFGKADAgECAgMNobowDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQTAeFw0xNTA0MDgwMTMzMzNaFw0xNjA0MDgxNzI3NDdaMEgxHzAd BgNVBAMMFmRvdWdsYXNyb3llckBnbWFpbC5jb20xJTAjBgkqhkiG9w0BCQEWFmRvdWdsYXNy b3llckBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDV8lDK8TLv Lwjma4Lba4qcO6REc6G72ykoP585+CFo2otxTqfyg6m/mmynOkEupL7EM2JvsPOppaHeoNXq k2bia0pZevG6zLazQxGGlTMyle9qumru51INuyVVdPwlyJ6TuhvZVU7zuIinRWaIZgPmRQ+j mT8Abdpj0BZP+3cmDTUhkSEtsAHF11I0hQcyuI/LYWf1EBNujN3p9tzwxY5JKI0JHBDtiz4e N53nT4QQeKo2aBrCJXVIT0zxb5IzxPzvKPyi20HUrigtFpYlAT6/Kwopm3IuWRmQrEnTP8g4 JmacOtxGgnrPZvNskjbnwqtXBHlyVaoD3eL0j7Cfy/ShAgMBAAGjggLcMIIC2DAJBgNVHRME AjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0O BBYEFDn7j56P25uHeE2AeTdYArnzSW7hMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLU uFGCMCEGA1UdEQQaMBiBFmRvdWdsYXNyb3llckBnbWFpbC5jb20wggFMBgNVHSAEggFDMIIB PzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2Nv cmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBv c2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYD VR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADI7gAqJwpHOgbiMxyRp2K qmxAIpubAd9vgYPlrjsBmTvztSm2PiJFUF2uGqCGKkvTAVWVGMoV0QDfthU1GnFm3YgmZnTZ 7Ab/gqXTrl+ggUQXVjHcbzLqwyJ38tKaXHRgnvNwzHU9pBYuwO7ZEs+4pB6fcnyjgkbqigfu /FdxTPCmJwNaC2S1sYcesVz6iZEXGbAgmkuDW3alC9M2XCcT4jYrrCMsKhBrK5f+Hp/atvYH TSVJx5syilcplHOQ+Mg2fgCDFVVvDL1G+YEUUA0aLyD2uGLtPGF9E57kYDe/diEmprNz2wLZ R4F1PzCVPF55NaokjfEyrREj/uShZCyFMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MGYGCCsGAQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L2NhMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYD VR0fBFQwUjAnoCWgI4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAj hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYB BAGBtTcBAgEwZjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRl LnBkZjANBgkqhkiG9w0BAQUFAAOCAgEACoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6 rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1JxbLpAxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWC tosmAOT4OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH21BbyAYr7b5EfGRQJNtgWcvqSXwKHnTut R08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seHunmyG642S2+y/qHEdMuGIwpfz3eD F1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSwtzYlk4AUr6yxLlcwSjOfOmKE Q/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OEqOJUl7q+h+r6fpvU0Fzx d2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR0k9mST1iAZPNYulc NJ8tKmVtjYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxLBXI++aMUEapS n+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0NBrxJ3fN9 dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIxggPt MIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMNobowDQYJ YIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDIxMDE5MjkwMVowLwYJKoZIhvcNAQkEMSIEIEEcv7+bUwaWLTTglWM6jJfQ6NjW z0QND+XZpGW+79nFMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1l ZGlhdGUgQ2xpZW50IENBAgMNobowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2hujANBgkqhkiG9w0BAQEFAASCAQB7QGvCkU1i /xWmCzBGdRiP9W8zwsjeBssxf8y5POBhaAo7ge2oMhl/hwE2gLHIQ2SEHWN8OdL7b5M4KIf2 2dXhNwSOPmQ2FgLxlGOOWlY2fzB7hH21eEoq1ru8POPWUVx/wf+7Dorh2lFtX3HpdDMb2Zw+ gYL+U5q7Ge1InlDvW0cwSMtO3LeXIxw3c1yCEpIZHeayC/g/EPrKfysmEhj3vgBeBTEJvIS/ khlCyrnUkph2ZJG3xMHmbgQHybGYmcRd2C5w13cJUg07F1XPpBqF22hsTWD2r2+qlBC3EFNd l2A1abSR8Iiqzn1GaYdmsLceGaJICdFjv+F0tJqJbH/bAAAAAAAA --------------ms000601010407080407070208-- From nobody Wed Feb 10 12:17:28 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4561E1B2F66 for ; Wed, 10 Feb 2016 12:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, KHOP_DYNAMIC=0.001, SPF_PASS=-0.001] autolearn=ham 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 IMeOPYRU9GDQ for ; Wed, 10 Feb 2016 12:17:25 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2081B2F64 for ; Wed, 10 Feb 2016 12:17:25 -0800 (PST) Received: (qmail 23350 invoked from network); 10 Feb 2016 20:17:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Feb 2016 20:17:23 -0000 Date: 10 Feb 2016 20:17:01 -0000 Message-ID: <20160210201701.1725.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5e3d7843-b3c8-4baa-b2da-2683fc36df84@gulbrandsen.priv.no> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 20:17:27 -0000 >The EAI situation is better than you probably think, mostly because the >unicode committee does very good work and the rest of the world is lucky >that it does. Oh, I agree. I was thinking of stuff like accented vowels which in French are usually considered close enough to the unaccented versions that you'd consider accented and unaccented versions to be the same name, as opposed to Scandinavian languages where the various forms of "o" are entirely different letters. There's also traditional and simplified Chinese characters which are equivalent except when they aren't. This has been an enormous can of worms for domain names, trying to figure out when names are close enough to be more or less equivalent and if so what to do about it. With EAI every MTA operator can do what makes sense in their situation but I'm guessing there will be as little consistency there as there is about what you do with dots and plus signs in ASCII local parts. R's, John From nobody Wed Feb 10 13:21:30 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B66C1B3001 for ; Wed, 10 Feb 2016 13:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham 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 dGghmjt6jZML for ; Wed, 10 Feb 2016 13:21:26 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 971721B2FF8 for ; Wed, 10 Feb 2016 13:21:26 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id x65so18050934pfb.1 for ; Wed, 10 Feb 2016 13:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:content-type; bh=3w1yn71E8MA7D1kjlrfFyaNDcHqlZT8aiAavxIEXI6U=; b=HLARiLLNWn3vKwM1MFEpai+8jkcgwh8lQXZHzT+I6Vy0r2JqOFVUvqizcwgAHmLZQC iVKi//5NCUP/bLbmAi+XUE1pL8dNW/Nk+jsAlUGWM3SRcFXcfXDLDqyHSWZThc4KI8+9 y7Wn3+uBM9jlwQXm6hD2ko2bOqYFuI6AhkAYq0xh4P+7kJ3JpvKX1HwtJF6YORMfV1W1 Dw7v5w14l9qQbhnWAq3p4jOnT0G0bdaOQq2EBL7MU+2oN+BbDRaKVaYSxm1Yj5AKIY/4 hLO/dFRc8+vFr28A/DIFbSVzEtIHVeZNMoqNrUigk7Iujfyv4HZtylXtDyjeOoOAgpGv ylaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:message-id:in-reply-to :references:subject:mime-version:content-type; bh=3w1yn71E8MA7D1kjlrfFyaNDcHqlZT8aiAavxIEXI6U=; b=e2cJYMw7iMdPnrjzhrHEV2vw7L+MdcIOcbNNABLeeiv/1KRvs1EhTLx/s5wKaRt7LT 8ZwgEKVquUKzJEDyVAuxXuOqY44oW2+VVBOhgZ6AI0NU4C+ZG78wn3hlMdb3YK1oyDar 1z88P9TxPqdUOirQHeBfvMXNmYN1Kt4hnQ+FLp9PvSCJ2IP5Jz7FLMP3N1K6hvvUKl9D 7zF762+nItB56wIiy+CuOW5INl76b9CdU72FBW+M/ir23K08xIuuts1O6ikC7d/XtvGh M5x5LyeL19ybqPTxP5bBiGfMsW1w7HH7OZ0f4TZNjLKfThwiywujsqbuGEgVgBWeqYrZ MH7A== X-Gm-Message-State: AG10YOT67rLiR+BRuyx8FfYdjLjMnBjT6wl/Wks6MsJ44x/KkVL5Dmjr6kN3g32e1ySI+A== X-Received: by 10.98.40.200 with SMTP id o191mr34460615pfo.83.1455139286312; Wed, 10 Feb 2016 13:21:26 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id b2sm7286007pfd.24.2016.02.10.13.21.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2016 13:21:22 -0800 (PST) Sender: Phillip Hallam-Baker Date: Wed, 10 Feb 2016 21:21:21 +0000 (UTC) From: Phillip Hallam-Baker To: , Doug Royer Message-ID: <994C5976EA09B556.C69D461E-0A18-429D-ACAC-C27ECF124263@mail.outlook.com> In-Reply-To: <56BA5C72.7050708@gmail.com> References: <14ED6A18B69DDBCAE548D2D3@caldav.corp.apple.com> <56BA5C72.7050708@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7313_1813955423.1455139281663" X-Mailer: Outlook for iOS and Android Archived-At: Subject: Re: [apps-discuss] Mail client configuration via WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 21:21:29 -0000 ------=_Part_7313_1813955423.1455139281663 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, so being offline most of today and about to get on the plane. I see two= separate requirements 1) Email service discovery2) Email account config The first I think should be dealt with using the SRV plus prefixed TXT reco= rd pattern that is already established for the purpose in IETF. The issue here is that we need more than just discovery of the IP address o= f a host that can serve us. The existing spec is fine for setting the inbou= nd and outbound hosts. But it doesn't have the TLS information I would want= . [And no, I do not want to use a DANE hack for reasons I have set out at l= ength in the past.] One of the security holes in the current email config is that we have a lot= of SMTP auto protocols, only some of which are widely supported only some = of which have code points registered and all of which are vulnerable to dow= ngrade attacks. It is an ugly mess that I don't plan to propose a fix for r= ight now. But what I do want to do is to define a clean interface to the ex= isting mess. Email account config is more than just service discovery. I want to be able= to configure keys for Endy-mail which at minimum includes S/MIME and OpenP= GP and possibly a future S/PGP. So when Alice is using her email client fro= m her laptop and her phone and her tablet, she needs all of them to be auto= matically provisioned with the necessary keys. That is what I mean by account configuration and that is what the Mathemati= cal Mesh was originally designed to address. Late in the implementation, I = realized that I could also just configure the email account network setting= s. But that is supplemental to, not a replacement for SRV+TXT config. The reason for this is that the Mesh profile manager has to find configurat= ion info from somewhere. Right now it will pull them out of a configured em= ail app. But I would also like to be able for the profile manager to pull t= hat info directly.=C2=A0 Looking at this, I don't see WebFinger as being the answer to either part. = We have an IETF architecture for Service discovery, it uses SRV + TXT and t= here is a quite comprehensive documentation of that in RFCs. I did try to w= ork out if I could use WebFinger for the same uses as I support in the Mesh= and I don't think it helps.=C2=A0 So very committed to helping solve this. I don't think WebFinger is the app= roach to use. Sent from Outlook Mobile On Tue, Feb 9, 2016 at 1:39 PM -0800, "Doug Royer" = wrote: Maybe the there are two separate issues. - How to containerize and standardize passing of configuration information from service provider to consumer. Maybe a MIME type with sub-registration of protocol (email, calendar, VOIP, ...), and mandating it be sent encrypted. - How to transport that information across whatever transport is available. SRV record to MIME blob URL, sent in email, HTTP/FTP download, ... --=20 Doug Royer - (http://DougRoyer.US) DouglasRoyer@gmail.com 714-989-6135 ------=_Part_7313_1813955423.1455139281663 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
OK, so being offline most of today and about = to get on the plane. I see two separate requirements

1) Email service discovery
2) Email account config
<= br>
The first I think should be dealt with using the SRV plus pre= fixed TXT record pattern that is already established for the purpose in IET= F.

The issue here is that we need more than just d= iscovery of the IP address of a host that can serve us. The existing spec i= s fine for setting the inbound and outbound hosts. But it doesn't have the = TLS information I would want. [And no, I do not want to use a DANE hack for= reasons I have set out at length in the past.]

On= e of the security holes in the current email config is that we have a lot o= f SMTP auto protocols, only some of which are widely supported only some of= which have code points registered and all of which are vulnerable to downg= rade attacks. It is an ugly mess that I don't plan to propose a fix for rig= ht now. But what I do want to do is to define a clean interface to the exis= ting mess.


Email account config is = more than just service discovery. I want to be able to configure keys for E= ndy-mail which at minimum includes S/MIME and OpenPGP and possibly a future= S/PGP. So when Alice is using her email client from her laptop and her pho= ne and her tablet, she needs all of them to be automatically provisioned wi= th the necessary keys.

That is what I mean by acco= unt configuration and that is what the Mathematical Mesh was originally des= igned to address. Late in the implementation, I realized that I could also = just configure the email account network settings. But that is supplemental= to, not a replacement for SRV+TXT config.

The rea= son for this is that the Mesh profile manager has to find configuration inf= o from somewhere. Right now it will pull them out of a configured email app= . But I would also like to be able for the profile manager to pull that inf= o directly. 


Looking at this, = I don't see WebFinger as being the answer to either part. We have an IETF a= rchitecture for Service discovery, it uses SRV + TXT and there is a quite c= omprehensive documentation of that in RFCs. I did try to work out if I coul= d use WebFinger for the same uses as I support in the Mesh and I don't thin= k it helps. 

So very committed to helping sol= ve this. I don't think WebFinger is the approach to use.


=
Sent from Outlook Mobile




On Tue, Feb 9, 2016 at 1:39 PM -0800, "Doug Roye= r" <douglasroyer@gmail.com> wrote:

Maybe the there are two separate issues.

 - How to containerize and standardize passing of configuration
information from service provider to consumer. Maybe a MIME type with
sub-registration of protocol (email, calendar, VOIP, ...), and mandating
it be sent encrypted.

 - How to transport that information across whatever transport is
available. SRV record to MIME blob URL, sent in email, HTTP/FTP
download, ...




--=20

Doug Royer - (http://DougRoyer.US)
DouglasRoyer@gmail.com
714-989-6135
------=_Part_7313_1813955423.1455139281663-- From nobody Wed Feb 10 13:46:42 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50791B305B for ; Wed, 10 Feb 2016 13:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 qV9_hOZFr2z1 for ; Wed, 10 Feb 2016 13:46:39 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 F306F1B3059 for ; Wed, 10 Feb 2016 13:46:38 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id q63so18343052pfb.0 for ; Wed, 10 Feb 2016 13:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:message-id:in-reply-to:references:subject :mime-version:content-type; bh=xFzDkx3lXlwYg2NHE60JhhdIR6B3BKjrRDLQyqx8t4E=; b=yeDNkLHF/gitqGCOh/Wlmkmf/Dfs/rnOVX6Ul4KZf9e1Pa2Nc8rhjBh7oG+Bf0MmkS Vh4xAnfrJQ07OkVbgSuUNvLFHFTRIuuIIP4fT+dLr9UGC+slnBrWvi1rqKZ1F6ozO4Pt ccLVqSLL2l2tgdXpkPVbTIk6SUQpQOyLGftStPmVOkstV2ZMGpjwM9K6uKzDMwLeesUm EOV1/n4CiUCNEhjCl16WYeJxFZj68J3zsjErbsbA5Fi+2wQW8q1sblu5uFkp3vY5GcGg oiyjD2teqTXTCDw4MvjBP0EQg6nMVdmEPhXGQ6+E9Aswh9mWYWDjNUf5LXFJmyYoVlA8 u7aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:message-id:in-reply-to :references:subject:mime-version:content-type; bh=xFzDkx3lXlwYg2NHE60JhhdIR6B3BKjrRDLQyqx8t4E=; b=RFIPJgo99t02VDUV2Bs3I0KJlDl6CzNZ7KVS6JrSsZynyLkA3Bfs9hqTNnMILqTuf9 HDLuvWw1DwbSI99QHmOioqa48IcwLSRFcfrdEJ7K8mxGJVQC17IRhTz1yHs4n0H6D+Ix +WcCAop9pVCIV27KLvdYoIcsWwF90vKOLutUG+Zzqit2d1J6BPdUMynh0YMwbnbf7puH QFMrHOsmQhC1Z063DCrPLniUARh419CPrUyIO1LskuJ8azf8cYqaWCoxyQm3AvDUKA4k Nvhue7gW64Pmm77YxcllNzf6APBiRUEr0zWWhdcOynbTY1BuwWrO6KsYiOcF8fN8WnaH yn8g== X-Gm-Message-State: AG10YOShKUSZBm5CsWbee2RJdKHKEHKFe4ebrB+7tXrOKGQS/UVRj2p0/q01AzjI1F+ohQ== X-Received: by 10.98.72.202 with SMTP id q71mr61546842pfi.69.1455140798703; Wed, 10 Feb 2016 13:46:38 -0800 (PST) Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id r145sm7327552pfr.59.2016.02.10.13.46.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Feb 2016 13:46:35 -0800 (PST) Sender: Phillip Hallam-Baker Date: Wed, 10 Feb 2016 21:46:34 +0000 (UTC) From: Phillip Hallam-Baker To: , John Levine Message-ID: <994C5976EA09B556.2633D77B-A5B3-40D2-841E-A004F2B11220@mail.outlook.com> In-Reply-To: <20160210201701.1725.qmail@ary.lan> References: <5e3d7843-b3c8-4baa-b2da-2683fc36df84@gulbrandsen.priv.no> <20160210201701.1725.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7473_965378063.1455140794463" X-Mailer: Outlook for iOS and Android Archived-At: Subject: Re: [apps-discuss] Mail client configuration via something, maybe WebFinger X-BeenThere: apps-discuss@ietf.org 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: Wed, 10 Feb 2016 21:46:41 -0000 ------=_Part_7473_965378063.1455140794463 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The complexity of the Netscape protocol from 1997 is only partly due to the= complexity of the problem.=C2=A0 The much bigger problem is the architecture. An email account config is ult= imately going to end up in some sort of file/registry setting. And so it is= going to be a collection of structured data.=C2=A0 The way we go about that problem today is to write an XML schema or a descr= iption of a JSON structure (which is of course a schema but we don't call i= t that as it frightens the horses). Then we poke or pull data blobs that co= ntain data structures according to the schema. All the complexity of the pr= oblem goes into the schema design. And so do any extensions to meet future = needs, proprietary purposes, etc. etc. The Netscape protocol isn't written that way. The complexity that these day= s we contain in the schema has escaped into the network protocol which is l= oosely speaking a mechanism for editing the data structure by sending diffs= for each branch. So, I think it is a distraction and not very helpful. The Mesh follows the schema approach but with layers of cryptography to pro= tect confidentiality and integrity. There may be common network config elem= ents that should be shared by email and xmpp config for example. In fact I = am sure there are or we are doing something wrong. =20 ------=_Part_7473_965378063.1455140794463 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The complexity of the Ne= tscape protocol from 1997 is only partly due to the complexity of the probl= em. 

The much bigger problem is the architect= ure. An email account config is ultimately going to end up in some sort of = file/registry setting. And so it is going to be a collection of structured = data. 

The way we go about that problem today= is to write an XML schema or a description of a JSON structure (which is o= f course a schema but we don't call it that as it frightens the horses). Th= en we poke or pull data blobs that contain data structures according to the= schema. All the complexity of the problem goes into the schema design. And= so do any extensions to meet future needs, proprietary purposes, etc. etc.=

The Netscape protocol isn't written that way. The= complexity that these days we contain in the schema has escaped into the n= etwork protocol which is loosely speaking a mechanism for editing the data = structure by sending diffs for each branch.

So, I = think it is a distraction and not very helpful.

The Mesh follows the schema approach but with layers of crypto= graphy to protect confidentiality and integrity. There may be common networ= k config elements that should be shared by email and xmpp config for exampl= e. In fact I am sure there are or we are doing something wrong.
=20 ------=_Part_7473_965378063.1455140794463-- From nobody Sat Feb 13 17:03:00 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8968B1B35BA for ; Sat, 13 Feb 2016 17:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.894 X-Spam-Level: ** X-Spam-Status: No, score=2.894 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001] autolearn=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 S8z0CUqQoMKX for ; Sat, 13 Feb 2016 17:02:57 -0800 (PST) Received: from sogo.guto.nl (guto.nl [178.21.117.49]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044AC1B35B9 for ; Sat, 13 Feb 2016 17:02:56 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by sogo.guto.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aUl5R-0006i5-5b for apps-discuss@ietf.org; Sun, 14 Feb 2016 02:02:53 +0100 From: Stephan Bosch X-Enigmail-Draft-Status: N1110 To: apps-discuss@ietf.org Message-ID: <56BFD23A.9010601@rename-it.nl> Date: Sun, 14 Feb 2016 02:02:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 130.89.162.218 X-SA-Exim-Mail-From: stephan@rename-it.nl X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on sogo.guto.nl) Archived-At: Subject: [apps-discuss] Question about mailto URI X-BeenThere: apps-discuss@ietf.org 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: Sun, 14 Feb 2016 01:02:58 -0000 Hi, I have a question about the mailto URI specified in RFC 6068. The followi= ng syntax is specified for header fields: hfields =3D "?" hfield *( "&" hfield ) hfield =3D hfname "=3D" hfvalue hfname =3D *qchar hfvalue =3D *qchar This syntax allows an empty header field name, whereas RFC 5322 specifies= the following: optional-field =3D field-name ":" unstructured CRLF field-name =3D 1*ftext ftext =3D %d33-57 / %d59-126=20 This doesn't allow empty header field names, which makes sense to me. Is there a reason to allow an empty header field name for the mailto URI,= or am I just looking at something that warrants an erratum for the RFC? Regards, Stephan. =20 From nobody Fri Feb 19 10:42:12 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5891A1F1D for ; Fri, 19 Feb 2016 10:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 wiphyEKPulTf for ; Fri, 19 Feb 2016 10:42:09 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 7D50A1A1B96 for ; Fri, 19 Feb 2016 10:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1455907328; d=isode.com; s=selector; i=@isode.com; bh=MhA/vVIE6qvVx+ThfJWnb0VwmxwzxLgo3jTNdWF9+OM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=hcO7vGJlbepSGgsGXAP4Xo+ksyhqFZlkryjh9m5i0c/7cgE9q3INT15vA4RYnXlDGVo6US 2W2mstgsF00m5zZDMF4YMoirYgGl85zHdkR8bE7DZNBBAxOx0OgIBJzpfU+vmxN0WuA+8a 7KncsYlvCgk/Ac4VWT5E4GwcyZIdzh0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 19 Feb 2016 18:42:08 +0000 To: Stephan Bosch , apps-discuss@ietf.org References: <56BFD23A.9010601@rename-it.nl> From: Alexey Melnikov Message-ID: <56C761EC.1000304@isode.com> Date: Fri, 19 Feb 2016 18:41:48 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <56BFD23A.9010601@rename-it.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] Question about mailto URI X-BeenThere: apps-discuss@ietf.org 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: Fri, 19 Feb 2016 18:42:11 -0000 Hi Stephan, On 14/02/2016 01:02, Stephan Bosch wrote: > Hi, > > I have a question about the mailto URI specified in RFC 6068. The following syntax is specified for header fields: > > hfields = "?" hfield *( "&" hfield ) > hfield = hfname "=" hfvalue > hfname = *qchar > hfvalue = *qchar > > This syntax allows an empty header field name, whereas RFC 5322 specifies the following: > > optional-field = field-name ":" unstructured CRLF > field-name = 1*ftext > ftext = %d33-57 / %d59-126 > > This doesn't allow empty header field names, which makes sense to me. > > Is there a reason to allow an empty header field name for the mailto URI, or am I just looking at something that warrants an erratum for the RFC? I don't know of any reason to allow for empty header field names. Although at this point implementations should just ignore empty fields. Best Regards, Alexey From nobody Fri Feb 19 20:05:18 2016 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82941B3947 for ; Fri, 19 Feb 2016 20:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 n3OUj54IMIQs for ; Fri, 19 Feb 2016 20:05:13 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0131.outbound.protection.outlook.com [104.47.126.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114D21B3943 for ; Fri, 19 Feb 2016 20:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=770cNpBujnPqQRtAy/p0YRmw0qvETuv5ZqedrEnZa9Q=; b=t7YVGVfBAT8Oed2/EvrdUBSsc+pUkUP5sPOv/HFsDtEO55xsTuYRSif371unhrMpzFKKC1/fmnIEYf0ilRxVRjl3qBMtF9piBIfH5YzoeCBq22GaC2bONiTv0EEqE6P1xAqJHp8ZMVM0Pujvk5jj1EobdejEoBWo5uuhkekain4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0136.jpnprd01.prod.outlook.com (10.161.229.13) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 04:05:08 +0000 To: Alexey Melnikov , Stephan Bosch , References: <56BFD23A.9010601@rename-it.nl> <56C761EC.1000304@isode.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56C7E5F1.7030905@it.aoyama.ac.jp> Date: Sat, 20 Feb 2016 13:05:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56C761EC.1000304@isode.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TY1PR01CA0050.jpnprd01.prod.outlook.com (25.164.162.160) To OS1PR01MB0136.jpnprd01.prod.outlook.com (25.161.229.13) X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0136; 2:+86pG+UAN3MBOZHzrdOskiMVdxvKA2cJV89mCmBOx6KJM0NqsCkQU6hzNBX3ChNPPQEd/GPWzcy2w0P9r9XGFwNt1x1xQTSq9wuOd69lmVfCQUx38yP4Xhz6GvxS03G7GNihySfVL1Y8d7C8RW6Yyw==; 3:DsnGxqvoRxZyYx0EsTCEoiJjAK+lzTNuR4OOBP9OQY+y/DReU2vbuH2pgWYt8e2yxj2axGTG4BRD3p5Ma0R566C7h/UVagZfuCouoR7Nfk7ms4txwgYb7/G2/rQ+7/9t; 25:+Hnd2tuJLdfcsZjCbSExavxUtH7Qo2Ds13BplTVrO3hz4arJ2LgCDDcEEDwgIB1lSzwksOPvgg7Hm2dQRGhb8thcY2VYktwVp9p8ENVNf1x7yDCaklLijpYcG4CjKAzBH7jWfg99kITrxusD5KLjKTzy+4IEv1frSzkfBHanPo0Z9Pp9Xl3XT6NJ0guBMkcBovAS6LEQq6e7NawJ1UjBw6rkarpN5g7YKFBbnUavd1Zk72eaX7o49SeK61n2TNFXFq0w1cnaQcKWjmG/2dDr7GVeNi9oIo9S1Ee++kWv7Kf2EgXvvZ7FI+MJSa1RgkO0mpjIXu3qVuFAUy6pc/1GK7NqMuL3WetihoZK+wasyOg= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0136; X-MS-Office365-Filtering-Correlation-Id: a6264db3-f768-407d-0d1f-08d339ab05ee X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:OS1PR01MB0136; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0136; X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0136; 4:YU+6GIwVG+AnYOCdSMa09V9Hcv3Vfsj2rjH7GsP+nxk+c+BaARzw64PBx3P5hyhRiJLl2yrP1n8SzXy1Kt5htTu81zlDdLqvTGAXVc6HyjQSrGvcCifxUOgQUpLc1Ra6QPrCocifnAYY8ykRLf2okwyyftUUUwPqNUkxOkS+JAkAHdNMNWQqKzH9fL+4h5VJ3TgPMxiKFcx1ukQOxIZFqUHqo6b8H0ZWzeH9NRC+bjJh9KoJ/om/Y/VWDLJ91ZsYrg33Z8drJrfLzVeFkwVCpEmJJ5ytj/E6EW6HPNIVfu+tvmWJMlwonZagvRdAIsrIVsMvXE3ulAgcjGonum95Wt72zzbLE6u8UobPziGBXkM= X-Forefront-PRVS: 0858FF8026 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(479174004)(24454002)(5001770100001)(19580395003)(5004730100002)(4001350100001)(86362001)(189998001)(5008740100001)(5001960100002)(74482002)(83506001)(87976001)(42186005)(107886002)(80316001)(230700001)(87266999)(2906002)(40100003)(3846002)(65956001)(23676002)(92566002)(122386002)(2950100001)(47776003)(77096005)(76176999)(6116002)(1096002)(33656002)(66066001)(586003)(65816999)(50986999)(54356999)(15975445007)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0136; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzFQUjAxTUIwMTM2OzIzOmpGOENzek93UTZlZ3llWkQzVy93ckw3N2Fs?= =?utf-8?B?akhZV3BYdXExTFNsTXErS0JiaUROaldlbDZsbk13ZE5pNDhPZU5JYnlLRlRK?= =?utf-8?B?dkxqOSs1Q0tLS2ZMcU1LeEcvYThlcXJTWDVhL3VacUdzN1d3eDZWbkRFUUN1?= =?utf-8?B?dEZ6SHJ1RGxYU2lMT2JlajZJUWpxUEx1MFZuZFYvTko3d3dzUVo1dzVsNklG?= =?utf-8?B?MnJIemx5Vk9jM09EYVBDVDJHOGp3ZUxmM040N2kyK1ZYMHFmMy9ia2ZjSnpy?= =?utf-8?B?MzZGMG0vd29OTEVseHo3aE15T0ZvOVZKV242bFQ1VjJlTjVzcmhMMmRLTG9v?= =?utf-8?B?RG9FM2tzbmlpdlQrc0RJYlFGbkxCV3BZU1ROSTRDYm5xc3F0QXdiVDE4Z00v?= =?utf-8?B?ZGtGSEduTHNQOGtHQ2kzUENVQ0RYQ2Q3VXhXYlVyeHZNaFdCcklBS3VDcTFm?= =?utf-8?B?Skxmc3YycXZCemRSbXozb3ZlWG1yRldhMW5TRUlFd25UenJRS3pJYjJLUXNR?= =?utf-8?B?R1pyZ3ZCcGVIRW9aaFJycUk4RWowZVJBSEN4ZHhLQlkvVkJtbXo4UEtwVHRQ?= =?utf-8?B?dHpYZmllSFRjajRsT3NWckE1SlVIakZsRkxXdzhtbEJZYk01RC9MMmFoVnpJ?= =?utf-8?B?TkliZFIvbyt6UkhvNWNPanpxREtFVlQ5MExFWTROZWc1RlBkUHhJL010cG9V?= =?utf-8?B?ai9BMko2TkplMEkrT2JnTnMxSmJJc3Jib2tFbFBhU3ByZGZNSE11WnVPWE1N?= =?utf-8?B?NFhYRVhJR3g4Z01HQm1BaHR2L0lSTDFWemtONFNNVWlCOS9nVVZha00xR0h5?= =?utf-8?B?Q3FEdzNhMVlCYm5jM2EzdHZUK0ZKZnVwVlhPV0tKZnZib001a3VlZDBnUmkx?= =?utf-8?B?Y3VFTlNBWEpDa3d4Mk9LVHhXMnA0TUxUZFZtQno1V2poa2ppSEVzeENxNlZK?= =?utf-8?B?Z0NuWmh0Wk1CNFhqVmpVSnc0ZVJMTXIwd0pFUlNueWpPRS9UQW9PdUozdklY?= =?utf-8?B?UW53ek44Ri9yc1g2NERibFJMUW9lY3h2QVp3NXBTNGZyUDBNd2ZWTm0vQUU5?= =?utf-8?B?VzQ2b3B3QnRqaGo3dlppV2ZCNmdycEtidXZqWG51bE5ZbDNjTFVkV0d1eEFH?= =?utf-8?B?djZVRXpUaDlDMVp5a0F4eUZOM1k0Y2tBSy9yaHhsblhMV005YTJPcFZDZHNx?= =?utf-8?B?a0ttYUgxaDB2TDNDd0dTdytMYVNHT0UwZWVVb1RxRmdIY2FMdVVuNlYyWlJH?= =?utf-8?B?VVBvQThRSks2ZGIzQnFFVHdzelhrY01rU1NTSTdBUGNKT1h5NnpveURmeHpr?= =?utf-8?B?akIyd3ZUaWd1YUFnRzJJV0ppYjhPQXNjc1docjRFMnNqalVMdTNzYU5WZnp6?= =?utf-8?B?bXZMYmJDTlBoalNDNGM3U3JmYWJ6TVp5WUFvbUFBMzN1QWhETk5FdzZtdWNG?= =?utf-8?B?c2x5MlpWeHgyTno3bm92RzRrTk9nb3hQSEN0dS9TYzZOQm04MFNrSFF6bG02?= =?utf-8?Q?fp71+JNFearz44XsYN9AEXVGroeLEX8Lzm4reWuRVcSdzB?= X-Microsoft-Exchange-Diagnostics: 1; OS1PR01MB0136; 5:Q77Slc5Gn1X7B2Jgt6qydxrO1bKHVHi0o62N2ghaskHM23N+dn7XWVWXOT0ljorOJb58P3E2jTELcQg7CTLgPWmrJOuAKqVFFo0f0gmWzq281T5Tt6iPStUGBZs0UwwUsKVv/JIh6uoMR1zu2rw1Xw==; 24:mVXS8dqoL8l3bpu9zYoeNO2haBdVTNkgD6gIxX8rwS6s4K+4ueoHb08Or0T+Up7WQ+A3Nmq/27h5IdA6gO4z4mN85ZXlFxNYG2CqvXnHm/c= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2016 04:05:08.9956 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0136 Archived-At: Subject: Re: [apps-discuss] Question about mailto URI X-BeenThere: apps-discuss@ietf.org 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: Sat, 20 Feb 2016 04:05:17 -0000 Hello Stephan, Sorry for the delay of my answer. On 2016/02/20 03:41, Alexey Melnikov wrote: > Hi Stephan, > > On 14/02/2016 01:02, Stephan Bosch wrote: >> Hi, >> >> I have a question about the mailto URI specified in RFC 6068. The >> following syntax is specified for header fields: >> >> hfields = "?" hfield *( "&" hfield ) >> hfield = hfname "=" hfvalue >> hfname = *qchar >> hfvalue = *qchar >> >> This syntax allows an empty header field name, I have been able to trace this back to https://tools.ietf.org/html/rfc2368, where the rules in question are headers = "?" header *( "&" header ) header = hname "=" hvalue hname = *urlc hvalue = *urlc >> whereas RFC 5322 >> specifies the following: >> >> optional-field = field-name ":" unstructured CRLF >> field-name = 1*ftext >> ftext = %d33-57 / %d59-126 >> >> This doesn't allow empty header field names, which makes sense to me. It makes a lot of sense to me, too. >> Is there a reason to allow an empty header field name for the mailto >> URI, or am I just looking at something that warrants an erratum for >> the RFC? > I don't know of any reason to allow for empty header field names. > Although at this point implementations should just ignore empty fields. I'm thinking about producing an update to RFC 6068 once it is possible to use non-ASCII characters in RFCs, which should be "soon". At that point, we should re-check this issue. Looking at RFC 6068, there's already quite some text at the end of Section 3 and in Section 4 that makes it clear that MUAs and the like have to be careful to not just put all the header fields into an email message as-is. This should cover empty header field names, too, but it might be a good idea to point this out more specifically in an update. Regards, Martin.