Tom> You know, I am not so sure you ought to go slowing down your Tom> responses to these attacks. It won't really affect the sending Tom> sites, since they are done automatically and there is no one to get Tom> bored or irritated by the slowness. But it will slow down your own Tom> machine by tying up one or more threads. Tom> Why not just send a 403 response ("Forbidden") and walk through the Tom> attacking sequence as fast as possible and be done with it? The rationale in the SMTP world goes like this: The bad guys have to send out a certain number of messages to get the ROI they need. If you keep them from being able to send enough messages, it will become nonprofitable and they'll go find some other way to make money. In this arena I think the argument is similar. Sure, there's nobody hanging around to get bored. Still, if it takes a script kiddie three or four days to find a vulnerable site instead of three or four hours, perhaps he'll give up and go do his history homework for a change. Tom> As I recall from some of my testing on these attacks, if you give Tom> any response that seems like a return, they go through their entire Tom> repertoire. A 403 still elicits part of the standard bag of Tom> tricks, but less of it, IIRC. 403 was, I thought at the time, the Tom> best response in terms of minimizing the number of requests in one Tom> of these attack sequences. I'm looking at it more as a way for the community to band together to fight the problem instead of simply deterring people from attacking my site in particular. If I can slow them down here, they'll be able to attack fewer sites overall. The best place for this to happen is in Apache, because it has the largest share of the server market. Skip