[eoc_Jason]

If those numbers are right, and based on my log file, they certainly seem to be, how can that 30 minute local cache be blocking very many bots?

Let me try to explain it from how I've looked over the code.

The main need for the local cache is because of where the hook location is in the registration code. Pretend a person (or bot) messes up their registration and the system throws an error (say they messed up the CAPTCHA, or forgot to fill out a required field). The hook to check SFS occurs after every "submit" is hit on the registration page, but before vB error checking and final user saving is done. Thus if a bot is pounding the registration with failed attempts it would in turn be pounding SFS with the same query over and over again. The local cache alleviates this problem since the Username/Email/IP should be the same through several attempts to get a successful registration.

I think it would be okay to cache the definite hits for the long-term, but usually after failing in that one short time-span, you won't see the same user/email/ip combo again. (especially if you already banned the user, which would also prevent the same email address from being used). And if it's a dynamic IP, eventually a legitimate user *could* get blocked because you cached results for several weeks (or are not checking how recent the last bot was seen).

But anyhow, I think having a short local cache is more than sufficient. I've seen bots pound the registration with failed attempts, but still the local cache is not allways effective since they sometimes will try different usernames/emails/IPs when the previous attempt is not successful. Fortunately for me there's tell-tale signs of being a bot (i.e. 10 registration attempts in one second) which gets them submitted to SFS. Also I have other checking that I do before querying SFS to tell if they are a bot, that helps Pedigree out in reducing load on his server.