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