Re: [Jmap] Address Validation (was Re: Submission)
"Adrien de Croy" <adrien@qbik.com> Sat, 22 April 2017 01:34 UTC
Return-Path: <adrien@qbik.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 B90D5128B4E for <jmap@ietfa.amsl.com>; Fri, 21 Apr 2017 18:34:10 -0700 (PDT)
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 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 q0fRhIDKZVKc for <jmap@ietfa.amsl.com>; Fri, 21 Apr 2017 18:34:08 -0700 (PDT)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E4F127698 for <jmap@ietf.org>; Fri, 21 Apr 2017 18:34:07 -0700 (PDT)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.5 (Build 5926)) with SMTP id <0001026507@smtp.qbik.com>; Sat, 22 Apr 2017 13:34:04 +1200
From: Adrien de Croy <adrien@qbik.com>
To: Chris Newman <chris.newman@oracle.com>
Cc: "jmap@ietf.org" <jmap@ietf.org>
Date: Sat, 22 Apr 2017 01:34:04 +0000
Message-Id: <em2713a97d-2fd2-421e-9c51-7ad1e5ae84c9@bodybag>
In-Reply-To: <00616B85-F365-4B1F-82EA-2FF2623CED77@oracle.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>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/SqLBPTkeaipFm1wS27VJYf3zpn8>
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: Sat, 22 Apr 2017 01:34:11 -0000
"two mechanisms to perform the same function is poor design" Sorry I missed this one on the Mt Sinai tablets. We are now and have throughout history been completely inundated with multiple designs and implementations of things for the same function. History has proven this to be a vital part of evolution. Stating this is therefore by definition somehow "poor design" seems like an argument for never improving anything. It could just as well be argued that if the first incarnation were not poor design there would be no need for the existence of (let alone proposals for) the second and subsequent. So maybe with that interpretation you're right. In any case validation upon submission of only local addresses is a long way short of validation prior to submission (during composition) of local and remote addresses, or at least even just allowing for the possibility of this. It's too little too late. Adrien ------ Original Message ------ From: "Chris Newman" <chris.newman@oracle.com> To: "Adrien de Croy" <adrien@qbik.com> Cc: "jmap@ietf.org" <jmap@ietf.org> Sent: 22/04/2017 1:02:55 PM Subject: [Jmap] Address Validation (was Re: Submission) >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://www.ietf.org/mailman/listinfo/jmap
- 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