Another Forms Solution
Application Security Testing: An Integral Part of DevOps
Your Email forms Won't Work?
Is it because they're not supported?
Don't want the Perl or ASP solutions?
We recently added an article describing some alternatives to ACTION="mailto: for forms handling (see http://www.htmlgoodies.com/articles/emailforms1.html) Subsequently, we have received a number of emails requesting a PHP solution. Always willing to oblige whenever we can, we here present just that!
Before we get into this option however, and in the interest of providing everybody with some kind of workable solution to their form handling problems, I'd like to point out the service offered by formmail.com. If for any reason you can't run any scripts and you still want to have forms with email responses, or you simply don't want to get into configuring your scripts, formmail.com will handle your forms for you. Not quite free, but almost, you can process up to a hundred submissions a month for less than a dollar (price as of this writing; higher volume prices also available - check the site.) Pay just once, and you can handle any number of different forms quickly and easily.
Test for PHP Support.
Before you use any PHP script it's useful to find out if PHP is supported on your server. If it's your own server that's easy, but if you have your site hosted somewhere, you could ask our host. Alternatively, you could use the code in "Your First Page With PHP Code" in our new PHP tutorial series. Once you've established that you have PHP support, you're ready to continue with this solution.
Get the Script.
The script we'll be using is called "formmail.php" and it was written by Joe Lumbroso. Joe credits Matt Wright of Matt's Script Archive for the original inspiration. Matt was the original author of the formmail.pl that was discussed in the earlier email forms solution article. To get the script, go to Jack's Scripts, here. There's also plenty of documentation on Jacks Scripts which I know you're going to read! (uh-huh!) Just in case you don't read it all, I'm going to run through the most important parts of the configuration for you.
Using the Script
I love this quote from the documentation: "To set up the FormMail.php script copy it into the directory in which you are planning to use it. It's that plain and simple." Yes, it really is that simple! However, there are a few things worth knowing. First his note in the documentation is followed by the recommendation that you rename your script. That's a very good idea! I'll be making a couple of other security suggestions in a moment, but my experience with formmail.pl tells me that renaming the script is of primary importance. If you use its original name, a search of the web on any decent search engine will reveal it. Hackers know what the original name is and the search will immediately provide them with a list of targets. Be creative with the name, but leave the .php on the end alone.
The problem with people finding your script is that they could use it to send out emails, potentially spam or other nastiness, that could appear to have come from your site. At the very least, it could choke the mail server you are using. Another important safety measure you can take is to restrict the potential recipients to the one or two email addresses you want to use. Most of the time when we use a form we are capturing data to be sent back to ourselves. That being so it is not necessary to leave the recipient address open to change. Neither is it necessary to use a field (albeit a hidden field) on the form to define the recipient. Anything contained on the form itself can be discovered and a hacker worth their salt would be able to manipulate it. Formmail.php provides a mechanism to "hard-wire" the recipient. Take a look at this piece of code from near the front of the script:
// for ultimate security, use this instead of using the form
$recipient = "email@example.com"; // firstname.lastname@example.org
// bcc emails (separate multiples with commas (,))
$bcc = "";
Simply put your email address in place of "email@example.com" (leave the quotes in there!)
These two fields are for predetermining the recipients (including the "blind copy circulation" a.k.a. "blind carbon copy".) Setting these in the script (which is resolved on the server and never sent down to the client) makes your copy of the script of little value to anybody else.
One last security measure you can consider using is to add in the list of domain names that are allowed to use the script. You know which of your websites will have forms that you will be processing, so adding them to the "referrers" list prevents any other website from using it. This code is also near the front of the script (right after the above code, in fact):
// referers.. domains/ips that you will allow forms to
// reside on.
$referers = array ('somedomain.com','www.somedomain.com','220.127.116.11');
Replace somedomain.com with your domain name. You can also use IP numbers, as in the example provided, but personally, I find that to be inconvenient. A domain can be moved to a different IP number, but its name will remain the same. The IP number option is best for sites without names, or for instances where there are a lot of sites on the same server.
That's really all you need to know to be able to use this script. The clever script that it is, it picks out all the fields in your form and sends them in an email to the specified address.
The URL for the full documentation is http://www.dtheatre.com/scripts/formmail_doc.php#recipient It makes for interesting reading.
Between our first article and the options suggested in here there is mechanism for everybody to handle their forms, regardless of their hosting choices, so go ahead, set up your forms and start collecting data!
IT Solutions Builder TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD
Which topic are you interested in?
What is your company size?
What is your job title?
What is your job function?
Searching our resource database to find your matches...