You've taken some good steps. While it's possible to stop all registration spam, you can probably reduce it a fair amount. One thing I notice is your registration url is very easy to get to. Most automated spam registration scripts/bots will easily be able to guess /register as a link. Having something slightly more obscure could help, like /book-lovers/register or maybe even /pccs-register.
I prefer ReCAPTCHA to ExpressionEngine's built-in CAPTCHA system, but generally speaking try to avoid captchas.
With Low NoSpam, I'd say also take a look at Barricade.
The Blacklist Module and your .htaccess file can also help in these battles. We use the 5G Blacklist updated annually by Perishable Press. It's chocked full of goodness, but be careful, you may have to comment out some rules that interfere with your set-ups behavior. For example: we modify this statement:
RedirectMatch 403 (\,|//|\)\+|/\,/|\{0\}|\(/\(|\.\.\.|\+\+\+|\||\\\"\\\")
the statement that disallows commas in the url, since we use Tags, and want to allow 2 or 3 combinations, but NOT unlimited combinations. The biggest boost this provided is just not allowing known spam bots to even hit the site.
CloudFlare is also good for this as well. It provides an all around extra security boots for the site, while improving site speed.
So make sure Blacklist is properly configured, that you look into the 5G Blacklist, and potentially use a CDN like Cloudflare as well.
That said, a lot more registration spam these days are created by actual people, who've created real email addresses. The get paid through services like Amazon Mechanical Turk to complete registration forms. It's still spam, but powers through CAPTCHA's, challenges, and other prevention methods.
Read this article on Fighting Registration Spam. What's true about it is that almost 99% of our registration spam have usable email addresses. Meaning that, even though we do self-activation, those activations don't bounce. We use Mandrill to monitor the normal black hole that is CMS email transactions. We thought that registration emails would have a high bounce rate, for one of our clients, because they have close to 70,000 registered members, and many of them are obviously just spam accounts.
Just remember, common names like register can be easily targeted via bots, especially if they are in strategically known locations, such as /register, member/register etc. So change the trigger (which you've done, but change the page name as well. If you are using something other than the default EE registration, like Authenticate or Safecracker Registration, Users, Zoo Visitor, etc., you can adjust the file name to whatever you like.
But also remember, now days you are mostly combatting humans, so beef up your overall security. Use blacklist, and .htaccess to other tools to help.
Update: Dealing with Client Notification
There is no way to successfully stop all spam. Any method that you find today, will eventually be cracked and attacked. Obviously, having systems to combat spam is good, but the real problem seems to be the client's need for notification. They don't want ALL notification, they really only want good notification. Which means, you don't want to send pending or banned notifications, rather just successful activations (those could also be spam, but it would be far less email).
I'm not certain of any system that does this outright. Possibly PostMaster could be used to do it. Otherwise, I'd look into seeing if you could combine Registration Codes with MX Notify Control to get something closer to what you need.
Otherwise, its just important to let your client know, they can't stop spam. Unless they want to turn their site into an invite only registration system, which I'd assume would hurt sales. Make them understand, the more complicated they make it for the 'purchaser' the higher the abandon rate. If you have Google Analytics set-up, you can create a funnel and provide data.
Ultimately, the site, by some fluke, could get 50-100, legitimate or semi-legitimate registrations per day, that don't turn into purchases or subscriptions. Do they really want to deal with all those notifications?
Some clients won't see reason, but it doesn't mean we shouldn't try to make them do so. It also means sometimes you have to say, 'this is the best we can do…' I can't stop your spam problem, I can ONLY reduce it.
