From: Eric Brunner-Williams in Portland Maine <brunner(_at_)nic-naa(_dot_)net>
Yakov,
Escuse my brevity.
No problem.
> >I'm still where Berry left off. I don't see anything in humans, or pseudo
> >humans, headers and eventual administrative DoS that solves for "virally
> >acquired spam slave servers".
>
> Lets analyze where spam comes from. From experience I have seen the
> following sources:
There is a taxonomy, most of which I've characterized as "slow", and then
there is
Do you mean "slow" as spammers who are "losing their skill" and are not
agile enough? However, there are still plenty of those around and we need
to stop them just as much as the "fast" spammers.
... spammers using slave servers.
> Based on this, I will have to agree with you that spoofing or solving
> spoofing will not solve the spam problem. It seems that we have to look at
> the spam problem as a subset of a larger problem of how to prevent a
> network user from abusing the network resources, in this cases being the
> bandwidth.
Hold that thought. It's not unqualified bandwidth. Not only is it SMTP,
but it has some immediacy property that is distinct from say, 3rd-party
persistent cookies and their replay times to namespaces dynamically
managed by technically capable advertizing networks, and it must possess
some additional properties.
> very easy and cheap for any network user to utilize the network resources.
> Thus the solution is to make it expensive or restrict the user ...
Hold that thought too. There is no user. His or her wintel box on a cdn
or dsl circuit is _yours_. You simply need to match your acquisition and
loss budgets, while working your delivery problem.
I was looking at the overall spam problem as follows: we have a network -
the Internet, users - humans using it, and resources - bandwidth, servers,
computers. The question is how to stop a user from abusing the network
resources, namely our DLS customer. It does not make a different whether it
is our DSL user who is actually sending the spam or the hacker that gained
access to his computer. If we have proper safeguards on place, then we
prevent both.
> The only thing that will help in these instances is either putting a
> sending limit on the user, or using some kind of a secure operating system
> which (in theory) makes it impossible to monitor local SMTP traffic. No
Hold that thought too. Is a node that transits from "nothingness" to "being"
indetectible?
As you stated, the most we can do is trace it to the unfortunate DSL user
whose computer was hacked. The node is detectable but can we do anything
about it aside from limiting the legitimate user's email?
---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research(_at_)solidmatrix(_dot_)com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg