This is an intriguing thread, and I have learned a lot. I personally don't use CAPTCHA or any visual confirmation. I know I have at least one user who is visually impared, whose equipment can't read visual confirmations. This person has requested I not use them, so she can use my site.
I haven't had misuse of my contact form, that I am aware of, so far. I have a small narrow interest site. I did have a guest book that got throttled by UCE attempts. From the start I set the guest book to allow me to preview posts before allowing them to display for public reading. This prevented garbage from being posted to my guest book, but I ended up changing the name to a Feedback Log to prevent search engines from finding it. I was wondering how this would work: 1) At the start of the contact form, capture the users IP address, the UNIX time stamp, and a generate a random number, and write these to a table in the dB (for ease we will call this table x for now). The random number would be used as the value of a hidden form field at the bottom of the form. The UNIX time stamp is used to compare to table x in the next page to make sure the poster took the correct amount of time to post (not too long or too short) 2) Check another table in the dB for the user's IP to see if they are banned. If they are banned, display the form anyway, or give them a "banned" message. 3) On the processing page (Thank You page), capture the user's IP and the UNIX time stamp again. Compare the post variables to table x where the IP and random number were written from the contact form page. The UNIX time stamp would be compared to the value in table x also and posts out of range (too quick or too long) could be treated as those not matching the IP and random number. If the time stamp values, IP or random number don't match, either dispay a rejection message or a thank you message to make them think they have succeeded. Their data is dumped at this point. If the post variables match the values in table x, the form variables are processed normally, the contact goes through normally and the values are deleted from table x. This would prevent users posting to the processing page without first visiting the contact form. 4) Users whose contact is rejected for attempting to post right to the processing page, or posting out of the accepted time stamp range could be added to the ban table. Combined with recognizing regular expressions known to be associated with unwanted contact, stripping html, and other such efforts, this could make it fairly difficult for malicious posters to automate their efforts, and get garbage through. The UNIX date stamp and IP could be retained on table x for a time to prevent flooding (frequent attempts to post), but another routine in the code would have to clean up table x to keep it clear of unnecessary records. This method seems least intrusive to users, unlike CAPTCHA or asking them to answer a silly question. It also doesn't depend on storing a whole lot of data. If a user's IP can be spoofed so the $_SERVER['REMOTE_ADDR'] variable is fooled this won't work as well.
