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

"John Levine" <johnl@taugh.com> Wed, 10 February 2016 18:18 UTC

Return-Path: <johnl@taugh.com>
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 <apps-discuss@ietfa.amsl.com>; 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 <apps-discuss@ietfa.amsl.com>; 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 <apps-discuss@ietf.org>; 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: Wed, 10 Feb 2016 18:18:22 -0000
Message-ID: <20160210181822.1369.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
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: <http://mailarchive.ietf.org/arch/msg/apps-discuss/cNJKRXu4aPDX051oqUdKZnIZWQQ>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=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.