Hi Lisa, David and others,
On 18 Jun 2007 at 10:47, Lisa Dusseault <lisa(_at_)osafoundation(_dot_)org>
said:
On Jun 18, 2007, at 5:41 AM, David F. Skoll wrote:
1) Tarpitting occupies server resources, making it easier to DoS the
server.
It certainly does. It depends on which position you take as to whether or
not this is a problem any more than it is already, though; someone
connecting to a server and simply keeping the connection alive with NOOPs
or equivalent commands can achieve the same thing if the servers limits
are within easy reach of the client and/or the implementation lends itself
to DoS (fork vs events, etc). The administrator of the server is
obviously responsible for making the compromise of tarpitting performance
over immediate mail deliverability (if you use greylisting, you're already
less concerned about the latter).
The only thing I can think of right now that would make DoS noticeably
easier is that it now only takes a spammer to somehow entice other
machines to send mail to a tarpitting host in order to increase the chance
of DoS at the tarpit (either crashed host due to misconfiguration or
delayed mail due to limits being exceeded). The server should obviously
avoid taking multiple connections from any given IP to cut off the most
obvious line of attack if that's necessary. Finally, the problem is only
there if hosts are sending mail under an attacker's control. Maybe
bounces sent by mailers that accept mail before noting delivery problems
(like qmail) will be an issue here. Otherwise, the mass source of
addresses that connect under spammer control is essentially the spambots,
and those are the very machines you want to hold up for as long as they're
willing to wait. Also, every host that passes mustard gets whitelisted,
so there's a maximum time that the mailer can spend tending to a
connection.
2) Tarpitting is useless against an attacker with essentially infinite
CPU and bandwidth resources --- and that's the kind of attacker a
serious spammer is.
I'm aware this is no simple adversary. (Deploy a dummy SMTP service that
accepts all commands except RCPT which causes the connection to be closed,
give it an MX, then spread addresses routable to it. Then just watch what
happens. You'll just see each rejection followed by yet another host
willing to try. Fun, but be careful.) If most spam gets sent to a host
using this scheme, then most spambots are waiting to deliver mail. Unless
spammers exponentially increase their supply of spambots, though, spammers
will soon hit the impass at the current rate of spambot deployment where
the number of bots available will simply not be able to get current
throughput without skipping recipients. They will have to assign more
threads/processes to each machine to process the deliveries, which would
endanger the client host system (to presumably noticeable levels); they
would slow down if they did things sequentially, and the timeouts unique
to each host make it impossible for a spammer to plan ahead of time which
hosts he will target for a full delivery (like greylisting, except that
this can be defeated by simply running a blast twice, for instance). That
assumes spammers adapt, of course; if they don't (or while they don't)
you'll presumably enjoy a niche privilege. But the load has to be
distributed among a finite number of spambots in the end, and if that
means we can put greater demand on each host while it is doing absolutely
nothing but reading continuation lines from, I don't know, 50 different
smarthosts it is planning to slam, then all the better.
3) Relying on "genuine" clients to adhere strictly to RFC-defined
timeouts
is dangerous.
The five minute timeout is the minimum required, so it would be the
foreign host in violation. A zealot wouldn't care, but I would. This
idea doesn't use that timeout, though; it sends continuation lines
periodically at short intervals that all hosts are practically guaranteed
to tolerate. My real worry is that a client might close the connection
before being sent the final line in a sequence; that's obviously a serious
problem for this idea.
4) It is perfectly possible to delay the client before EHLO.
That's what
Sendmail's greet_pause feature does. However, it's *not* designed to be
Please go back and read my original message again. I think you missed the
point. Pausing at the greeting is not an option because there is no way
to make the client hold the line at that stage for longer than it wants
to. Force-feeding lines to a client which it must read the whole time
you're doing it without daring to say anything, though, is enough either
to waste a spammer's time or make it lose patience and incriminate itself
(either by saying something after what it presumably thinks is a complete
response or by dropping the connection). In the former case, multiple
implementations of the tarpit endanger more bots, and in the latter you
get less spam! That's the goal.
a tarpitting mechanism. Rather, it's designed to detect SMTP clients
that send everything in one burst without waiting for the initial
greeting (and also to detect clients that use broken proxy servers.)
That's true, although a lot of people reported setting quite insane values
for greet_pause like a full two minutes, since a lot of spambots will
indeed have lost interest by then. Unfortunately, as you remarked, a few
clients won't use the timeouts given in RFC 2821 and will also have quit
before then, too. I'm not sure whether HTTP proxies are in fashion
anymore; I never see them more often than about twice a month on my
personal machine compared to the 3000+ aborted attempts. (But once again:
this is not the way this proposal functions.)
adding:
5) If this were standardized or even widespread, spammers would adapt
easily (much easier than the good actors can change). It can only be
useful as a trick that a few systems use.
I agree with all except the last sentence in the long-term, all otherwise.
Having deployment is part of the master plan (You can tell I've got a
real gripe against spammers, can't you? :-) ), but not having more than a
few is as likely to bring benefits like those of greylisting to those who
want it while helping to slow down the existing spam-sending client
population if they choose to wait. If they don't, you've essentially got
a safer greet_pause function.
I'm going to put this on the back burner for a while because I'll
obviously have to test it for myself, and that'll require some coding for
which I don't yet have the time (probably start with a proxy). I'd be
interested in any further comments, though. The *main* point here is not
so much the exact specification of an extension (the extension is only
there so that we can send multiple, delayed lines in response to
EHLO/HELO), but that client behaviour is, to the best knowledge of people
here, sufficiently good in all truely robust client implementations to
support this slight abuse of the characteristics of a linear protocol like
SMTP with continuation lines.
Cheers,
Sabahattin
--
Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com>
Address harvesters, snag this: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399