Re: [Jmap] Address Validation (was Re: Submission)
"Chris Newman" <chris.newman@oracle.com> Thu, 27 April 2017 01:48 UTC
Return-Path: <chris.newman@oracle.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3D126D05 for <jmap@ietfa.amsl.com>; Wed, 26 Apr 2017 18:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jXXzpZ0rAp1 for <jmap@ietfa.amsl.com>; Wed, 26 Apr 2017 18:48:24 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 B13E812441E for <jmap@ietf.org>; Wed, 26 Apr 2017 18:48:24 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3R1mLqQ024818 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Apr 2017 01:48:22 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v3R1mLuO026120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Apr 2017 01:48:21 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v3R1mLo1022764; Thu, 27 Apr 2017 01:48:21 GMT
Received: from [10.145.239.185] (/10.145.239.185) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Apr 2017 18:48:20 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Brandon Long <blong@google.com>
Cc: Adrien de Croy <adrien@qbik.com>, "jmap@ietf.org" <jmap@ietf.org>
Date: Wed, 26 Apr 2017 18:48:18 -0700
Message-ID: <3D9D8003-F757-432D-BE9E-C75665DAF990@oracle.com>
In-Reply-To: <CABa8R6v0XJrgw7m1CfWxiBgpADiMgyZbAPSQXyY_OkaNNfnurg@mail.gmail.com>
References: <emd3533c0d-dc08-45c3-801c-07972858ad64@bodybag> <20170421001702.24991.qmail@ary.lan> <em7b8ab713-d303-46e1-b0de-eec9f43f18e0@bodybag> <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.com> <CABa8R6v0XJrgw7m1CfWxiBgpADiMgyZbAPSQXyY_OkaNNfnurg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.6r5347)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/vnBpUmLR9qnwQWi32IDCNmzQ180>
Subject: Re: [Jmap] Address Validation (was Re: Submission)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Apr 2017 01:48:26 -0000
On 26 Apr 2017, at 15:08, Brandon Long wrote: > This is the second time you've asked for the SMTP status codes and > enhanced > status codes, I'm very unclear what the utility of those would be, and > why > we would need to expose them to JMAP. Good protocol design requires both machine readable and human readable status information, and IETF experience suggests that status codes need to be extensible in a way that is lighter-weight than publishing an RFC (a first-come-first-served or expert review IANA registry seems reasonable to me). As JMAP submission will need status codes for the different things that can go right or wrong at submission time, we can either use the already defined status codes and registry, or we can create a new set of status codes. If we create a JMAP submission status codes registry, the registry should include a column listing SMTP Submission status codes that map to the JMAP code. Using the existing codes is less work in the spec but I'm fine with either approach. > We very rarely care about the difference between the codes beyond > ok/temp/perm, I won't argue this point. But I'll observe that rarely is not the same as never. > and find that folks are fairly inconsistent about the > enhanced codes, or that the enhanced codes don't actually translate > into > useful information from a user perspective. At best they provide a > fallback for what is otherwise a long list of regexes for the error > messages themselves. That argument may support creation of a new JMAP submission status codes registry. > It also ties the implementation to SMTP when SMTP may not even be > used, ie > local delivery on a service using JMAP may never use SMTP. I don't see how status codes ties JMAP to SMTP. On the flip side, the JMAP charter already requires us to tie JMAP to Submission (RFC 6409). That's a good thing since all non-local messages will travel over SMTP for a very long time. > It also ties it > to SMTP when we know that we can't implement it with SMTP (due to > address > scraping concerns). Submission (RFC 6409, port 587/465) is not the same as SMTP (RFC 5321 port 25). I'm not aware of any address scraping concerns in authenticated submission that wouldn't also apply to JMAP. Either the deployment allows authenticated users to validate addresses or it doesn't -- that's a policy choice of the deployment and nothing we say in any spec will change that. > One could make a better case for tying it to LDAP, for example. For curiosity's sake, I'd like to hear you make that argument but I doubt it's relevant to this list; maybe a fun bar BOF topic at an IETF ;-). I don't think JMAP should be tied to LDAP but I wrote the pooling LDAP client library from scratch that is deeply integrated in our server so I'm quite familiar with that protocol. - Chris > Brandon > > On Fri, Apr 21, 2017 at 6:02 PM, Chris Newman > <chris.newman@oracle.com> > wrote: > >> On 20 Apr 2017, at 23:16, Adrien de Croy wrote: >> >>> In article <emd3533c0d-dc08-45c3-801c-07972858ad64@bodybag> someone >>>> write: >>>> >>>>> I'd love to see a mail client that does at least initial >>>>> validation on >>>>> destination email addresses as they are added to the message, so >>>>> that >>>>> errors in the addresses which can be resolved at that stage (e.g. >>>>> NXDOMAIN) can be raised with the email author before the mail is >>>>> even >>>>> submitted. >>>>> >>>> >>>> This is quite the can of worms. It's easy enough to look up a >>>> domain >>>> and see if it has an A or an MX, but whatever you were planning to >>>> do >>>> to validate mailboxes will get you blacklisted as a listwashing >>>> spammer. >>>> >>> sure, I think there are fundamental issues with trying to go further >>> than >>> an A/MX for now, but if we built in a mechanism to verify addresses, >>> it >>> could be extended later, rather than being blocked off for all of >>> eternity. >>> >>> Even A/MX would have some value. Who knows what kind of trusted >>> mail >>> delivery infrastructure may come out in the future, at some stage we >>> have >>> to fix SMTP. Forever is a long time. >>> >> >> The present model for MUA mail address validation is to authenticate >> to an >> IETF standard submission server, issue a MAIL FROM + RCPT TO + RSET. >> Anyway, I support adding a feature in JMAP that does the equivalent >> of >> performing this sequence of commands on the Submission server and >> returns a >> 3-digit SMTP status code, optionally SMTP enhanced status codes (see >> RFC >> 3463 section 3.2) and text string. >> >> This is quite extensible and I believe this specific functionality is >> in-scope of the JMAP charter as Submission (RFC 6409) is explicitly >> in-scope. Doing address validation this way is already quite >> powerful. For >> example, if the submission server chooses to implement the SMTP >> 251/551 >> response codes for local users, the mail client gains the ability to >> prompt >> the user to correct the address book entry for that recipient. >> >> How much validation the submission server does then becomes a >> quality-of-implementation issue (and there are, of course, >> security/privacy >> issues). Future work would be to define additional SMTP/Submit >> enhanced >> status codes for additional address validation, but that's presently >> out-of-scope for the JMAP charter. >> >> The JMAP charter does not permit development of a new address >> validation >> mechanism and I object to development of a new incompatible >> validation >> mechanism on the grounds that having two mechanisms to perform the >> same >> function is poor design, when a full-standard mechanism to do address >> validation already exists. I support mapping the existing Submission >> validation mechanism to JMAP in a way that preserves all the >> semantics of >> the existing mechanism. >> >> - Chris >> >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_jmap&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=QBZgPENFbjFadxqU4HJ3ZDpRz3X1JlDY-keqMt52FFo&m=1vWqS7msmD233b9CaI98kh4rSO2gJ-Vly0EVUxduLcE&s=kkW8-WUbouatu9xo78ad7vt4KcIqOQ5maMWA4RMew_M&e= >>
- Re: [Jmap] Submission Alexey Melnikov
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Neil Jenkins
- [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Arnt Gulbrandsen
- Re: [Jmap] Submission Arnt Gulbrandsen
- Re: [Jmap] Submission Arnt Gulbrandsen
- Re: [Jmap] Submission Alexey Melnikov
- Re: [Jmap] Submission Ricardo Signes
- Re: [Jmap] Submission Daniel Kahn Gillmor
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission John R Levine
- Re: [Jmap] Submission John R Levine
- Re: [Jmap] Submission Daniel Kahn Gillmor
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Alexey Melnikov
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Submission Brandon Long
- Re: [Jmap] Submission Brandon Long
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission is not hard Ned Freed
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Address Validation (was Re: Submission) John Levine
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Address Validation (was Re: Submission) Bron Gondwana
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Submission is not hard John Levine
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Arnt Gulbrandsen
- Re: [Jmap] Submission John R Levine
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission John Levine
- Re: [Jmap] Submission is not hard Adrien de Croy
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission is not hard John R Levine
- Re: [Jmap] Submission John R Levine
- Re: [Jmap] Submission is not hard Adrien de Croy
- Re: [Jmap] Submission is not hard John R Levine
- Re: [Jmap] Submission is not hard Adrien de Croy
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Message Tracking and JMAP extensibilit… Chris Newman
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Message Tracking and JMAP extensibilit… Adrien de Croy
- Re: [Jmap] Submission Adrien de Croy
- [Jmap] Message Tracking and JMAP extensibility (w… Chris Newman
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Chris Newman
- Re: [Jmap] Address Validation (was Re: Submission) Adrien de Croy
- [Jmap] Address Validation (was Re: Submission) Chris Newman
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Address Validation (was Re: Submission) Adrien de Croy
- Re: [Jmap] Address Validation (was Re: Submission) Bron Gondwana
- Re: [Jmap] Submission Adrien de Croy
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Submission Ted Lemon
- Re: [Jmap] Submission Ned Freed
- Re: [Jmap] Submission Jeremy Harris
- Re: [Jmap] Address Validation (was Re: Submission) Arnt Gulbrandsen
- Re: [Jmap] Address Validation (was Re: Submission) John R Levine
- Re: [Jmap] Address Validation (was Re: Submission) Arnt Gulbrandsen
- Re: [Jmap] Address Validation (was Re: Submission) John Levine
- Re: [Jmap] Address Validation (was Re: Submission) Cyrus Daboo
- Re: [Jmap] Address Validation (was Re: Submission) John Levine
- Re: [Jmap] Address Validation (was Re: Submission) Arnt Gulbrandsen
- Re: [Jmap] Address Validation (was Re: Submission) Ted Lemon
- Re: [Jmap] Address Validation (was Re: Submission) Adrien de Croy
- Re: [Jmap] Address Validation (was Re: Submission) Bron Gondwana
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Address Validation (was Re: Submission) Adrien de Croy
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Submission Mads Hjorth
- Re: [Jmap] Address Validation (was Re: Submission) Cyrus Daboo
- Re: [Jmap] Address Validation (was Re: Submission) Ted Lemon
- Re: [Jmap] Submission John R Levine
- Re: [Jmap] Address Validation (was Re: Submission) Adrien de Croy
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Address Validation (was Re: Submission) Adrien de Croy
- Re: [Jmap] Address Validation (was Re: Submission) Cyrus Daboo
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Address Validation (was Re: Submission) Alexey Melnikov
- Re: [Jmap] Address Validation (was Re: Submission) Paul Smith
- Re: [Jmap] Address Validation (was Re: Submission) Brandon Long
- Re: [Jmap] Address Validation (was Re: Submission) Chris Newman