[Asrg] [ASRG] SMTP pull anyone?

Ravi shankar <ravisha22@gmail.com> Mon, 17 August 2009 09:53 UTC

Return-Path: <ravisha22@gmail.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 27D3728C295 for <asrg@core3.amsl.com>; Mon, 17 Aug 2009 02:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id JDQKb5S1W+RR for <asrg@core3.amsl.com>; Mon, 17 Aug 2009 02:53:32 -0700 (PDT)
Received: from mail-qy0-f194.google.com (mail-qy0-f194.google.com []) by core3.amsl.com (Postfix) with ESMTP id 7E89628C294 for <asrg@irtf.org>; Mon, 17 Aug 2009 02:53:32 -0700 (PDT)
Received: by qyk32 with SMTP id 32so2002905qyk.15 for <asrg@irtf.org>; Mon, 17 Aug 2009 02:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7AQejJ33Nk8NYjSxxxpbGM5ZXXOAH4XNEMvZD8sD9dw=; b=YWQMPy6vnWXviEKGvbTB+S46KMVKOi/upyltSCPNHVjfNrkvhDYo7o2e0fe0zuJiKJ 2OtpuVw0xlh2fsVuS6v/S8+zI3nFlPhMPXdh03yegWefoGmN0GeQIqPv2H6pNcHcNq8t RH3GtfFgpMQYLxeuc3L77ZIoo69CWi5oVHFrs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cID+nHo+dNFJG6josObO1tMv5YoTdU28+3y8f6pgx6BT9QdAdwl9SPlKXPq1v1s3ky 5rFDoEE45Nu8OcQWTbz59AdEUnW1B82skX2fjXISl2UGZGoX5y/9nfRuYMTus7GjCxY0 l0g2vbQ5sT/iEQRC+3NHHVzXkkC6DRWx+owWA=
MIME-Version: 1.0
Received: by with SMTP id i12mr4044430qao.120.1250502816117; Mon, 17 Aug 2009 02:53:36 -0700 (PDT)
Date: Mon, 17 Aug 2009 15:23:36 +0530
Message-ID: <922a897b0908170253k60c0d57dh5e593c78f9137fab@mail.gmail.com>
From: Ravi shankar <ravisha22@gmail.com>
To: asrg@irtf.org
Content-Type: multipart/alternative; boundary=000feaf1dbdd2538310471536035
Subject: [Asrg] [ASRG] SMTP pull anyone?
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <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: Mon, 17 Aug 2009 09:53:39 -0000

>DNS is used *as a medium* for various applications that are used to

>mail as legitimate or illegitimate by various standards of legitimacy, and

>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.


Today's model is no different from what i have suggested in that they deploy
costly anti-spam

solutions, which utilise probably 10 fold resource than what this solution
will use. By allowing the system to cut most of the spam through a simple
pull mechanism, compares very well against today's anti-spam software model,
which not all can afford.

>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

>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.

Actually SPF only validate the legitimacy of the sender IP and domain
relation and i mentioned SPF as just a example. And if the large senders
cannot implement something as simple as a TXT record for SPF (leave alone
DKIM), then probably they do no care about spam. SPF or DKIM are only
effective when deployed by all the domains that send mails.

> 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?

What i mean is in order to prevent a system from getting overwhelmed, by
anonymous submission, if for say domain1.com server knows the next 10
message ID that will be sent by domain2.com, then it can confidently reject
those message submission attempts that does not have any mails in this range
(ofcourse this logic holds only if domain2.com is going to send those 10
message IDs domain1.com only)

>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,

>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


I guess we are expecting a magic solution that will stop all the spam in a
single go and would not require us from changing our system continuosly. But
unfortunately, every system has flaws and has to be corrected one step at a
time, this i believe is the evolution.
I have done my best to detail how this system applies in various steps of a
mail communication, may be i can work on a pictorial representation, if
someone else requires it as well.