RE: [Asrg] Two ways to look at spam

Paul Judge <paul.judge@ciphertrust.com> Tue, 01 July 2003 21:14 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16611 for <asrg-archive@odin.ietf.org>; Tue, 1 Jul 2003 17:14:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSRl-00084c-Lz for asrg-archive@odin.ietf.org; Tue, 01 Jul 2003 17:13:54 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h61LDre7031031 for asrg-archive@odin.ietf.org; Tue, 1 Jul 2003 17:13:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSRl-00084Q-IB for asrg-web-archive@optimus.ietf.org; Tue, 01 Jul 2003 17:13:53 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16606; Tue, 1 Jul 2003 17:13:50 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSPw-00080u-RQ; Tue, 01 Jul 2003 17:12:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XSPd-00080i-G8 for asrg@optimus.ietf.org; Tue, 01 Jul 2003 17:11:41 -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 RAA16586 for <asrg@ietf.org>; Tue, 1 Jul 2003 17:11:37 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19XSPa-0000kv-00 for asrg@ietf.org; Tue, 01 Jul 2003 17:11:38 -0400
Received: from mail0.ciphertrust.net ([64.238.118.69] helo=ciphertrust.net) by ietf-mx with esmtp (Exim 4.12) id 19XSPZ-0000ks-00 for asrg@ietf.org; Tue, 01 Jul 2003 17:11:37 -0400
Received: from ([10.0.0.6]) by mail0.ciphertrust.net with ESMTP ; Tue, 01 Jul 2003 12:50:00 -0400 (EDT)
Received: by ctxchg.ciphertrust.com with Internet Mail Service (5.5.2653.19) id <G7BLY2TM>; Tue, 1 Jul 2003 12:38:05 -0400
Message-ID: <B1F08F445F370846AB7BEE424365F00D0188CAE1@ctxchg.ciphertrust.com>
From: Paul Judge <paul.judge@ciphertrust.com>
To: 'Yakov Shafranovich' <research@solidmatrix.com>, Paul Judge <paul.judge@ciphertrust.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: Tue, 01 Jul 2003 12:38:00 -0400


> -----Original Message-----
> From: Yakov Shafranovich [mailto:research@solidmatrix.com]
> Sent: Monday, June 30, 2003 10:25 PM

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

I think your next question at the bottom is closely related, so I will
elaborate there.

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

On the global level, in addition to the goal of reducing the amount of spam
that is received, the goal is to reduce the amount of spam that is sent. The
consent framework on a local level affects the amount of spam that is
received; however, in many cases, we must have an inter-network solution to
affect the ability to send spam. The types of solutions that can affect the
ability to send spam according to the taxonomy include: 1) spam prevention
systems including spam protection systems (transaction-level C/R,
greylisting, consent tokens) and spam deterrence systems; 2) spam detection
systems that operate at the network-level or within the SMTP protocol (i.e.
blacklists and various DNS lookup systems); and 3) spam responses that limit
the ability to send traffic in the future (i.e. rate limiting systems). 


> Are we talking about different hosts or networks on the
> Internet expressing 
> combined consent of their users to each other? 

In addition to the approaches mentioned above, there is the opportunity to
provide spam detection closer to the source.

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

The problem with spam detection closer to the source is that you are making
a decision for all the downstream receivers. Currently, due to the blunt
'spam vs. non-spam' classification used by many anti-spam systems, it is
risky to make that decision for multiple organzations. The move towards a
more granular expression of desired and undesired communications allows
perhaps a logic or language to be built that will allow a more precise
policy enforcement even on an inter-network level. This would allow the
common rules to be implemented as close to the source as possible.

> Or are we simply talking 
> about various systems that collect data to be used on the 
> local level?

In all of this, there are, of course ,various systems performing different
tasks. Information exchange between these systems is very important not only
for the coordination of this system, but to share relevant information based
on the other systems view of the world. For example, we have seen: 1) the
C/R internetworking proposal that looks at coordination between systems and
2)information sharing in systems such as blacklists, DCC, and razor. There
are other coordination systems to consider as well as more advanced
information sharing approaches such as reputation systems.

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