At 10:40 AM 4/4/2003 -0500, you wrote:
>
> 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.
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.
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.
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.
> 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.
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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg