[Top] [All Lists]

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

2007-06-19 10:33:29

Hi David,

On 18 Jun 2007 at 20:33, David F. Skoll <dfs(_at_)roaringpenguin(_dot_)com> 

Sabahattin Gucukoglu wrote:

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. :-)

Aye, you've got a point there. :-)


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

Yes, I'd actually intended on doing a lot of operations in my MTA using 
nothing but pure events (only disk I/O may block, so that's the only thing 
you need workers around for).  (I must be a spammer. :-) )  But putting 
that aside, aren't you giving these spammers quite a bit of credit for 
brains and familiarity with these swish programming ideas?  We have seen 
better spam-sending behaviour in company-developed hardware than in 
ratware (think Ironport).  Now, don't get me wrong - I'm not asking to be 
DoSed (please :-) ).  However, there are more factors to spam delivery 
that make a lot of the efficiencies they used to take advantage of in open 
relay days back then an impossibility now.  Personalised mails, for 
instance, to get around hash-based detection or pull off social 
engineering stunts.  Or word salad and unique headers or EURIs, to get 
around bayes filtering and net-based queries.  (If you can keep your food 
in your stomach, find the documentation for one of these pieces of 
slimeware.)  And the hardcoded fd limits in most personal OSs that no end-
user could ever tweak by himself and which probably isn't as easy as a 
single system call for a spambot to do.

Of course, if you're a spam king with some common sense, you'd want your 
mail sent from a Unix machine where the program you described would be 
running a hardcore job.  Then again, you'd just note that Postfix was very 
fast on such an OS at that, and use that instead.  And every now and then, 
I can actually confirm this happening (qmail's another popular one).

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.

No, there isn't, but the objective is to make those who are willing to 
wait, wait (including spammers that take the bate).  Normally, clients 
that give up before the RFC-defined timeout are a problem, which is why 
greet_pause has limited usefulness.  So this is a greylisting replacement 
and/or a glorified greet_pause option.

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.

(Putting aside the fact that AOL already has quite an attitude for doing 
things their way and no other ...)  The proposal suggests a very short 
tarpitting time; the objective is to hang on to the address that's calling 
so that the delivery doesn't have to be delayed any further than the 
initial tarpitting time per cycle, because otherwise the mail may arrive 
on another address and be delayed further.  Tarpitting is not the primary 
objective, we simply don't want the client to drop off before a given 
amount of time as it might otherwise be tempted to do.  Five minutes a 
month to any given organizations' smarthosts isn't going to bankrupt any 
reasonable site, no matter how disperse the mail.  Greylisting, while it 
may not take up resources, will suffer from the address problem (the 
resolutions either require administrative help, RBLs or diminished 
effectiveness, but I take your points about the implementation) and, for 
those MTAs which don't prefer to queue mail unless they have to (like Exim 
3, not sure about 4.5), *is* an inconvenience.  Perhaps it's a matter of 
perspective, or maybe I just wish more people would run their own MTA.  
But so long as your mailer were sufficiently robust, it probably wouldn't 
actually notice any given delivery being tarpitted briefly and the 
likelihood of its being simultaneously tarpitted by enough destination 
sites as to cause it ill-health is probably quite small (and, in any 
event, something the client should not be trying to do anyway).


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

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