Subject: [Asrg] Taxonomy of anti-spam systems version 2

From: Paul Judge <[email-masked]>
Date: Tue, 18 Mar 2003 04:10:50 -0500

After more thought and feeedback from some people on the list, here is a
second draft of the taxonomy of anti-spam systems. 

The systems are classified into prevention, deterrence, and reaction
approaches.

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 vs. egress and MTA vs. MUA.

a)	Fail-Open (determine unwanted messages)
	i)	Human determination
		(1)	Collaborative filtering (i.e., razor) [SB]
	ii)	System Determination
		(1)	Who is it from? (Blacklists) [SB]
			(a)	Blacklists
			(b)	Reputation systems
		(2)	What's in it? (Content Filtering)
			(a)	Static lists [SB]	
			(b)	Learning methods [AD]
		(3)	How was it sent?
			(a)	Forged info? [AD] (i.e. reverse DNS, domain
lookup, verify email address 				on calling server,
verify message on sending server, reverse MX record)
			(b)	Envelope characteristics; delivery path
information [SB/AD]
			(c)	Quantity? [AD] (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		
	ii)	Challenge/Response systems
		(1)	Basic
		(2)	Human verification (i.e. turing tests)
	iii)	Consent Tokens (a priori consent)
		(1)	Proof-of-work (i.e. hashcash)
		(2)	Stamps
		(3)	Payment upon misbehavior 
			(a)	Confirmed payment (i.e. Bonded Sender,
Trusted Sender)
			(b)	Pursue payment (i.e.Habeas)
	iv)	Don't receive messages, just notification (i.e. IM2000)	

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 Reaction Approaches - These are the different approaches that
can be taken upon receipt of a spam message. 

	a)	Accept
	b)	Quarantine
	c)	Reject
	d)	Drop
	e)	Label
	f)	Charge
	g)	Challenge
	h)	Limit Rate
		i)	Ingress
		ii)	Egress
	i)	Feedback
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 18 Mar 2003 17:08:38 +0000

> The systems are classified into prevention, deterrence, and reaction

I wonder if it might be useful to separately attempt a classification of
message classification systems? Something like this (way incomplete):

1  Transport
    1.1 Source IP
    1.2 Rate
    1.3 Envelope (MAIL FROM)
    1.4 Bounce ratios
    1.5 ...

2. Content
    2.1 Header consideration
    2.2 Body consideration
    2.3 Composite content analysis 
    2.4 ...
    
3. Context
    3.1 Challenge/Response
    3.2 Consent Tokens
    3.3 ...

It might be convenient to describe anti-spam systems in terms of
the message classifications they employ, as well as the other
considerations you identify. Such a classification would be useful
in your taxonomy and elsewhere.

Maybe?

--

---

From: Hadmut Danisch <[email-masked]>
Date: Tue, 18 Mar 2003 09:34:28 -0800

> 		(1)	Collaborative filtering (i.e., razor) [SB]

Sorry, but I still don't agree with that hierarchie.

I don't think that Fail-Open/Fail-Close is a suitable criterion
of such a high level. That's just a low level property, not
a taxonomy criterion.

The taxonomy should distinguish methods by what they do and 
in what way they do not, not what happens if they fail.

This and the question of human/system determination are
properties of the particular implementation, not of the method
in principle. Therefore they should be kept out of the main taxonomy
hierarchie.

We should care about the main principles, not implementation details.

Hadmut

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 18 Mar 2003 13:07:54 -0500

> message classification systems? Something like this (way incomplete):

It would be very helpful to have a parallel taxonomy based on different 
criteria, like the one you've described.  In the _same_ document.

No need for a taxonomy document to be limited to only _one_ set of 
keying criteria.