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 address?
Answer: Just use mailto in the form's action attribute:

<form action="mailto:somebody@example.com" 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:

Let's consider some of the things that can go wrong:

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!

Image of Security Alert DialogThe 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 mailto. 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, thank you for your submission. You can sort of work around this using JavaScript, 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 lot!

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:

textfield1=value+entered&textfield2=another+value&Submit=Submit

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

Using mailto 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:

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.

Conclusion

Okay, hopefully, I've weaned you away from the evils of mailto and started you down the road to reliable form processing. I hope you've at least found this rant to be mildly enlightening.