Like most kinds of gated security, many solutions are borne out of inspecting the payload instead of who's sending it.
Captchas prevent bots from submitting spam, but they don't prevent humans from submitting spam. In 99% of cases, your problem is the spam, not who is submitting it. The non-lazy solution is to look at the content itself and directly determine whether it's spam, instead of relying on a related heuristic (e.g. who submitted it) to make an informed guess.
This isn't an alternative solution, just one you could do alongside making it difficult for drive-by bot spam.
For example, let's look at an actual service for identifying spam payloads: Akismet. It still lets a lot of spam through, especially in non-English languages.
This is a solution that, if done "perfectly", should be able to catch 100% of spam submissions. This is in contrast to things like captchas (because they "test" something other than the end-goal [no spam] to guess at whether something is spam or not, while ignoring spam from humans [or humans filling out captchas on behalf of bots], and cause problems for both humans and benign bots).
Obviously, it's an extremely hard problem that is hard to do 100% correctly. But it's a viable non-lazy solution (that still needs a lot more work than the current state-of-the-art implementations) compared to the lazy solution of just putting captchas on the page.
The ideal solution would get rid of spam without inconveniencing users who aren't submitting spam, I'd think, which means captchas aren't it.
Honest question - if you set it up so the user gets an email with a link they have to click before their message is actually sent to your queue, would that help?
I'm thinking it would probably reduce the number of users who successfully contacted you legitimately, but CAPTCHAs also do that. Do spammers actually have the email accounts they claim to and respond to confirmation emails?
It would definitely help, I highly doubt spammers would use that sort of mechanism.
The solution gets around potential vendor lock-in and privacy issues with a service like Google's, but it still fundamentally shifts the problem from the service to the user (the original commentor's gripe).
But this is exactly the point I am trying to make. That's the service provider's problem and not the user's. CAPTCHA shifts the problem to the user.
CAPTCHA is a 00's idea, when we had the multiple page registrations(with errors showing only after you submit the page), the insane password requirements, etc.. It doesn't belong to modern stack in my opinion.
"What is the non-lazy solution?" That's how disruption is born.
Almost. It gives a botness score to the server, and it's up to the website to decide what to do with that score. They can pick a threshold to approve, reject, or apply stricter verification to.