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
- [Asrg] Two ways to look at spam Yakov Shafranovich
- [Asrg] Two ways to look at spam Yakov Shafranovich
- RE: [Asrg] Two ways to look at spam Paul Judge
- Re: [Asrg] Two ways to look at spam Alan DeKok
- RE: [Asrg] Two ways to look at spam Yakov Shafranovich
- Re: [Asrg] Two ways to look at spam Yakov Shafranovich
- RE: [Asrg] Two ways to look at spam Barry Shein
- RE: [Asrg] Two ways to look at spam Bob Wyman
- Re: [Asrg] Two ways to look at spam C. Wegrzyn
- RE: [Asrg] Two ways to look at spam Paul Judge
- RE: [Asrg] Two ways to look at spam Yakov Shafranovich
- RE: [Asrg] Two ways to look at spam Yakov Shafranovich
- RE: [Asrg] Two ways to look at spam Bob Wyman
- Re: [Asrg] Two ways to look at spam Bruce Stephens
- Re: [Asrg] Two ways to look at spam Jon Kyme
- Re: [Asrg] Two ways to look at spam Dave Aronson
- Re: [Asrg] Two ways to look at spam Bruce Stephens
- Re: [Asrg] Two ways to look at spam Jon Kyme
- Re: [Asrg] Two ways to look at spam Kee Hinckley
- 6. Solutions - Detection (was Re: [Asrg] Two ways… Yakov Shafranovich
- Re: [Asrg] Two ways to look at spam Bruce Stephens
- Re: [Asrg] Two ways to look at spam Jon Kyme
- RE: [Asrg] Two ways to look at spam Barry Shein
- Re: [Asrg] Two ways to look at spam Andrew Akehurst
- Re: [Asrg] Two ways to look at spam Walter Dnes
- Re: [Asrg] Two ways to look at spam Bruce Stephens