Subject: RE: [Asrg] Taxonomy of anti-spam systems

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Mar 2003 08:10:31 -0800

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:[email-masked]]
> Sent: Monday, March 10, 2003 10:53 AM
> Cc: [email-masked]
> Subject: Re: [Asrg] Taxonomy of anti-spam systems
> 
> 
> In 
> <[email-masked]
> > Paul Judge <[email-masked]> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 10 Mar 2003 11:41:11 -0800

> Teergrubbing sounds silly to people who know that some spamware uses
> illegal SMTP command pipelining.  Some spammers send send the entire
> client SMTP transaction including the ending TCP FIN before the STMP
> server has finished doing the reverse DNS lookup to decide whether to
> post its banner.  Whether the STMP server delays 10 ms or 10 hours is
> of no concern to them.  

Ah but you don't understand, 182% of spam is sent through open relays.
So the teergrubbing encourages people to close the open relays - NOT.

The teergrubbing idea sounds to me to be clueless, particularly if let
loose on the general population where we will see folk using it on the
most flimsy of pretexts.

There are people who are aggressively pushing these ideas and we should
address them for that reason alone, even if it is highly unlikely we 
would ever endorse them.

I don't think that any of the bulk sender stuff would be caught by 
teergrubbing, they must have checks in there to stop them being held up
by slow sites. Heck you have that in most mailing list software.

		Phill