I guess I'll chime in with my experience on this problem. For the
past 2 years I've been using a form processor script I wrote on all
the client sites for my company. I developed it at first to handle a
simple set of functionality that hit 90% of the requirements of
contact forms. It can handle any input field and will send emails,
log the results, or anything else you want with a simple plugin hook
architecture. It is deployed on hundreds of contact forms across
dozens of different websites.
I'm happy to report that most of the spam across the board has been
stopped. All without a single CAPTCHA. When we spot a problem, I can
update our one form processor and then all of the scripts are
protected against the new attack vector. Plus when there is a very
specific case I can use the plugin setup to really get specific in my
rules.
Here are some of the concepts that it employs. Please keep in mind
none of this is a 100% and each can be easily bypassed, but together
they are fairly good. If a human is doing the spam manually, then
there's nothing you can do. :) Also it should be noted that if any of
these requirements fail, then I simply re-display the form with a
message that explains why to the user so that legitimate users will
see what went wrong. Again this aids in allowing spammers to find a
way around, but that is always our burden.
Valid Email
I require an email address in a specific input field and use the
PEAR_Validate function to validate the existance of the domain name.
Also there is another thing where I can say do not allow email from
this domain as some spam software will auto fill in the current
hostname.
Honey Pots
This is a two step process. First I have a hidden form field that has
a specific value in it. If this value is tampered with, then I reject
the form. The second form field is inside of an html comment. If
that value is posted, then I reject the form since it shouldn't exist.
Blacklisting
There are a key set of words that I block.
array('to:','from:','cc:','bcc:','href=','url=')
Require Cookies/Sessions
Most spamming programs I've seen are stateless. So by simply
requiring it accept a cookie foils quite a bit of them.
Max @ limit
Another little trick is to limit the number of @ characters that can
exist within the contents of the post variables. This catches quite a
few submissions.
Define form fields
An optional feature is to enable something to define each input field
that should exist in the post array. Then when the form is posted I
check the defined post array against what has been posted. If there
are extra post fields, then I re-display the form since it is probably
a spam bot just blanket testing forms.
One thing to keep in mind is that this is in use across a lot of
different sites. Not one specific type of site or service is in use
here. Perhaps if someone had more incentive to crack on one of our
forms I'd have more issues. It is hard to say. All I know is that it
has worked really well for my needs, maybe it'll work for someone else
too.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
