Re: [Asrg] Some data on the validity of MAIL FROM addresses

Dave Crocker <dhc@dcrocker.net> Mon, 19 May 2003 04:36 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25149 for <asrg-archive@odin.ietf.org>; Mon, 19 May 2003 00:36:52 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4J45cA31667 for asrg-archive@odin.ietf.org; Mon, 19 May 2003 00:05:38 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J45cB31664 for <asrg-web-archive@optimus.ietf.org>; Mon, 19 May 2003 00:05:38 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25142; Mon, 19 May 2003 00:36:21 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HcPa-00079U-00; Mon, 19 May 2003 00:38:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19HcPa-00079R-00; Mon, 19 May 2003 00:38:10 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J40JB31445; Mon, 19 May 2003 00:00:19 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4J3xVB31379 for <asrg@optimus.ietf.org>; Sun, 18 May 2003 23:59:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25061 for <asrg@ietf.org>; Mon, 19 May 2003 00:30:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HcJg-00077w-00 for asrg@ietf.org; Mon, 19 May 2003 00:32:04 -0400
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 19HcJf-00077t-00 for asrg@ietf.org; Mon, 19 May 2003 00:32:03 -0400
Received: from adsl-68-120-80-8.dsl.irvnca.pacbell.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id h4J4X0N05473; Sun, 18 May 2003 21:33:00 -0700
From: Dave Crocker <dhc@dcrocker.net>
X-Mailer: The Bat! (v1.63 Beta/4) Personal
Reply-To: Dave Crocker <dcrocker@brandenburg.com>
Organization: Brandenburg InternetWorking
X-Priority: 3 (Normal)
Message-ID: <6419342993.20030518213514@brandenburg.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
CC: asrg@ietf.org
Subject: Re: [Asrg] Some data on the validity of MAIL FROM addresses
In-Reply-To: <200305190208.h4J28JNw009481@calcite.rhyolite.com>
References: <p06001227baeddbf491c3@[192.168.1.104]> <200305190208.h4J28JNw009481@calcite.rhyolite.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Sun, 18 May 2003 21:35:14 -0700
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

>> Can you show instances in which they say yes to messages they cannot deliver?

VS> I was skeptical of the report that Yahoo defers no-such-user responses
VS> until the DATA command, and so I made the obvious `telnet ... 25` test.
VS> I tried a perfectly valid message to an address that was very unlikely
VS> to exist.  The Rcpt_To command was answered with at 250 response.  It
VS> was not until the end of the DATA command that I got a 5yz.


Folks, the email operations world has increasingly moved away from
real-time processing of SMTP data.

Processing causes delays and SMTP client daemons are impatient. The
very, very wide range of network delays has compunded the effect of
these processing delays, constantly causing problematic timeouts.

So the tendency, these days, is to just say 'yes' in the protocol, take
the addresses and content, store them in a queue, and do any real work
after the connection closes.

d/
--
 Dave Crocker <mailto:dcrocker@brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg