Re: [Jmap] Address Validation (was Re: Submission)

"Adrien de Croy" <adrien@qbik.com> Mon, 24 April 2017 02:07 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 7DD75126C2F for <jmap@ietfa.amsl.com>; Sun, 23 Apr 2017 19:07:37 -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 P7Kdrf_bp5nv for <jmap@ietfa.amsl.com>; Sun, 23 Apr 2017 19:07:35 -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 AA405120046 for <jmap@ietf.org>; Sun, 23 Apr 2017 19:07:34 -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 <0001027887@smtp.qbik.com>; Mon, 24 Apr 2017 14:07:31 +1200
From: Adrien de Croy <adrien@qbik.com>
To: John Levine <johnl@taugh.com>, "jmap@ietf.org" <jmap@ietf.org>
Cc: "brong@fastmail.fm" <brong@fastmail.fm>
Date: Mon, 24 Apr 2017 02:07:31 +0000
Message-Id: <emb951e04d-3dc9-4244-915b-21bd272245ff@bodybag>
In-Reply-To: <20170424014957.39235.qmail@ary.lan>
References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan>
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/Zkem7STEBlyeGdDDWth4Kp5ZnPg>
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: Mon, 24 Apr 2017 02:07:37 -0000

when I made the suggestion, I was imagining that although you can't do 
VRFY or EXPN or probe emails and yes this is for good reason, the number 
of times I've had bounce messages a long time after submission for 
problems such as NXDOMAIN, means the current system isn't very good at 
even this.

Also if we put a system into JMAP to allow it, it can then be extended.  
If we don't, we are stuck with the current functionality.

I believe there is certainly some value in pre-checking an address.

The problem tends to happen in more cases than you'd think (e.g. not 
just importing / checking an address book).  I've seen many messages 
stuck in retry queues which are just replies to an email from someone 
who made a mistake setting their own email address in their mail client. 
  Presumably these people have a frustrating life wondering why they 
never get replies until they sort it out.  Also if you take someone's 
address down from some other medium (phone) and get it wrong.  People 
often write what they want to hear rather than what is spoken to them.

So you can't even rely on people to get their own email correct, and you 
can't rely on an address being correctly transcribed.  It's on first use 
that you find out whether the address is any good.  Also it's fairly 
common for addresses to get cancelled, even domains expire.

Checking (whatever form of checking is possible) early is better than 
later, as it can provide more options.  If you hit send and bolt for the 
door, even a submission bounce will be too late.

At the moment yes I believe all the checking that's really possible is 
just at the domain level.  that's not to say that's all the checking 
there will ever be, once (if) it's proven to have sufficient value.

Adrien

------ Original Message ------
From: "John Levine" <johnl@taugh.com>
To: "jmap@ietf.org" <jmap@ietf.org>
Cc: "brong@fastmail.fm" <brong@fastmail.fm>
Sent: 24/04/2017 1:49:57 PM
Subject: Re: [Jmap] Address Validation (was Re: Submission)

>In article 
><1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> you 
>write:
>>Do we want JMAP-Mail to include a facility to check whether an address 
>>would be accepted for mail delivery by the server - presumably the 
>>result is a
>>tristate of [definite YES, Unknown, definite NO] via whatever response 
>>method is used.
>
>I'm trying to think of a plausible use case for separate checks rather
>than at submission time, and also trying to think of a plausible way
>to do useful checks on non-local addresses.
>
>The use cases I think of are pretty contrived, like someone just
>uploaded an address book and wants to prune out the bogus addresses.
>
>For the latter, since nobody supports VRFY and EXPN any more (for good
>reasons,) and RCPT TO probes tend to get you blacklisted, the answer
>for remote addreses is always going to be "maybe" unless you mistype
>a nonexistent domain.
>
>So I wouldn't bother.  The addresses will get checked when people send
>the message, just like now.
>
>R's,
>John
>
>
>_______________________________________________
>Jmap mailing list
>Jmap@ietf.org
>https://www.ietf.org/mailman/listinfo/jmap