Sabahattin Gucukoglu wrote: >> 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; I guess my point is that in almost any imagninable scenario, the server doing the tarpitting will be forced to yell "Uncle!" before the attackers being tarpitted even notice. >>> 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. [...] > 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. Spammers can increase their supply of spambots quite easily. > 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); You'd be AMAZED at how many people don't notice when their Windoze machine is balky/misbehaving/unresponsive. For many people, that's the normal state of affairs. :-) [...] > 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. You don't have a criminal mind. :-) Spam-sending engines can be *highly* optimized. They need not be multithreaded; they don't queue messages. A simple highly-efficient event-driven sender can probably occupy 5,000 SMTP servers without putting noticeable load on the client. Multiply that by tens of thousands of spambot machines, and you see the scale of the problem. > 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. If this list is archived anywhere, please read the exchange between Hector Santos and me. He wanted to use this idea to get an SMTP server to "force" (or at least "encourage") a client to wait longer than its normal timeout. I believe this will annoy legitimate SMTP clients enough that they'll find it worthwhile to code an overall timeout rather than a per-read timeout (as is commonly done now.) > 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. Yep. > 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. There is no way to "make" optimized ratware clients written and used by criminals to do anything either. Greylisting works because it ensures that spammers have to stick to the same IP address for a few minutes (or tens of minutes) to get their messages through. This gives RBLs a chance to catch up. It works because greylisting doesn't waste server resources and (if properly implemented) doesn't unduly inconvenience legitimate clients. This proposal *will* inconvenience legitimate clients. If AOL (for example) discovers that 1% of its outbound connections are being tarpitted, I'm darn sure they'll announce that they refuse to stand for it and simply won't deliver mail to would-be tarpitters. Regards, David.
