ietf-smtp
[Top] [All Lists]

Re: Proposal: Using Conservative EHLO Response Parser Behaviour For Tarpitting

2007-06-18 17:49:34

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.

<Prev in Thread] Current Thread [Next in Thread>