RE: [Asrg] Two ways to look at spam

Yakov Shafranovich <research@solidmatrix.com> Tue, 01 July 2003 02:27 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 WAA26912 for <asrg-archive@odin.ietf.org>; Mon, 30 Jun 2003 22:27:28 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h612R1511207 for asrg-archive@odin.ietf.org; Mon, 30 Jun 2003 22:27:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XArE-0002ug-Vp for asrg-web-archive@optimus.ietf.org; Mon, 30 Jun 2003 22:27:01 -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 WAA26906; Mon, 30 Jun 2003 22:26:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XAr9-0006Fy-00; Mon, 30 Jun 2003 22:26:55 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19XAqa-0006Fq-00; Mon, 30 Jun 2003 22:26:20 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XAqI-0002kI-Er; Mon, 30 Jun 2003 22:26:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XAq4-0002jw-V0 for asrg@optimus.ietf.org; Mon, 30 Jun 2003 22:25:49 -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 WAA26890 for <asrg@ietf.org>; Mon, 30 Jun 2003 22:25:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XAq1-0006Fi-00 for asrg@ietf.org; Mon, 30 Jun 2003 22:25:45 -0400
Received: from 000-235-455.area5.spcsdns.net ([68.27.158.252] helo=68.27.158.252 ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19XApp-0006Fa-00 for asrg@ietf.org; Mon, 30 Jun 2003 22:25:34 -0400
Message-Id: <5.2.0.9.2.20030630221600.00b34f90@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Paul Judge <paul.judge@ciphertrust.com>, "'asrg@ietf.org'" <asrg@ietf.org>
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: RE: [Asrg] Two ways to look at spam
In-Reply-To: <B1F08F445F370846AB7BEE424365F00D0188CA52@ctxchg.ciphertrus t.com>
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: Mon, 30 Jun 2003 22:24:52 -0400

At 03:35 PM 6/29/2003 -0400, Paul Judge wrote:

> > -----Original Message-----
> > From: Yakov Shafranovich [mailto:research@solidmatrix.com]
> > Sent: Sunday, June 29, 2003 2:12 AM
> > To: asrg@ietf.org
> > Subject: [Asrg] Two ways to look at spam
> >
>[..]
>
> > 2. Consent - these proposals do not try to block the email at
> > the sender's
> > end, or as at being transferred over the network. Instead,
> > they concentrate
> > solely at the receiver's point.
>
>This is not the case. It is most desirable to block unwanted traffic as
>close to the source as possible. There is some difficulty in moving the
>solution closer to the source in that you are enforcing a policy for all
>downstream receivers. Careful policy expression helps here.

Can you elaborate on this point?

>Overall, I think that consent-based communication as referred to in the
>charter includes what you have referred to here as 'consent' and 'network
>abuse' models. What I think you are touching on here with these two models
>is what I refer to as local vs global spam solutions. A local solution
>refers to controlling spam for some individual or organization. I also think
>of this as providing symptom relief rather than a real cure. This is
>commonly done today with anti-spam tools deployed at the desktop, server, or
>gateway. There are a number of commercial and non-commercial solutions that
>are quite effective at 'solving the problem' for local environments.
>
>While many individuals and organizations have deployed such solutions, the
>spam problem continues to exist globally. It is even suggested that these
>local solutions have increased the global problem since spammers are sending
>more. The solution to the global problem requires an understanding of the
>adversaries and their motivation. As many have suggested, controlling spam
>globally requires reversing the spammers profit model. What I suggest that
>is different is that this does not require directly associating a cost with
>sending email.
>
>Just as in any other business, the profit in spamming is equal to revenues
>minus costs. In spamming, revenue is equal to the number of spam messages
>received times the response rate times the profit per item. Expenses include
>the cost of obtaining the lists of email addresses and the cost of sending
>the messages. The difference between the amount of spam messages sent and
>the number received is a factor of the effectiveness and deployment rate of
>anti-spam technologies. User education is able to affect the response rate
>as well as the difficulty and costs of obtaining email addresses. Besides
>providing a strong deterrence, anti-spam legislation is able to introduce
>overhead in the form of the expenses of litigation.
>
>The consent-based communications paradigm considers this and directly
>affects both the number of spam messages sent and the number received. If
>you consider this along with the taxonomy that looked at spam prevention,
>spam detection and spam response approaches, then the relationship can be
>seen between the various anti-spam system proposals, the consent-based
>communications paradigm, and global and local spam solutions.
>
>With that said, I do agree that we need to further document this framework
>to provide a clearer view as we deal with this large number of individual
>proposals. It seems that without this clarity, many are having trouble
>putting everything in context. All, please share your thoughts on this view
>of the overall framework.

The consent framework on a local level seems simpler to understand than on 
the global level. Locally the consent framework may consists of various 
components that will keep track of what the user has consented to, and what 
email he did not consent to. Some of these consent decisions may be made 
automatically based on various pieces of information such as RBLs, message 
content, C/R, etc. Some of them maybe be made manually by the user. 
However, on the global level how does is the consent framework relevant? 
Are we talking about different hosts or networks on the Internet expressing 
combined consent of their users to each other? Or are we simply talking 
about various systems that collect data to be used on the local level? The 
charter is a bit murky on this:

"Expressing consent is more straightforward on an individual basis; as the 
solution is moved closer to the source, it is more difficult to express a 
policy that satisfies all downstream receivers. "

Yakov 


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