On Saturday 22 May 2004 18:40, Seth Goodman wrote:
Theo Schlossnagle:
Then again, MTAs are beginning to support high SMTP concurrency (like
>100,000 concurrent connections). So, the techniques are becoming more
suitable for "in session" deployment. That's what we do here. The
beauty of doing in-session tarpitting within the MTA is that you can
make them pay a serious, but *finite* cost. If you think they are a
spammer, just make them spend 60 or so seconds in every SMTP phase.
Think of it like the HASHCASH proposals, just with time instead of
computation.
I guess I don't understand why this doesn't work both ways. If the
white-hat MTA's can support 100K simultaneous connections, it seems that so
can the black-hat MTA's. If it is not a significant burden to a white-hat
MTA to tie up a socket for five minutes, why should it be a problem for a
black-hat MTA?
Because the spamming MTA's in these cases are typically home machines with
cable/DSL connections that have been infected by some trojan and are now
taking part in a DSPAM operation. As such they have limited upstream
bandwidth (typically 10% of their downstream bandwidth - 128k or less) and
they are trying to use minimal resources (threads, CPU, RAM etc.) on an
infected machine in order to avoid drawing attention to themselves, so will
often limit the number of threads they'll spawn at once (or be single
threaded). And if they're running W98 or XP Home or something similar, there
may well be hard limits on the number of concurrent sockets they can have
open at once.
Tarpitting is, as Theo pointed out, all about the economics of spamming, the
idea is to make the sender's operation more expensive.
Regards
--
Tim