Subject: [Asrg] Taxonomy of anti-spam systems

From: Paul Judge <[email-masked]>
Date: Sun, 9 Mar 2003 22:05:03 -0500

Here is a first draft of a taxonomy of anti-spam systems. I've classified
the systems into spam prevention, spam deterrence, and spam reduction
systems.

1.	Spam Prevention Approaches -  These systems aim to prevent the
spread of spam messages. There are fail-open and fail-closed systems.
Fail-open systems aim to detect unwanted messages; just as in intrusion
detection, there are signature-based and anomaly detection-based schemes.
I've marked them below as either [SB] or [AD]. Another useful view would be
whether systems are implemented at the ingress or egress.

	a)	Fail-Open (determine unwanted messages)
		i)	Human Determination
			(1)	Collaborative filtering (i.e., razor) [SB]
		ii)	System Determination
			(1)	Who is it from? 
				(a) Traditional Blacklists [SB]
				(b) reputation systems [AD]
			(2)	What is in it? (Content Filtering)
				(a)	Static lists [SB]
				(b)	Learning methods [AD]
			(3)	How was it sent?
				(a)	Forged info? (i.e. reverse lookups)
[AD]
				(b)	Envelope characteristics; delivery
path information [SB/AD]
			(4)   Other properties
				(a) bulk determination (i.e. DCC)

	b)	Fail-Closed (determine wanted messages)
		i)	Whitelists
			(1)	Basic
			(2)	Verified
				(a)	Authenticated sender identity
				(b)	Token supported		
				(c)	Disposable email addresses
			(3)  Used in Fail-open systems 
				(a) normal whitelists
				(b) Third-party lists (i.e. trusted sender)
		ii)	Challenge/response systems
			(1)	Basic	
			(2)	Human verification (i.e. Turing tests)

2)	Spam Deterrence Approaches - These systems aim to deter spamming
activities. In most areas of life, deterrence is achieved by introducing the
ability to identify and track wrongdoers. These systems can provide input to
spam prevention systems. Also, these systems are useful with the presence of
laws to prosecute the wrongdoers that are identified and tracked.

	a)	Authentication
	b)	Tracking
	c)	Non-repudiation

3)	Spam Reduction - These systems aim to reduce the level of spam by
making it more costly or timely to have the messages delivered.
Independently, this type of system does not aim to identify or block spam,
but simply to change the characteristics of the spam to reduce the amount of
spam. These systems can be used in conjunction with deterrence or prevention
systems.

	a)	Cost-based Systems (increase cost of spamming)
	b)	Proof-of-work (i.e. hashcash)
	c)	Rate limiting
		i)	Ingress
		ii)	egress

I'm not fully comfortable with the spam reduction being a third category,
but I am currently not sure how to better classify them. What classes of
techniques did I miss? Once we add other classes and see if there are better
ways to classify these, we will begin to build this out into a survey of the
systems in each class. I have a draft of some of this done, but I want to
get feedback on the taxonomy before dumping that on the list.

Paul
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 10 Mar 2003 08:31:54 +0000 (GMT)

On Sun, 9 Mar 2003, Paul Judge wrote:

> techniques did I miss?

Re-writing SMTP (e.g. IM2000). (and no, I'm not advocating that approach).

Matt.

---

From: [email-masked]
Date: Sun, 9 Mar 2003 23:05:35 -0800 (PST)

Could add the following into
a. ii. 3 ..
  Callback email address verification (i.e. verify email address is valid 
on calling server),as in Keith Moor's code or new postfix code

   Also actual callback pickup (not actually implemented but proposed couple
times, including in drafts) might require its own category or go also 
into "how was it sent" a. ii. 3.

   Also there several other not-implimented approaches (and you did include 
hashcash in your list, so I assume its ok) such as message tracking server
and similar ideas of having mail servers keep track of what emails came 
from it and receiving system being able to verify that (also similar to 
callback but verification is not just based on actual email address but 
both email address, messageid and date).

  And its unclear what category below it belongs to (or if it belongs among
"spam fighting" at all) is web pickup - i.e. only notification of email 
is sent and the actual email is hold at particular emailbox.

I'll think of some more staff if I go through my notes tomorrow.

Oh, almost forgot - I do not see simple catch-spam email accounts (which I 
use), i.e. special email accounts, not ever used for actual communication 
but advertised couple times on newsnet and embedded on website and 
anything coming into it is considered spam and email is then searches in 
your other accounts and same messages as in catch-spam removed. To be 
honest I actually use this simple approach and it works fairly well.

> get feedback on the taxonomy before dumping that on the list.
---
William Leibzon
Elan Communications Inc. 
[email-masked]

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 10 Mar 2003 15:07:10 +0100

Hi,

I'd like to propose a different structure for a taxonomy:

Based on the process of receiving a message and filtering out spam,
I'd like to use a model of (at least) 4 stages, where every stage
is seen as a simple question to an opaque (black box) oracle. The
taxonomy would be based on which of these four oracles the method
applies to and how it is implemented:

- First stage: We receive(d) a message, feed that message and all
  connection information to the first oracle and ask:
   
    "What do we know about the sender/origin/history of that message?"

  The oracle will tell us any information and whether this is 
  reliable. Example methods:

      * All we now is the sender address given in the header, 
        but not reliable (simplest case i.e. no implementation)

      * We know the sender identity reliable (e.g. e-mail was
        digitally signed)

      * We had a sender indentity which is doubtable (e.g. 
        digitial signature failed to verify)

      * We know that the sender's IP address was authorized
        so send by the domain's administration (RMX alike approach)

      * We know that the sender replied to a former message or
        successfully used some secret (cookie, challenge, nonce...)

- Second stage: We feed the message and the first oracle's answer to 
  the second oracle and ask:

    "Is that message spam?"

  The oracle will tell us "Yes", "No", "I have no idea", maybe a
  probability.

  Example methods:

      * All content analysis methods, pattern matchers, statistical 
        methods

      * Is Sender/Subject black- and whitelisted?

      * Do we accept forged/anonymous mail? What about messages with
        signatures that don't verify?

      * Has anyone else received a similar message? 

- Third stage: We feed the message and the answers of the first and 
  second oracle's answers to the third oracle and ask:

     "What do we do with that particular message?"

  Example methods:

      * accept, reject, drop

      * keep in memory, send a challenge, wait for reply

      * Add special header information

      * forward to a random e-mail address or the asrg mailing list

- Fourth stage: We feed the message and the former answers to 
  the fourth oracle and ask:

     "How do we react, what (c|sh)ould we do to prepare for future, to
      improve the first three oracles, to make the sender stop?"

  Examples

      * do nothing

      * black-/whitelist the sender

      * black-/whitelist the domain authority or certificate issuer

      * inform legal authorities/ISP/domain authority

      * let the spamfilter "learn" (when it's former answer was wrong)

      * add message to spam database

      * sue the sender or send him 10 copies of each linux kernel 
        developed so far

      * send the assassination squad to the sender

Every method discussed so far finds it's place somewhere in this
model. When we have put all proposed methods and principles into 
that model, we can discuss implementations.

Once we found which methods and implementations are desireable, 
we then can discuss whether they fit in today's SMTP or whether
we need a new transport protocol and how it should look like.

And it makes it easier to see that some proposals do not 
exclude each other or do not compete, since they are located
at different stages. They could complement each other.

Hadmut

---

From: wayne <[email-masked]>
Date: 10 Mar 2003 09:53:09 -0600

> the systems into spam prevention, spam deterrence, and spam reduction

Maybe it is just me, but these labels seem to be murky.  I had to read
the definitions to understand which systems belong in which category,
and even then, the labels didn't seem clear to me.

Hadmut has suggested another taxonomy based on "four oracles", which
seems a lot clearer to me.

I would like to suggest a third, based off of the natural progression
of email through the internet.

1) What things can the sender's MUA do to reduce sending spam?

   These are mostly things like "don't send vacation notices to
   mailing lists", and "make it obvious the difference between reply to
   one person, reply to the mailing list, and reply to everyone
   involved".

   A spammer, of course, will not be restrained by these checks.

2) What things can the sender's MTA do to reduce sending spam?

   These would include rate limiters, authenticating who can
   send/relay email through the MTA, content checking to see if the
   sender is sending spam, etc.  This can also include things like
   port 25 filtering to force the "sender's MTA" to be the ISP's MTA.

   At this point, it is much easier to track down who exactly is
   sending the email.  

   A spam friendly ISP will not restrain senders.

3) What can the receiver's MTA do before that SMTP DATA statement?

   This includes firewalling, blacklists, verification of HELO/EHLO,
   tempfailing, RMX/domain specific DNSBL checks, etc.

   Part of the goal here is to reduce network bandwidth.

4) What can the receiver's MTA do after the message has been received,
   but before it has been delivered?

   This includes header and body checks.  At this point, bounces can
   still be forced to be created by the sender's MTA, preventing
   bounces from being sent to another victim.  It also reduces the
   bandwidth used because a bounce message isn't sent.

5) What can the receiver's MTA do after the message has been
   accepted for delivery?

   While the options are pretty much the same as stage 4), the MTA has
   to generate a bounce.  

6) What can the receiver's MUA do?

   Some information that was available to the MTA is often lost by the
   time that the receiver's MUA can do checks.

   This is the only spot where the end users can give feed back to
   earlier parts of the system about false positives or false
   negatives.

One important aspect of anti-spam systems is error handling.  The
sooner that spam is detected, the better.  The choices of how to
handle errors are also different at each stage.  The earlier stages
know much more about the sender than the later stages.

Once the mail has been delivered by the receiver's MTA, you can't
generate a bounce.  Either you have to generate a reply email (which
can be made to look like a bounce), or you have to drop the email.  A
false positive may well give no feed back to the sender.

On the other hand, the later the stage, the more you know about how
the end users values false positives vs false negatives, so the more
aggressive you can make the checking.  The end user may receive email
from several different ISPs, so receiver's MUA has more complete
information about the type of email they receive.

Also, later stages may benefit from information learned elsewhere.  A
DCC check at the sender's MTA time (stage 2) may yield no hits while a
check at the receiver's MUA (stage 6) may have given spamtraps time to
react.

Hmmm... I guess that Hadmut's four oracles could be applied to each
stage. 

-wayne