IETF Logo Mail Archive

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

"Adrien de Croy" <adrien@qbik.com> Mon, 24 April 2017 21:37 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 E920C1317F3 for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 14:37:07 -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 eKkohb7HpqRi for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 14:37:05 -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 6C6A0120227 for <jmap@ietf.org>; Mon, 24 Apr 2017 14:37:04 -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 <0001028908@smtp.qbik.com>; Tue, 25 Apr 2017 09:37:01 +1200
From: Adrien de Croy <adrien@qbik.com>
To: John R Levine <johnl@taugh.com>
Cc: "jmap@ietf.org" <jmap@ietf.org>
Date: Mon, 24 Apr 2017 21:37:01 +0000
Message-Id: <emced4cfbd-91e8-4ad7-974e-ab757894cf10@bodybag>
In-Reply-To: <alpine.OSX.2.20.1704240925190.68584@ary.qy>
References: <1492996915.3310412.953749536.0F1C8B46@webmail.messagingengine.com> <20170424014957.39235.qmail@ary.lan> <emb951e04d-3dc9-4244-915b-21bd272245ff@bodybag> <alpine.OSX.2.20.1704240925190.68584@ary.qy>
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/A1zic9bynn5pSV1Zp1wCcbXXDkI>
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 21:37:08 -0000


------ Original Message ------
From: "John R Levine" <johnl@taugh.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "jmap@ietf.org" <jmap@ietf.org>
Sent: 25/04/2017 1:43:23 AM
Subject: Re: [Jmap] Address Validation (was Re: Submission)

>>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.
>
>Once again, that's a change to SMTP and in this case a fairly large and 
>incompatible one.
actually I didn't envisage this one going anywhere near SMTP in the 
first instance.  The JMAP server can easily do domain-part validation, 
or any other validation available to it (address book lookup, security 
policy whatever) and deny the recipient validation.


>
>
>On all the mail systems I know, if you try to send mail at a domain 
>that doesn't exist, it fails instantly.
I've seen a lot delayed, especially when the initial submission server 
forwards to another pre-configured "smarthost" which then delays it 
further.

Adrien


>The problem is when you send mail to a domain that has an A record but 
>no mail server.  There's no way for a client system to tell a 
>nonexistent mail server from one that crashed and will be back shortly. 
>  Maybe the retry timeout should be less than the 4-5 days that RFC 5321 
>suggests, but that's a quality of implementation issue that has nothing 
>whatsoever to do with JMAP.
>
>Regards,
>John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
>Please consider the environment before reading this e-mail. 
>https://jl.ly
>
>_______________________________________________
>Jmap mailing list
>Jmap@ietf.org
>https://www.ietf.org/mailman/listinfo/jmap

v2.23.0 | Report a Bug | By Email