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

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

> 1.	Spam Prevention Approaches -  These systems aim to prevent the
> spread of spam messages. There are fail-open and fail-closed systems.

With my spokeperson hat on I prefer the terms 'Detect Wanted' and
'Detect Junk'. I am not going to use any term that involves the
word 'fail' with a journalist when talking about my work or
company products.

I think the terms I propose are also easier to communicate.

> 2)	Spam Deterrence Approaches - These systems aim to deter spamming

> 	a)	Authentication
> 	b)	Tracking
> 	c)	Non-repudiation

I place Authentication based approaches with other 'Detect Wanted' schemes.
Authentication plus some form of authorization gives access control.

I think that legal/legislative approaches should rank a bullet here. We
should also mention vigilante actions such as teergrubbing and hackback, I
don't approve of these, they create far more problems than people claim.

> 3)	Spam Reduction - These systems aim to reduce the level 
> of spam by
> making it more costly or timely to have the messages delivered.

Actually this is the objective of all security based approaches. The point
of security is risk reduction, not risk elimination. Unusually for an
Internet application we have an actual economic model here where the
attacker is actually a somewhat rational actor so cost approaches can bite.

> 	a)	Cost-based Systems (increase cost of spamming)

I think the term CHARGE-BASED is better than cost based. 

> 	b)	Proof-of-work (i.e. hashcash)
> 	c)	Rate limiting
> 		i)	Ingress
> 		ii)	egress
> 
> 
> 
> I'm not fully comfortable with the spam reduction being a 
> third category,

I think that it is actualy a branch of the Detect Wanted chain, the proof of
work or charge is simply a form of authorization.

The detect wanted should thus split into two branches with an authorization
and authentication component, you need to use one mechanism from both to
address the whole.

Another issue to address is spam sender countermeasures and the
counter-counter-measures to defeat those. In particular I am interested in
schemes where there is an asymmetric work factor, preferably one that means
that it is more difficult for the spam sender to catch up than for the good
guys to counter.

I would also like to suggest that we consider deployment strategy
explicitly. I believe that the standard MUA setup will look something like
(ignoring subject folders for a moment):

Inbox
	Known Good
	Not Sure
	Known Junk

I do not see the Detect Wanted and Detect Junk strategies being in
opposition. Until people use authentication mechanisms that allow a large
fraction of mail to be Known Good most mail is going to be in Not Sure or
Known Junk.

However it is quite an easy matter to at least achieve 'known good' status
for internal mail which in any large or medium sized enterprise is the vast
bulk for most people. If we design the strategy carefully we can achieve
some viral uptake.

Another area where is is comparatively easy to achieve a rough and ready
known good status is on mailing lists. Although spam senders do sometimes
subscribe to send junk this is relatively rare. Most mailing lists are
already applying a lightweight authentication mechanism of their own -
restricting posting to list members. 

		Phill
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Mar 2003 11:20:51 -0700 (MST)

> From: "Hallam-Baker, Phillip" <[email-masked]>

> ...

That's almost but quite right.  Besides using the forbidden word "fail,"
I needed a few seconds to understand "fail open/closed."
"Detect Wanted" is ok, but "Detect Junk" is not for the same reason that
"fail something" is not.  "Detect Unwanted" would be better.

Personally, think "reject by default" and "accept by default"
are better still.

> ...

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.  

Yes, not withstanding my recent claim that other spammers want to hear
5yz-no-such-user responses so that they can clean their target lists
to avoid AOL's filters.  There are currently on a few spammers, but
they are incredibly diverse.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 10 Mar 2003 15:04:11 -0500 (EST)

> post its banner.  Whether the STMP server delays 10 ms or 10 hours is

Yes, but some spammers do not control the relevant MTA, as for example if
it is an open relay. Teergrubing must have very strong incentive effects
on open relays if it becomes reasonably widespread. And this incentive
applies even if the relay has no legitimate mail to transfer to the
victim.

Daniel Feenberg

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Mar 2003 13:32:31 -0700 (MST)

> From: Daniel Feenberg <[email-masked]>

> ....

I'm sorry but that's standard anti-spammer self-contradictory wishful
thinking.  Open relays are ill maintained machines.  Well maintained
machines don't need any incentives from teergrubers to be fixed after
being attacked by spammers as open relays.  Badly maintained machines
don't have anyone who might notice the effects of teergrubing.

The biggest reason that teergrubing is silly is that there always have
been and always will be more unintentional teergrubing machines than
can ever be installed intentionally.  Anyone who runs a non-trivial
bulk mail operation such as a mailing list knows too well that a
significant fraction of legitimate SMTP servers stall for longer than
typically recommended teergrubing durations.  It doesn't matter whether
they stall because the 3 or more DNS lookups required by an SMTP server
to receive a message can teach take 90 seconds or a total of more than
5 minutes, because some spam filters need 5 minutes to get an answer,
or the many other reasons that can stall STMP.  Whatever the reason,
they look the same to all bulk mailers as the trivial number of
intentional teergrubers.  That's why all useful MTA client code has
timeouts to defeat teergrubers.

---

From: Anthony Howe <[email-masked]>
Date: Tue, 11 Mar 2003 10:28:54 +0100

> word 'fail' with a journalist when talking about my work or

I like these terms, they are far more clear and don't carry any 
negative conitations.

> should also mention vigilante actions such as teergrubbing and hackback, I

I've not heard these terms before

	"teergrubbing"
	"hackback"

Maybe part of this  should create a "glossary" web page, because some 
people like myself might not be "au courant" and since you are already 
talking about journalists, will find it useful if some terms and 
concepts are predefined (or in the course of being defined).

I've found that alot of the arguments being carried on in other 
threads revolve around semantics and meaning and really start to grow 
tiring after so many posts.  I can't believe that it takes people so 
long to actually come to some concensis on what SPAM is and what to 
call / classify the assorted abuses of SMTP, RFC 2822, MIME, and the 
like, let alone even start coming up with ideas, data gathering, 
experiments, and maybe even some possible solutions.

I think the choice of words and their semantics are important, but I 
also think that they shouldn't be the focus of overlong continued 
discussions, which is why I'd think some sort of open community 
glossary might be a better place to define and isolate such long term 
discussions of this nature.

-- 
Anthony C Howe                            +33 6 11 89 73 78
http://www.snert.com/     ICQ: 7116561      AIM: Sir Wumpus
"Will the real email please stand up..."

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 11 Mar 2003 13:59:50 -0700 (MST)

> From: Anthony Howe <[email-masked]>

> I've not heard these terms before

Ignore the fact that normal SMTP servers often spend many minutes
accepting incoming mail because of DNS lookups, spam filtering, and
other slow processes, assume that spamware does not have short timeouts
to deal with slow SMTP servers, and slow down your SMTP server by a
few minutes in the foolish hope of hurting spammers.

Well, those are not exactly the words you'll find on the net
in pages like http://info.astrian.net/jargon/terms/t/teergrube.html

> 	"hackback"

As far as I can tell from poking around search engines, that means what
it sounds like, generally illegal retaliatory "hacking" or "cracking."