The spammer essentially "hijacks" FormMail CGI routine and causes it to send out emails as fast and furiously as they can. I know of one instance where a spammer sent over one million emails in a single day before someone noticed that their web server was going very slowly (I wonder how long it would have taken had spammer tried limiting load on server so it didn't show up as much). What happens here is very simple. The FormMail CGI routine is simply called remotely by spammer, once for each spam email that he wants to send.

Ah, you say, but you could code FormMail routine to check referrer field. This would surely prevent a spammer from using it remotely, as his referrer would not be website URL.

Sorry, no. The referrer field is actually a text string passed to CGI routine by browser. The spammer is most likely using a program which appears, to your web site, to be just another browser. Since spammer controls program he can code it to send CGI routine whatever value he wants for referrer field.

As it turns out, it is very difficult to make a CGI routine such as FormMail even relatively secure, and it may be impossible to make it bullet-proof. All you can do is check enough things and put in delays here and there to slow down and discourage spammers.

You could, for example, only allow one posting per IP address per hour. You could also check referrer just to block out more ignorant spammers. I suppose you could count number of times routine is called, and have it just stop working after a certain amount. For example, only allow one hundred calls per day from anywhere.

The point here is not to tear apart FormMail routine. The goal is to show how difficult it can be to make anything secure on internet, and demonstrate that some assumptions (that referrer field is a valid check) may not be true in all cases.

What do you do? Before you implement any CGI or similar interface, be sure and do a little research to be sure you completely understand and handle ramifications. If you don't do this, you may find yourself victim of a hacker or spammer.

3) Each of input tags includes a variable name. The data which is retrieved from visitor (or directly set if tag includes "hidden" qualifier) is placed in variable name.

4) When visitor presses "submit" button, CGI routine which was specified in form tag is executed. At this time, CGI routine "takes control", meaning browser essentially is waiting for it to complete.

5) This CGI routine can get data from variable names. It retrieves data and does whatever action is required.

6) When CGI routine finishes, it returns control back to web client (the browser).

Some important things to remember about CGI routines:

- You can install CGI routines on your own site if your host allows it - Addr.Com is an example of a web host which allows for CGI routines. Some web hosts do not allow you to install your own routines but do provide some pre-written ones to you. If these are not sufficient for your needs, you can find a remote hosting service to provide necessary functions.

- Generally, if you install your own routines they must be installed in cgi-bin directory of your site. This is a special location which allows scripts and programs to be executed.

- CGI routines work best on Apache-style servers. Windows NT and Windows 2000 does support CGI, but it tends to be slow and problematic.

- If you use a remote hosting service, you must remember that although they appear to be giving you this for free, you are actually paying a price. Usually they want to display advertisements, although some of them actually take visitors away from your site.

- When you write a CGI routine, you have choice of a scripting language like PERL or a compiled language such as C++ or Visual Basic. Anything which can execute on web server is acceptable.

I hope this short introduction to CGI has cleared up some of mystery.