[Asrg] Two ways to look at spam

Yakov Shafranovich <research@solidmatrix.com> Sun, 29 June 2003 06:13 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 CAA22516 for <asrg-archive@odin.ietf.org>; Sun, 29 Jun 2003 02:13:44 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5T6DF607079 for asrg-archive@odin.ietf.org; Sun, 29 Jun 2003 02:13:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WVR4-0001q6-St for asrg-web-archive@optimus.ietf.org; Sun, 29 Jun 2003 02:13:14 -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 CAA22459; Sun, 29 Jun 2003 02:13:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WVR1-0007QU-00; Sun, 29 Jun 2003 02:13:11 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19WVQv-0007QR-00; Sun, 29 Jun 2003 02:13:05 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WVQr-0001mX-JX; Sun, 29 Jun 2003 02:13:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WVQH-0001jF-PW for asrg@optimus.ietf.org; Sun, 29 Jun 2003 02:12:25 -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 CAA22346 for <asrg@ietf.org>; Sun, 29 Jun 2003 02:12:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WVQE-0007Pw-00 for asrg@ietf.org; Sun, 29 Jun 2003 02:12:22 -0400
Received: from 000-254-303.area7.spcsdns.net ([68.27.233.50] helo=68.27.233.50) by ietf-mx with smtp (Exim 4.12) id 19WVQ2-0007Pp-00 for asrg@ietf.org; Sun, 29 Jun 2003 02:12:11 -0400
Message-Id: <5.2.0.9.2.20030629021151.00bbe168@solidmatrix.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
Subject: [Asrg] Two ways to look at spam
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 02:11:52 -0400

It seems to me that the members of the group are looking at the spam 
problem from two different angles:

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.
2. Consent - others in particular, the people or person who wrote the group 
charter, propose that spam be viewed as an issue of consent. Spam is caused 
by the fact that the receivers have no mechanisms in place to be able to 
express their consent to receiving email.

Thus, all of the proposals fall into three general categories:
1. Network Abuse - these proposals are the ones that look at the underlying 
nature of email and trying to fix or correct the abuse problem. This 
includes RMX, rDNS, certificates in DNS, distributed spam detection systems 
such as DCC, systems for detecting open relays and proxies, creating a 
separate email system, moving from SMTP to a different protocol, charging 
for sending email, etc.
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. These proposals define various mechanisms 
and structures through which the receiver (or his ISP), can his or her 
consent about wanting to receive email. These include trusted sender 
systems (like Habeas), filtering systems based on message content (like 
SpamAssasin, HTML blocking), C/R systems, systems based on passwords 
(Selby's proposal for lock-and-key), manual whitelists, etc.
3. Combination - these includes combination systems like filtering on 
receiver's end based on a blacklist of open proxies, etc.

The problem is that many of these approaches if implemented independently 
of each other, would not be able to operate together as a cohesive system, 
and in some cases interfere with each other. I would like to see these two 
models of spam and three approaches to anti-spam defined clearly so we can 
work out a cohesive model of how to fight spam.

Yakov 


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