Hi Kevin, Thanks for answering quickly. What a pleasant surprise.

Now what I mean with when the spambots have learned to deal with that is that after a while I am pretty certain spambots will become aware of how they are prevented from registering and start delaying.

From what I was able to see there is no where the time the bot took. I have set it currently to post to forum, which is great as it publishes the spamming email addresses, and exposes them to email harvesters LOL. I thought I saw something about a log file but I was unable to find where that goes. It certainly is not in the settings of the spambot blocker. And ideally the log file would have all the information so that I can run an analysis after the fact.

Oh, I see. When you said "spambot" I thought you meant this mod. Anyway, as I said I don't monitor what this blocks myself, but I haven't heard anyone say anything that makes me think any spambots are smart enough to adapt to this. We discussed it earlier in the thread and I think the consensus is that there's a small percentage of vb sites using this scheme for protection, so it wouldn't be worth programming a spambot to deal with it. I think if they fail to successfully register, for whatever the reason, they just move on.

There is no log file, although I've been talking about it for a long time. At this point I don't think there ever will be one, but who knows, I might get motivated some day to release an update with a few new features.

First of all the bots themselves aren't intelligent. They are part of a program, programmed by humans.

Using timers for well over three years and studying bot behavior carefully, I have seen no evidence adjustments are made for timers.

Think about it - first you as a XRumer programmer have to know there is a timer. Then you have to know there is a minimum and a maximum setting. Then you have to guess the setting, site to site.

It won't happen, because they are hitting 1000s of sites all at the same time, and individual results don't draw any attention - it's like fishing with a big seining net. Automation, bulk and speed are all that matters.

It's easy to think you're personally being targeted and studied, but you're not. You're just one in the many 1000s.

I am certain for now this is precisely what happens, until there are enough sites where they are starting to investigate why they no longer can register as they 'used to'. The whole spam, anti spam is after all a whack a mole game. It was that for many years and will be for many years to come. So basically a fair assumption is that over time spambots will learn that it is much more effective to wait for 'x' seconds and then send the registration screen back. That would be a simple change in the spambot and over time they will do that. Its just a question when, not if.
I would offer my help in getting a log file into the mod if nothing else because I'd love to have it and I am fairly certain some other folks would be able to get some insight as well. e.g. Right now I believe its about 70% yahoo.com addresses responsible for the spam registration attempts, but I'd love to be able to have real data, not just "gut" data.

It is not a "simple change."

Using timers for well over three years and studying bot behavior carefully, I have seen no evidence adjustments are made for timers.

Think about it - first you as a XRumer programmer have to know there is a timer. Then you have to know there is a minimum and a maximum setting. Then you have to guess the setting, site to site. Impossible. And not even doable, since you are dealing with 10s of 1000s of sites you are hitting. There's also nothing in XRumer that tracks failed registration attempts anyway.

It won't happen, because they are hitting 1000s of sites all at the same time, and individual results don't draw any attention - it's like fishing with a big seining net. Automation, bulk and speed are all that matters.

It's easy to think you're personally being targeted and studied, but you're not. You're just one in the many 1000s.

Conventional "wisdom" says the spammers are all powerful, all-talented, smarter than us gods of some sort, who will always figure a way around any hindrance we dummies out here might devise. And it just ain't so.

I agree with you. I think it's a given that if this were a built in feature of vbulletin, it would have been defeated long ago. It would actually be fairly trivial for a programmer who knew what they were doing.


Yeah, I had a version of this that I reworked and never released that had all the data collected, it just needed the actual logging code. I'm not sure if I still have that around. But the major obstacle for me is that I haven't looked at this code in a long time. Well, it's not much of an obstacle but it's been enough to keep me from thinking about it.

He would also have to know the settings max and min, for every site with this mod he might encounter. And since he can't possibly, he's more or less urinating in the wind. Might get some improvement, might not. It would be a guessing game.

This is all mostly XRumer doing the automated registration and posting, and currently it has nothing in it at all that allows the user to set delays. They can program that into it I am sure, but without somehow being able to detect the time settings they are going to be hit and miss at best, and miss more than hit.

Agreed that if this was a native feature of vBulletin it would get alot more attention than it does - but then we get to the details, where the devils always are.

I have been programming for SO many years before I quit being actively involved in code I can tell you from my own knowledge and experience, THAT change is not only simple, its trivial. It may not be implemented yet because there are not enough site out there so that it became a nuisance, but a programmer who could not implement: "Wait at least x number of seconds and after that wait between y and z seconds to make it look its a human in 10 minutes flat should stop programming. He or she is not worth the money they are being paid for.

Now OTOH, making the spam bots multi-threaded or multi-process or both, That is not a trivial undertaking if it is not designed into it from the get go. I have no insight into spambots and if they are multi-threaded or multi process designed, but if they are, the change to wait is so trivial that it is laughable.

Which brings be back to gathering information: Kevin, would you be willing to let me take a stab at the code? And just to be clear: I do NOT want to take over or step on anybodies toes. I just offer some time to implement a feature *I* would like to see and then hand the software back to its owner and inventor.

Why dont you pm him the new changes to see what he thinks

Sounds trivial until you realize the x and y settings are different for every site.....