Subject: RE: [Asrg] Taxonomy and List of Requirements

From: Paul Judge <[email-masked]>
Date: Fri, 4 Apr 2003 10:40:56 -0500

> 
> Are these done?  Was any form of agreement reached?
> 

Taxonomy draft 3. 3/20
http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01794.html

There was only one response to this message and it required no changes. So,
this draft is what we will move forward with.

Requirements draft 1. 3/19
http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01721.html

Russell Brand volunteered to take charge of the requirements doc. Eric D.
Williams is also working with him.

> Current attention here seems almost exclusively limited to 
> solutions based 
> on actions taken at the receiving system.  Was it ever 
> decided that such a 
> restriction was appropriate?

No. No restrictions have been decided upon. 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Spencer <[email-masked]>
Date: Fri, 04 Apr 2003 10:22:21 -0600

>this draft is what we will move forward with.

OK.  Open proxy & open relay honeypots don't even appear.  Broadly speaking 
there are two kinds of spam: direct spam and abuse-path spam.  Currently by 
far the larger problem is the abuse-path spam.  Many feel that many spam 
sources are waiting in the wings, hoping to be given some kind of license 
to send direct spam of a more targeted nature.  This would be the kind of 
spam the DMA, Microsoft, etc. favor.  Technical measures may not be 
adequate by themselves to keep such spam from multiplying.  I very much 
believe in the honeypot as a solution but I don't kid myself: that other 
is, in the long term, the greater threat.  Still, I'd like for honeypots to 
make a maximal contribution to the elimination of abuse spam.

>Williams is also working with him.

Could the language be made more precise?  Some things may be absolute 
requirements, others may indicate desirability.

For honeypots, for example, is it a privacy problem that honeypot operators 
end up with big lists of email addresses from the trapped spam?  Otherwise 
I think honeypots score pretty highly with regard to the requirements. For 
requirement 9 there surely is  the likelihood that spammers will be able to 
detect honeypots with some degree of success once honeypots become 
prevalent enough to be of concern to the spammers.  The goal (as I see it) 
for a honeypot operator is to so perfectly mimic a vulnerable system that 
the spammer can't tell the difference.  That means countermeasures to 
whatever the spammers try, when they try it.  Slightly less stringent would 
be a goal of making it so expensive to the spammer to distinguish honeypots 
from true vulnerable systems that the spammer is in despair.  In any case I 
find it very hard to imagine a successful spammer countermeasure to what I 
now do: simply trap relay tests.  The best the  spammer can do is to never 
test that IP again.  If you control several IP's in a range the best the 
spammer can do is never test that range again ("never test" implies "never 
abuse.")  That, to me, is good enough to be worthwhile.

>No. No restrictions have been decided upon.

Nonetheless the impression I get is that all the emphasis is on that one 
type of solution.  Abuse is  a key component of current spam, relay tests 
are vital to current spam.  Neither is clear to me in the  taxonomy - it's 
like they are so unimportant they deserve no mention.  Blacklists can be 
said to apply to abuse spam (open relay and open proxy dnsbl's) but then 
we're back to what I said: actions at the receiving end only.  It's natural 
for those who experience the problem at the receiving end to put their 
emphasis there.  So far that's been inadequate - I favor having a taxonomy 
that examines the entire spam cycle, from discovery of email addresses to 
receipt of payment.  It may be that the solution is a combination of 
techniques.  I favor hitting spam at every level.  Three successive 90% 
solutions give a combined 99.9% solution, and so on.

Sorry to be so late with these comments.

Thanks.