> >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.