I'm of firm belief that the best way to both control spammers as well as maintain high registration percentage is to simply reverse the process and require registration (or log-in, if user's already registered but not signed-in) details once user already submitted whatever he/she wanted to contribute to your website. Two reasons why:
- User already went through the trouble of typing whatever he/she wanted to and is thereof more likely to complete the registration process, and
- You already have insight into contents users wanted to submit. These posts can be run through spam filters and checked for unwanted contents a lot easier than maintaining any blacklists (public or private).
People can argue that you're tricking your user-base into registering just to post a comment or such, but that can be easily controlled with end-user notifications, if needs be. It's not that difficult to implement either. You can either do it the same way you'd register a new member before email verification (write to DB but mark inactive until registration/log-in is complete), or carry the input fields forward through the registration process in hidden form fields. If we're not talking about content heavy submissions, then the second option is the easier one.
Of course, once a user is discovered to have been trying to submit spam messages, you should immediately flag user's IP address (and tracking cookie, if any) as unwelcome in your DB and check against it each time they try to submit anything new, or even better - completely disable user input to those IPs so they can't flood your web server with too many requests. These flags probably shouldn't be permanent (unless you're really confident in the way your supporting code works) and should be regularly checked to see if your automated spam filter implementation needs corrections.