RE: [Asrg] Taxonomy (Four oracles model)

[Paul Judge <paul.judge@ciphertrust.com>]

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:hadmut@danisch.de] 
> Sent: Monday, March 10, 2003 9:07 AM
> To: Paul Judge
> Cc: 'Asrg (asrg@ietf.org)'
> 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
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg