Re: [Asrg] SMTP pull anyone?

Bill Cole <asrg3@billmail.scconsult.com> Sun, 16 August 2009 18:14 UTC

Return-Path: <asrg3@billmail.scconsult.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125DD3A69AB for <asrg@core3.amsl.com>; Sun, 16 Aug 2009 11:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.369
X-Spam-Level:
X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_73=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G98x+BM0U8HH for <asrg@core3.amsl.com>; Sun, 16 Aug 2009 11:14:35 -0700 (PDT)
Received: from toaster.scconsult.com (news.scconsult.com [66.73.230.190]) by core3.amsl.com (Postfix) with ESMTP id 5D09B3A6BD3 for <asrg@irtf.org>; Sun, 16 Aug 2009 11:14:01 -0700 (PDT)
Received: from bigsky.scconsult.com (bigsky.scconsult.com [192.168.2.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by toaster.scconsult.com (Postfix) with ESMTP id DBBBD93C4A0 for <asrg@irtf.org>; Sun, 16 Aug 2009 14:14:00 -0400 (EDT)
Message-ID: <4A884C68.7020301@billmail.scconsult.com>
Date: Sun, 16 Aug 2009 14:14:00 -0400
From: Bill Cole <asrg3@billmail.scconsult.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <922a897b0908160420w4554837aj684e86eb586823af@mail.gmail.com>
In-Reply-To: <922a897b0908160420w4554837aj684e86eb586823af@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] SMTP pull anyone?
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: asrg@irtf.org
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Aug 2009 18:14:36 -0000

Ravi shankar wrote, On 8/16/09 7:20 AM:
> Hi,
> Me and my buddy had a interesting discussion, which i thought could put
> across the geeks here.
> It goes something like this:
> SMTP is currently a push protocol and is initiated by the the sender, no
> controlling that fact.
> But it is possible to overcome the relay problems, IP spoofing and
> domain impersonation etc,
> by making the servers pull the mails.
> 1. Sending server contacts the destination and proovides the Message ID
> and sender details(and other details) and disconnects the session.
> 2. The receiving server queues it up and looks up the messages one by
> one using DNS to determine their legitimacy.

DNS itself provides no mechanism for determining the legitimacy of email.

DNS is used *as a medium* for various applications that are used to identify 
mail as legitimate or illegitimate by various standards of legitimacy, and a 
major reason for its use in those applications is to make it feasible for 
mail systems to do the validation synchronously during the SMTP session. By 
using a lightweight, distributed, cached database, mail systems are spared 
from deferring a message, queuing its validation, remembering the results, 
and waiting for the sender to offer it in an identical way again. You are 
suggesting that receivers should take on all the heavyweight management but 
retain using DNS for something unspecified. It makes no sense.

> 3. If the IP that contacted is legitimate(can be verified by say SPF?),
> it contacts the sender and provides the message ID with other details.

The *most* that SPF can provide towards showing "legitimacy" is to confirm 
that the envelope sender address of a message is not forged. It is very rare 
for large senders of any sort to deploy records that can do that strongly. 
There is nothing about SPF that directly attacks spamming. It could in 
theory be used to attack sender forgery, but the collateral damage has 
proven to be too great for either sending or receiving systems to actually 
apply it strongly to that end. Meanwhile, a lot of spammers are sending a 
lot of spam with senders that are validated to the degree that SPF can 
validate anything.


> 4. The sending server then hands over the message.
> 5. To overcome DDoS attacks, the receiving server can be made to request
> the next 10 or so Message IDs that it will assign to messages,
> so that if a attacker tries to give those details, it will know from the
> next list of message IDs that it's fake connection.

That sentence makes no sense. What did you mean to say?

> 6. May be by this collection of data, the IP addresses can be reported
> to a RBL and blacklisted.
> Please point the holes in this model, so that we might get a entirely
> new insight.

Nothing you have described would add to spam control as it is currently 
being done, as far as I can see. The 'model' is too vague to critique inn 
detail because you aren't really providing any meaningful details.

In order to bring anything truly new and useful to controlling email spam, a 
new idea has to either attack spam in a way that existing tactics don't, do 
a demonstrably better job than existing tactics, or overcome the negative 
aspects of existing tactics. You have identified none of those in your new 
idea.

> Note: I have gone trough IM2000 and other similar discussions in the
> archive. Just thought this version of C/R is worth getting discussed.

As described, there's not much to discuss. It looks like it might be a 
little like IM2000 (which has been a complete failure) if fleshed out, but 
you haven't explained how this would differ from it, how it would integrate 
with existing SMTP, or how it would offer anything significantly better than 
existing mechanisms.

Right now, receivers can choose to validate the sender against SPF records 
after receiving the MAIL command and reject non-validating messages at that 
point, or they can wait until RCPT if they want their rejections to be more 
broadly respected, or they can wait until the second phase of DATA if they 
want to weight SPF results along with other filters that rely on message 
data. Many sites already explicitly reject the vast majority of offered 
messages in response to RCPT or earlier without requiring legitimate senders 
to sit on a pile of pending offered messages that may or may not be asked 
for later. You have not identified any benefits for receiving systems or 
legitimate senders, so it is hard to agree that it is "worth getting 
discussed" or indeed worth anything at all. Where is the added value?