[Asrg] Tarpitting

[Chris Lewis]

Alessandro Vesely wrote:

> Thus, you are suggesting that drop, which can be considered a poor man's 
> tarpit, wrt reject can be more effective. Or is the reason (short 
> timeout bots give up) rooted in the fact that tarpitting exists?

Rooted in the fact that attempting to "negotiate" thru slow delivery is 
not in the best interests of increasing the sheer quantity of 
deliveries, whether it be tarpitting, banner delays, or just slow MTAs.

If most (or the big) receivers started deliberately slowing delivery 
then the spammers would have to change tactics again.

>> Dropping 'em at the router is difficult, because routers (at present) 
>> can't be configured to hold all the IPs you'd like it to, and can only 
>> be used very selectively.
> 
> (Using a Linux box may overcome that limit)

It may, and at first glance, it might seem no worse than letting the MTA 
do the queries and rejects at connect, but consider:

- the temptation, of course, is to apply the technology for more than 
just port 25.  This could cause some serious performance problems if the 
subnet (behind the router) doing this is does more than just inbound 
email - like web traffic or DNS.  Secondly, not all DNSBLs should be 
used this way.  Eg: PBL or CBL/XBL.

- timing requirements are a lot more stringent at router level.  A query 
delay that might be more than reasonable for SMTP level could cause 
legitimate connections to fail at the TCP/IP level.

If the linux box doing the router-level stuff is co-resident with the 
MX, it could be quite tractable.  On the other hand, getting, say, IPF 
to do it might be more than a minor challenge.

[I think spamd effectively does this to a certain extent, but I've not 
researched it very well.]

It'd be well to consider why Spamhaus DROP is so small.  Not only are 
there size constraints, but also the difficulty in distinguishing ranges 
that are so bad you want to drop _everything_, not just SMTP.