RE: [Asrg] Two ways to look at spam

Paul Judge <paul.judge@ciphertrust.com> Sun, 29 June 2003 19:51 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 PAA06683 for <asrg-archive@odin.ietf.org>; Sun, 29 Jun 2003 15:51:37 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5TJp8C14016 for asrg-archive@odin.ietf.org; Sun, 29 Jun 2003 15:51:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WiCa-0003dz-Qc for asrg-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 15:51:08 -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 PAA06679; Sun, 29 Jun 2003 15:51:07 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WiCZ-0004vY-00; Sun, 29 Jun 2003 15:51:07 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WiCT-0004vV-00; Sun, 29 Jun 2003 15:51:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WiCU-0003Xf-58; Sun, 29 Jun 2003 15:51:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WiBe-0003So-6t for asrg@optimus.ietf.org; Sun, 29 Jun 2003 15:50:10 -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 PAA06666 for <asrg@ietf.org>; Sun, 29 Jun 2003 15:49:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WiBI-0004u3-00 for asrg@ietf.org; Sun, 29 Jun 2003 15:49:48 -0400
Received: from mail0.ciphertrust.net ([64.238.118.69] helo=ciphertrust.net) by ietf-mx with esmtp (Exim 4.12) id 19WiB8-0004tA-00 for asrg@ietf.org; Sun, 29 Jun 2003 15:49:38 -0400
Received: from ([10.0.0.6]) by mail0.ciphertrust.net with ESMTP ; Sun, 29 Jun 2003 15:48:09 -0400 (EDT)
Received: by ctxchg.ciphertrust.com with Internet Mail Service (5.5.2653.19) id <G7BLYCPX>; Sun, 29 Jun 2003 15:35:51 -0400
Message-ID: <B1F08F445F370846AB7BEE424365F00D0188CA52@ctxchg.ciphertrust.com>
From: Paul Judge <paul.judge@ciphertrust.com>
To: 'Yakov Shafranovich' <research@solidmatrix.com>, "'asrg@ietf.org'" <asrg@ietf.org>
Subject: RE: [Asrg] Two ways to look at spam
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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, 29 Jun 2003 15:35:49 -0400

> -----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
> 
> 
> It seems to me that the members of the group 
> 
> 1. Network Abuse - some people including Barry Shain and Eric Brunner 
> specifically, have been proposing that we look at the entire 
> spam problem 
> as one of network abuse. The Internet in general, and SMTP in 
> particular, 
> have been built as open systems trusting all network users to behave 
> themselves. Spam is caused by those users abusing the network and its 
> resources.

I, of course, encourage the generalization of the problem and also casting
it into some framework. I agree that people are "looking at the spam problem
from two different angles" but I do not think that necessarily means that
the proposals fall into those three categories.

The consent-based communication paradigm also looks at the spam problem as a
large-scale networking problem. There are properties of the email system
that spammers are exploiting; this causes a number of symptoms. Some members
focus on the symtpom of network abuse (which is definitely a valid concern);
however, it is already considered as part of the consent-based communication
framework. To help clarify the difference between the vulnerabilites and
symptoms that are a result of the exploit of these vulnerabilities,
Liudvikas Bukys was working on an 'inventory of problems' document.



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

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.

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