On Sun, Jan 04, 2009 at 11:15:19AM -0600, J.A. Terranson wrote:
> I realise I may well be just another "stupid newbie" in your eyes, so
> please explain why something that can enforce a fixed amount of work to
> each and every transaction on the SENDER's side is a bad idea by itself.
I've covered this in detail elsewhere, and it's not really appropriate
for this list, so I'll be brief. I suggest those interested in such
schemes peruse the archives of various spam-related mailing lists
and newsgroups.
Hashcash is an attempt to drown people who own the ocean. Spammers
control, in the aggregate, several orders of magnitude more computing
horsepower than anyone else. (And could, if they deemed it desirable
or necessary, increase that computing pool even further.) I'm talking,
of course, about the ~10e8 hijacked systems out there ("zombies") and
will note in passing that this is an order-of-magnitude estimate: based
on my research as well as that of others, I wouldn't be surprised if
the actual number was in the 2x10e8 to 4x10e8 range. [1]
The activities that these systems are currently engaged in (sending spam,
hosting DNS for spamvertised web sites, hosting spamvertised web sites,
harvesting email addresses, conducting DoS attacks, etc.) consume only
a small fraction of their available computing capacity -- that is, the
overwhelming majority is left over. There is plenty left to maintain
the illusion for their former owners [2] that they actually still control
these systems -- and there is certainly plenty left to deal with any
additional computational burden imposed on an SMTP transaction.
Note as well that each time the former owners of these systems
upgrade them, their new owners acquire a free performance increase.
Similarly, when they replace them, the same poor computing practices
(e.g., use of inferior operating systems, careless downloading,
missing or incorrect firewall configuration, etc.) that led to the
compromise of the old system quite often lead to compromise of
the new one, once again resulting in a free performance increase
for the new -- that is, the real -- owners.
Thus we see that imposing such a requirement will not impede spammers
in the slightest -- while it *will* impede nearly everyone else.
Note as well that in the several years since it first became clear that
spammers (and other abusers) had acquired these resources, no reasons have
surfaced to indicate that the problem is getting or will get any better.
On the contrary, there is every reason to believe that the problem is
getting steadily worse. [3] Spammers/abusers now control an
essentially-unbounded pool of computing resources -- not just CPU,
but memory, disk, bandwidth, etc.
So all that hashcash and other similar schemes would do is
burn a lot of CPU in a lot of places...for absolutely nothing.
---Rsk
[1] Note that the actual number is not only unknown, but unknowable,
since a system which provides no externally-visible evidence of its
hijacked state will not be detected. Neither will a system which does
provide such evidence, but does not provide it to a suitable detector.
Note as well that there is substantial evidence which suggests that
hijackers have long since learned to hold many systems in reserve
against the possibility that some are lost to them; clearly, this is
a basic strategic concept well within their grasp, so it would be
surprising if they *didn't*.
[2] If someone else can run arbitrary code of their choice
on your system, it's not YOUR system any more.
[3] It's not necessary to take my or anyone else's word for this.
Anyone running a mail server can acquire their own sample by using
passive OS fingerprinting, rDNS lookups, and spam logging in combination.
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
