Support

First issue: turn off emails. When you need to review the security exceptions you can go into Admin Tools, Web Application Firewall, Security exceptions log. Simple!

Second issue: You do realise that regbots do not try to hack your site, therefore there's nothing for Admin Tools to block, right? In fact, the only things you can do are:
- Use the Project Honeypot integration; it doesn't stop them all, though
- Use the Bad Behaviour integration; however, it throws a lot of false positives
- Use a CAPTCHA; your users will hate you
- User a registration email to confirm new accounts; there are companies which will charge you 1$ for 100 website registrations performed by a HUMAN in a developing country, so even that is not perfect

When you find the absolutely perfect way to stop spam registrations, please do share it with me. I'm looking for it for over a decade, to no avail :) If you have found any place in our documentation where I explicitly say that Admin Tools is designed to prevent ALL spambot registrations I will gladly refund you. However, I have not sid that anywhere. I do mention that Project Honeypot and Bad Behaviour integrations, as well as CSRFShield should block such bots, but it all depends on how the bot is coded. If I had such a silver bullet I wouldn't sell it for 20$ per year without domain restrictions, but 20,000$ per site per year.

Regarding the first issue, there's a reason why it's not implemented. There are two mindsets regarding security alerts. One of them says that you should be instantly notified when they occur, hence the emails. The other one says that you should log them and review the logs at your leisure, hence the logging. In fact, there are four different kinds of emails sent:

1. Back-end logins. IMHO, you should always be emailed about them, as you can spot a hacker if he breaks in to the site's back-end.
2. Failed administrator login. Ditto. It could indicate a hacker trying to brute-force your password.
3. Automatic IP ban. I consider this an overkill, some people begged to have it.
4. All other security exceptions. IMHO, an overkill. The log is better suited for them. Some people want them. Most people, you and I included, don't. Therefore, just leave that email field blank.

I don't see the benefit of grouping, batching and filtering the emails per security exception. It would result in a very complex interface which makes no sense whatsoever. I mean, would you think that SQLi is more important than a malicious user agent? Most likely yes, but not always. It is more than fathomable that you get hundreds of SQLi reports every day due to some script kiddie trying his scripts on your site. Funny thing, those scripts could be for Joomla! 1.0 or phpBB3. However, you might only get one MUAShield alert and that being from a hacker using a powerful hacking tool which could cause something bad on your site, ranging from denial of service to hacking it. So, what's the point of filtering them? It would only be relevant if we had some sort of AI capable of understanding which attack is real and which is inconsequential or a false positive. But should we have this AI, we needn't have emails, we'd simply block the confirmed attacks. Therefore I am not particularly interested in creating a useless filtering feature that adds no value to the software.

Regarding the second paragraph of your reply, I just don't want you to think that I'm trying to screw you off your money. I thought this is what you implied, as you said that you bought the Professional version so that you can get rid of spam bots and it fails at that point. I never said that it's the silver bullet which can prevent website spam. In fact, there is nobody with a perfect bullet. The proof is that spammers still exist. It's not something I can "fix". I was very honest when I said that if I had invented the silver bullet against spam I'd sell it for a crazy amount and become rich (and famous). Just think about what you implied with your post: someone having a solution against a multi-billion dollar illicit activity. I'd love to be that guy, but I don't think this person has been born yet ;) The workarounds I proposed is what you can realistically do today to fight spam, with moderate success. Since there are companies employing real (flesh and blood) humans for 0.01$ per spam registration I don't think we'll ever be able to stop spam, unless we start asking users to email us copies of birth certificates.

if a bot is using code or sql methods rather than exploiting a form to plant users is that not hacking a site.

That's an arbitrary assumption. Can you please provide the log excerpt which verifies this assumption as a fact? That's a rhetorical question. This is not how spambots work. Let's take a crash course into writing spam bots.

Even if you do not have set up a Joomla! user registration page as a menu item or in a module, it is always available at index.php?option=com_user&view=register (that's a Joomla! 1.5 URL, it is slightly different in 2.5). A spam bot can parse the HTML, extract the token, forge the HTTP referer header, and submit the form back to your server. A new user is created. If you have not enabled the registration emails, it is an activated user. If you have activated those emails, a sophisticated bot could read the email and access the URL in it, activating the account. If you give me 2 hours I can write such a bot in PHP, it's not a big deal.

Since this activity DOES NOT have anything to do with hacking –we are using the standard Joomla! user registration URL– you can not expect Admin Tools to stop it. There is no SQL injection, remote file inclusion, access to arbitrary PHP file, upload of arbitrary PHP code, cross-site scripting or other hacking method involved. In fact, from the server's point of view, it's exactly what a human user would do to register a user account.

Just because you assumed there is an elaborate hack involved in spam registrations doesn't mean it is so. First things first, that would define the Occamm's Razor principle: it's a too complex explanation to be true. Simpler methods work best. Besides, that's why your server keeps access logs. Please take the time to read them and understand where the spam registrations come from. Don't just assume that I am an idiot writing software which lies about its ability to stop hacks. My software is designed to stop most common hacking methods. From there to blocking all spam registrations, that is a leap of logic, since there is no hacking involved.

The plugin you mentioned seems to be using the same Bad Behaviour library and the same Project Honeypot integration used in Admin Tools. Which are two of the workarounds I did tell you to pursue, along with their drawbacks. Moreover, I will make an educated guess that it might be using another spam filter, called Akismet, to fight Kunena spam. This involves sending the entire post text to a remote service which assesses its content based on millions of other messages and reports –within a degree of accuracy– if it's spam or ham (jargon for should be blocked or not blocked, respectively). I chose not to implement that in Admin Tools because I aimed for a security solution, not a comment/post anti-spam solution. There are other plugins to do that, why should I reinvent the wheel?

The problem seems isolated to Joomla! 1.5 because in Joomla! 1.5 the direct user registration URL is index.php?option=com_user&view=register whereas in Joomla! 1.6 and later it is index.php?option=com_users&view=register (note that it's com_userS, not com_user). The spambot scripts have not been updated with the new URL, yet. Expect that to change in the near future.

So, I will have to ask you again. Did you buy Admin Tools Professional because you thought that spam registrations were the result of elaborate hacks and you wanted to stop them, or because you genuinely wanted to secure your site? Admin Tools –like any other tool– can not guarantee it will block spam registrations. It can guarantee that the vast majority of hacking methods which go through Joomla! will be blocked.