Your Email forms Won’t Work?
Is it because they’re not supported?
Don’t want the Perl or ASP solutions?
Read on!
We recently added an article describing some
alternatives to ACTION="mailto: for forms handling (see
https://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 = "youremail@domain.com"; // youremail@domain.com
// bcc emails (separate multiples with commas (,))
$bcc = "";
Simply put your email address in place of "youremail@domain.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’,’121.0.0.111′);
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!
