Hi Lisa, David and others, On 18 Jun 2007 at 10:47, Lisa Dusseault <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Phone: +44 20 88008915 Mobile: +44 7986 053399
