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

Yakov Shafranovich <research@solidmatrix.com> Tue, 20 May 2003 18:07 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 OAA23433 for <asrg-archive@odin.ietf.org>; Tue, 20 May 2003 14:07:12 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KHXb120705 for asrg-archive@odin.ietf.org; Tue, 20 May 2003 13:33:37 -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 h4KHXbB20702 for <asrg-web-archive@optimus.ietf.org>; Tue, 20 May 2003 13:33:37 -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 OAA23410; Tue, 20 May 2003 14:06:42 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBUI-0007LE-00; Tue, 20 May 2003 14:05:22 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19IBUH-0007LA-00; Tue, 20 May 2003 14:05:21 -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 h4KHQoB20318; Tue, 20 May 2003 13:26:50 -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 h4KHPZB20255 for <asrg@optimus.ietf.org>; Tue, 20 May 2003 13:25:35 -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 NAA23122 for <asrg@ietf.org>; Tue, 20 May 2003 13:58:40 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBMW-0007HC-00 for asrg@ietf.org; Tue, 20 May 2003 13:57:20 -0400
Received: from 000-254-406.area7.spcsdns.net ([68.27.233.153] helo=68.27.233.153) by ietf-mx with smtp (Exim 4.12) id 19IBMU-0007H2-00 for asrg@ietf.org; Tue, 20 May 2003 13:57:19 -0400
Message-Id: <5.2.0.9.2.20030520134501.00b99fa0@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] Some data on the validity of MAIL FROM addresses
In-Reply-To: <E19I6KM-0004Ck-00@argon.connect.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
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: Tue, 20 May 2003 13:58:06 -0400

At 01:34 PM 5/20/2003 +0100, Jon Kyme wrote:

> >Folks, the email operations world has increasingly moved away from
> >real-time processing of SMTP data.
> >
>
>A colleague has just drawn my attention to the relevant part of rfc2505
>(BCP 30) - for completeness here it is:
>
><quote>
>1.5. Where to block spam, in SMTP, in RFC822 or in the UA
>
>    Our basic assumption is that refuse/accept is handled at the SMTP
>    layer and that an MTA that decides to refuse a message should do so
>    while still in the SMTP dialogue. First, this means that we do not
>    have to store a copy of a message we later decide to refuse and
>    second, our responsibility for that message is low or none - since we
>    have not yet read it in, we leave it to the sender to handle the
>    error.
>
></quote>

See RFC 2821, section 3.1.:

---snip----
    However, in practice, some servers do not perform recipient
    verification until after the message text is received.  These servers
    SHOULD treat a failure for one or more recipients as a "subsequent
    failure" and return a mail message as discussed in section 6.
---snip----

Even thought it might be recommended to do processing in real-time, in 
practice many systems do not and will not. We must be take that into account. 

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