> Hi Javier!
>
> At my work we had tons of issues with spam bots randomly hitting our
> contact forms. They would inject all sorts of random garbage along
> with the standard email header injection attempts to try and send mass
> mails through the forms.
>
> We've worked on a standardized form processing script that has some
> basic ideas implemented that has cut down on 99% of the spam in our
> forms yet also does _not_ use any horrible CAPTCHA crap. If you use
> one of those you're basically saying you hate your users and want to
> make them miserable.
>
> Here are a few of the ideas we use:
>
> - Require a user enter an email address and then validate this address
> using PEAR::Validate::email() with the true parameter to resolve host
> names. That would always require at least a valid domain name.
>
> - Filter all the fields against a set of invalid keywords. Also make
> this set of keywords extendable on a per site basis because some sites
> get hit with different keywords. Here is a set you can start with
> array('to:','from:','cc:','bcc:','href=','url=')
>
> - Trick the bots. I noticed lots of forms spam scripts will use some
> sort of regex to find all form fields and then inject them with any
> value that they want. Just because your form uses a select dropdown
> or hidden field doesn't mean that is what you're going to get back.
> Most of these things in my experience are automated so they just do a
> mass search for name="". I use this to my advantage by doing two
> things. First I have a commented out field that if it is submitted I
> fail the post. Then I also have a hidden field that has a constant
> value that must remain the same. If this value is changed (only a
> spammer would do it since it's hidden) fail the post.
>
> - Add a configurable option to ignore posts that contain the domain
> name in them. Lots of these bots will send out a test that uses
> random@<the current domain of the site> as a test. I usually enable
> this feature after the client has tested their form and are happy with
> it.
>
> Make sure that if any of these conditions fail you show the form back
> to the user with a helpful error message. This way if a real user
> accidently triggers any of the security measures you can let them know
> how to fix it, such as removing href= from input fields.
>
> Good luck!
Thanks again for the suggestions Eric and everyone else. One of my
colleagues, who is more PHP savy than I, agreed to help me work on this
using all of your suggestions.
I am now quite confident that we will be able to conquer our spam problem.
Javier
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
