I would prefer to avoid the term 'oracle' which has a very particular place
in cryptographic research as a term of art.
I think Hadmut's four stage model is usefull, however I would prefer to
avoid getting too far into implementation issues when setting out the
taxonomy of approaches. Hadmut's taxonomy is a taxonomy of applications,
which is slightly different.
Phill
-----Original Message-----
From: wayne [mailto:wayne(_at_)midwestcs(_dot_)com]
Sent: Monday, March 10, 2003 10:53 AM
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] Taxonomy of anti-spam systems
In
<B1F08F445F370846AB7BEE424365F00DB2EB6E(_at_)ctxchg(_dot_)ciphertrust(_dot_)com
Paul Judge <paul(_dot_)judge(_at_)ciphertrust(_dot_)com> writes:
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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg