The process is totally transparent to the browser user, since the email isn't sent via the user's mail client (which can't be guaranteed to be configured at all, and which requires the cooperation of the user in completing the send process), but via the Web server's own mail software. Often, the destination would be your own email address, so you could then manually process the results of the form. More usefully, it could be an automated mailbox on your own servers which allowed you to upload static HTML pages to a very basic Web hosting service (without such modern facilities as MySQL databases), yet have the form results update local back-end systems. The email could be received and processed automatically on your systems, even if the only Internet connection you had was a regular dial-up mail drop. A very simple form of what might now be more grandly named an Asynchronous Message Queue Transaction System.

Figure A shows a sample of emailed results of a Web form.

FIGURE A

Here are sample emailed results of a Web form. Click picture for a larger image.

Drawbacks
Of course, there are drawbacks in this approach, principally that there is no ability to send immediate feedback to the Web user who fills in the form, other than a standard page generated perhaps by the form-to-mail script. After pressing the submit button, nothing happens right away other than an email being fired off in the background. Any response to the form--whether this be a sales update or a field validation error--has to be in the form of a separate email sent back to the user later.

However, if you were a 1996 Webmaster with access only to static HTML Webspace, then the drawbacks hardly mattered compared to the ability to put fancy Web forms onto your Web site and receive customer feedback in some form of structured email.

Fast forward to 2000, and although Domino hosting is available, the costs are still out of the league of many small groups and individuals. Other Webmasters have to try and tie Apache or Microsoft IIS based Internet sites back to a Domino-based intranet. The old tricks are therefore still useful. And if you're delivering Web forms to offline devices--such as Palm devices running AvantGo--receiving Web form submissions in this fashion, without immediate user feedback, is the natural way of things.

Even if your Web hosting company is at the very bottom end of the market and won't host a CGI script, there are public CGI servers with which you can register to process forms by mail. For example, the address of the CGI scripts of FormMailer, http://www.formmailer.net, can be specified as the Submit action on a Web form hosted on any server. In this case, all of your Web content is on your preferred provider, but the results of user's forms are processed on FormMailer's Web server and then sent to your own email account. For details of such companies and other CGI services, check the CGI Resource Index at http://cgi.resourceindex.com/Remotely_Hosted/Form_Processing/.

Domino form reception
Earlier, I mentioned that this solution would also require some old Notes techniques. The very idea of sending forms around by email is natural to experienced Notes developers (i.e., the Store Form in Document option in Form Design), though it's less often practiced these days. In a traditional R3 workflow system, when a form had finished wending its way through the inboxes of people involved in the approval process, it would usually end up being sent to a "Mail In Database." An example of a Mail In Database document is pictured in Figure B.