The Mythical Mailto:

Every website out there that wishes to interact with its visitors uses a form. This article serves to highlight the growing problems and misconceptions of form handling. Many forms out there fail for one reason: The webdesigner has incorrectly assumed what a visitor has installed.

Forms Overview

HTML Forms are the most common feedback mechanisms on the web today. They allow the site-owner to collect information about the surfer, for reasons of pure interest right through to nefarious schemes to swindle people's life savings (also known as Multi-Level Marketing and adult content sites). If you want to know something about a visitor to your site, you use a form.

Hand in hand with displaying forms follows a component to process or direct the input of this form. As behind every innovative man is a strong woman, behind every form there is a mechanism for retrieving, storing or assimilating the data - two sides of the same coin.

Normally behind every form is a server side script which takes the form data, via either a get or post method (depending on the size and type of data being passed), collects the data and does one or more of the following actions:

• Store the data in a database or file
• Use the data to calculate/generate a page
• Sends the data to the site-owner via email

The third methodology has been taken up by enthusiastic web-authors, mainly because of its convenience and simplicity, and mainly for the mistaken belief that an action of mailto: results in the sending of the form data in a mail to the owner. "It works for me", say the inexperienced author.

True, <form action="mailto:joebloggs@example.com"> looks very elegant a solution - so did the Titanic, and its captain didn't expect problems either.

Mailto Drawbacks

Looking at the HTML 4.0 specifications, and especially at the exposition of the form tag shows that for the action attribute should be a correctly formed HTTP URL. Anything other than a URL is undefined, thus the resulting action taken by browsers is completely random since browser designers are left to their own devices.

Microsoft's Internet Explorer when used with Outlook Express does produce the remarkable effect of sending the contents of the form via email to the address suggested in the form tag. Which is good for the newbie web-designer - Melissa and Love Bug worm-authors are equally happy with this close relationship between the browser and mail reader. This affinity is thus a good thing, and a serious fundamental security flaw.

Other combinations of browsers and mail readers produce one of the following effects:

• An error that there is no mail reader on the users machine.
• An error because the browser cannot identify the users mail reader.
• No mail being sent, because the user cancels the mail request so as to avoid revealing the user's email address.
• The email disappears into nothingness because the action mailto: is further malformed from a proper email address by the use of ?subject - which is an invalid email address.
• The email arrives to the website owner, only to appear blank, since either or both of the browser and mail reader could not add the contents of the form to the email.

alt.html Snippet:

Here's the result of using the Pegasus mail client to send email to an illegal address: 501 <joebloggs@example.com?subject=testing>: malformed address: ?subject=testing> may not follow <joebloggs@example.com -- What this suggests is that if the browser doesn't process the illegal address that includes '?subject=...', doesn't strip off the illegal part, then the email goes South.

An author has no control over which browser the visitor uses. He/she can't be sure the ?subject address will work every time, when the page is being designed. Newbies beware.

Posted by Steve Grant

With so many possibilities of going wrong, all of them dependant on the user's set up; this form has broken one of the fundamental rules of web-design: Never assume what the user has installed.

The Solution

The corollary the the first fundamental rule of web-design is: The server is the one tool a web-designer can trust. Since the web designer has the choice of where to host his pages, he therefore has the choice of what tools and interfaces he will use during site construction.

Translated to our problem at hand, form processing, the solution is blindingly obvious. Use a server side script to handle all the data from our form, and this script can then email all the details to the web-site owner.

The advantages of using a server-side process are:

• No mail-reader required by the user. This is an important point since there are still a vast number of people who don't have the luxury of surfing from their homes or work, and use an internet cafe.
• The form can be used by a much wider range of web-browsers. This is largely because server-side processing makes no assumptions about the client browser - except for the prime requirement of the browser being able to accept correctly formed HTML.
• Security-wise - no email addresses are mentioned on the web-page, thus a spammer's mail-harvester will have no luck in finding you as a potential victim to Unsolicited Commercial Emails (spam).

Where do we find a server-side script to handle form submissions? There is a great CGI-resource on the web that has several formmail scripts that can be used.

One common punt by the inexperienced web-designer is that his web-host doesn't offer CGI facilities, so he is forced to use a mailto:. There is a reliable alternative for this problem, apart from moving to a different web-host. This alternative is the remotely-hosted formmail script - which is a script that is hosted on someone else's box. Two sites allow web-designers to use these scripts freely, they are Response-O-Matic and Freedback.