9.4 Using Email to Collect Form Data

It is increasingly common to find authors who have no access to a web server other than to upload their documents. Consequently, they have no ability to create or manage CGI programs. In fact, some Internet service providers (ISPs), particularly those hosting space for hundreds or even thousands of sites, typically disable CGI services to limit their servers' processing load or as a security precaution.

If you are working with one of the many sites where you cannot get a form processed to save your life, all is not lost: you can use a mailto URL as the value of the form's action attribute. The latest browsers automatically email the various form parameters and values to the address supplied in the URL. The recipient of the mail can then process the form and take action accordingly.

By substituting the following for the <form> tag in our previous example:

<form method=POST action="mailto:chuckandbill@oreilly.com"
    enctype="text/plain"
    onSubmit="window.alert('This form is being sent by email, even
    though it may not appear that anything has happened...')">

the form data gets emailed to chuckandbill when submitted by the user, not otherwise processed by a server. Notice, too, that we have a simple JavaScript alert message that appears when the browser gets ready to send out the form data. The alert tells the user not to expect confirmation that the form data was sent (see Figure 9-2).

Also, unless disabled by the user or if you omit the method=POST attribute, the browser typically warns users that they are about to send unencrypted (text/plain) and thereby unsecured information over the network and gives them the option to cancel the submission. Otherwise, the form is sent via email without incident or notification.

Figure 9-2. A warning about a mailto form submission

The body of the resulting emailed form message looks something like this:

name=Bill Kennedy
sex=M 
income=Under $25,000

9.4.1 Problems with Email Forms

If you choose to use either mailto or a form-to-email facility, there are several problems you may have to deal with:

• Your forms won't work on browsers that don't support a mailto URL as a form action.

• Some browsers, including some early versions of Internet Explorer, do not properly place the form data into the email message body and may even open an email dialog box, confusing the user.

• A mailto URL doesn't present users with a confirmation page to assure them that their forms have been processed. After executing the mailto form, the user is left looking at the form, as if nothing had happened. (Use JavaScript to overcome this dilemma with an onSubmit or onClick event handler.) [Section 12.3.3]

• Your data may arrive in a form that is difficult, if not impossible, to read, unless you use a readable enctype, such as text/plain.

• You lose whatever security protections may have been provided by the server with the form.

The last problem deserves additional explanation. Some web providers support secure web servers that attach an encryption key to your web page when sent to the user's browser. The popular browsers use that key to encrypt any data your document may send back to that same server, including the user's form data. Since only the client's browser and the server know the key, only that server is able to decipher the information coming back to it from the client browser, effectively securing the information from nefarious eavesdroppers and hackers.

However, if you use email to retrieve the form data, the server decrypts it before packaging the form information into the body of an email message and sending it to you. Email normally is highly susceptible to eavesdropping and other types of snooping. Its contents are very insecure.

So, please, if you use an email method to retrieve sensitive form data, such as credit cards and personal information, be aware of the potential consequences. And don't be fooled or fool your users with a "secure" server when insecure email comes out the back end.

In spite of all these problems, email forms present an attractive alternative to the web author constrained by a restricted server. Our advice: use CGI scripts if at all possible and fall back on mailto URLs if all else fails.