Using Mailto in a Form Action
FAQ #6,384,279: What's the easiest way to send a form's results to an e-mail
Answer: Just use
mailto in the form's action attribute:
<form action="mailto:firstname.lastname@example.org" method="post" enctype="text/plain">
That's so easy; what could possibly be wrong with it? What's wrong is that it makes assumptions that may not be valid and, as a result, it is very unreliable.. It assumes that:
- The user's browser knows what to do with a
- The user has e-mail client software installed and properly configured
- The user's e-mail software knows what to do with a
- The user's security settings allow this to happen without prompting with a security alert
Let's consider some of the things that can go wrong:
- The user uses a webmail service, like hotmail
- The user is using a public computer at a library or Internet cafe
- The user uses a browser or e-mail software that doesn't recognize
- The user's security settings cause a prompt, alerting the user of a potential security problem
If none of those apply, your form results will be sent like you wanted.
Why It Fails
Let's discuss those possibilities just a little further, so you'll understand what can happen. In the first two cases, where the user uses a web mail service or a public computer, the machine will not have an e-mail program configured. Assuming, for the moment, that the user's browser knows what to do with a mailto link, the default e-mail program on the machine will start up and ask the user to configure it by entering host and user information.
The third issue, the user's browser or e-mail software dosn't recognize the mailto action. Why would that be? Well, mailto is not an officially defined protocol. There is no established action for the browser to take with that type of link. Most browsers will recognize it, but since it's undefined, you're taking a chance there. If the browser or e-mail software doesn't recognize it, the user may simply get an error message.In some other instances, the user's e-mail program might open a new e-mail message requiring them to manually send it. That e-mail message may, or may not have the form data included. In fact, some will just open a new blank e-mail message! Or what about those hidden fields. What if the e-mail message opens, populated with all your form data? The user can change the values of your hidden fields!
The fourth one, the security alert, may allow the e-mail to be sent if the user chooses to allow it. The dialog box to the right is an example of what the user may see when submitting the form. I've not done any kind of scientific survey, but I'd just about bet that at least half of the people who get the security warning will cancel sending the form. Most will not even bother to read it. They'll just see the warning, get scared, and cancel.
So now we have five possible outcomes, four of which are bad. As a matter of fact, three of the four fail completely.
Success? ... Sort Of
Even when it succeeds, there are other problems with using
One problem is that it doesn't allow a redirect following the form submission.
You know, like when you submit a form and it sends the data and then says,
but the result is phony because it will always redirect to the thank you page,
regardless of whether the e-mail was sent or not! Imagine the poor user who
gets a security warning, clicks Cancel, then arrives at a thank you page.
How confused do you think they will be? A
Another problem is that you have no control over the formatting of the e-mail message. You may simply get the results in a message that looks like this:
That's not exactly what I would call readable!
Okay, I could rant on and on about how bad
mailto is for sending
a form, but I'm probably boring you by now. Hopefully, the issues involved
are compelling enough to convince you to abandon the use of it.
How to Solve the Mailto Dilemma
in the form's action relys on the
user's software. Worded differently, it relys on client-side software. There
is a very old adage in web development: "only trust the server."
I believe in that adage. That means that, if you want reliability, you have
to process the form and send the e-mail using a script on the server. So now
the question is, how do you do that?
- Use a Pre-Installed Script
Most respectable web hosts have a pre-installed script for e-mailing form results. The first place to look is in your web host's control panel. You should also check your host's FAQ. Most hosts will have a script that can be easily installed and configured and using that script will be the easiest way to get your form results e-mailed reliably. Your host's FAQ should have instructions for setting this up.
- Use a Pre-Written Script
If your host does not have a pre-insalled script, then you need to find out what scripting languages the server supports. Here are a few recommendations for scripts that are reasonably powerful and not too difficult to install and configure:
- PHP: PHPFormMail, available at http://boaddrink.com/
- ASP: ASP FormMail, available at http://www.brainjar.com/asp/formmail/
- Perl: nms FormMail, available at http://nms-cgi.sourceforge.net/scripts.shtml
Note that the above scripts are all based, in usage, on the original Matt's FormMail from http://scriptarchive.com/formmail.html and all offer the same basic functionality. The original, by Matt Wright, has not been updated since 2002 and the replacements offer quite a few security enhancements. Even Matt recommends not using the original any more, but the documentation there may be helpful if you're having trouble getting one of the others to work.
- Use a Third-Party Form Processor
If your host does not support any server scripting, you should consider changing hosts. If that's not possible, your only recourse is to use a third-party form processor. You can check out some of what's available at http://hotscripts.com/Remotely_Hosted/Form_Processors/index.html
Of course, if your server supports PHP and you want to learn more about how to process forms with that language, I might humbly recommend this tutorial. It will lead you through basic text e-mail messages, form validation, HTML e-mail, sending attachments with the e-mail, and security issues. Once you have the knowledge, you can have a lot of control over the processing.
Okay, hopefully, I've weaned you away from the evils of
started you down the road to reliable form processing. I hope you've at least
found this rant to be mildly enlightening.