Subject: RE: [Asrg] Taxonomy (Four oracles model)

From: Paul Judge <[email-masked]>
Date: Mon, 10 Mar 2003 09:41:29 -0500

While at first glance, this model sounds interesting, I don't believe that
it offers enough structure to allow us to compare anti-spam systems. For
example the second stage of your taxonomy asks "is this message spam?". I
believe that is a broad bucket and would include the 20 or so subclasses
presented in the spam prevention section of my taxonomy. Therefore, I don't
see the value of this broad bucket. Also, the first stage of your taxonomy
is covered in 1.a.ii.1 and 1.a.ii.3 of the original taxonomy. 

Also, the last two stages of your taxonomy do not deal with spam
identification, but spam response once spam has been identified. Usually,
when I think about anti-spam systems, I think that there is an
identification component and a response component that deals with that
particular message and might perform some passive or even active response.

So, I would not move to this four stage model because the first two stages
are too broad and do not provide any real classification. However, I will
use this note as a reminder that we should also provide a classification of
spam response systems. I will follow-up with an outline of such. I would use
what you have sent, but it only lists examples and does not classify them.

Paul

> -----Original Message-----
> From: Hadmut Danisch [mailto:[email-masked]] 
> Sent: Monday, March 10, 2003 9:07 AM
> To: Paul Judge
> Cc: 'Asrg ([email-masked])'
> Subject: Re: [Asrg] Taxonomy (Four oracles model)
> 
> 
> 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
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 10 Mar 2003 16:22:52 +0100

On Mon, Mar 10, 2003 at 09:41:29AM -0500, Paul Judge wrote:
> example the second stage of your taxonomy asks "is this message
> spam?".

I've put that question not at the top of the taxonomy but in 
one of several stages intentionally. Several methods were discussed 
which don't focus on "Is it spam?" and objections were made because of
that. Therefore I came to the conclusion that there should be a layer
above that question and to invent additional steps in the process to 
cover those methods. 

> what you have sent, but it only lists examples and does not classify them.

Of course, I didn't want to go too deep into a taxonomy in the very
first proposal. I have several layers below that four stages in mind, 
but that would have been to much for the first proposal and would
require further discussion.

It is true that my proposal yet lists only examples, that's why I
called them "examples". The next step would be to build the 
subclassification in order to build a taxonomy tree. 

The reason to propose a different structure was that I see several
shortcomings in the original taxonomy design:

- Fail-Open/Fail-Close should not be a top-level to Prevention
  Approaches. That's the wrong level. That's a question of
  response or implementation, but not a top level principle of 
  prevention.

- The question who/what/how are much more important and should 
  be on a higher level than at the fourth level.

- The distinction of Human/System Determination is to be put
  on a lower level, because it is not a principle but an
  implementation detail in my eyes.

- Authentication is not a form of Deterrence. That's just wrong.
  
  Threaten spammers with a law-suit after successful authentication
  is, but not the authentication itself. Authentication is a 
  method to answer "who sent?"

- Same with tracking

- Non-repudiation is a special form of authentication. 
  Methods like non-repudiation and zero-knowledge-methods are
  subclasses of authentication.

- Spam reduction is a little bit difficult to handle. 

  From a theoretical point of view this is an esoterik method
  of authentication: Split all possible senders into two groups:
  Those who are so interested in sending me that particular message
  that they'd even would pay to do so, and those who don't. 

  The sender is required to authenticate to belong to the first group.

  Implementations: 

  - Real cash (e.g. any kind of e-commerce/microcash: Sell a real
    ticket which allows to send a message)

  - Pseudo cash (e.g. hashcash)

  In my model, those methods would be subclasses of the first
  oracle.

  You said you're uncomfortable with the placement of spam reduction
  in your model. Maybe that shows that the model is not fully correct.

Hadmut

---

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

Just to give an idea about how I'd subclass the second stage
("Is this message spam?"):

- sender rating

     - sender black/whitelisting
     - RMX results (possibly with black/whitelisting)
     - signature verification result (possibly with black/whitelisting)
     - has sender been authenticated?
     - does the sender's MX accept messages sent to this
       address?

- context analysis

     - is this message somehow related to earlier
       traffic with the other party? (e.g. is a 
       direct reply, did we discuss similar contents
       with that particular party earlier?)

     - did the message contain a valid cookie?

- mass mail detection

     - Try to determine whether other recipients received
       the same mail, e.g. ask databases, hash value methods

- content analysis

     - statistical methods
     - patterns
     - blacklisted words ("penis enlargement devices", "money transfer 
       from africa")
     - size constraints

- meta rules

     combine results of other methods
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg