Developer Support »

Form-to-email primer

"form to email" is a protocol used on websites. It goes by a number of different names like form mail, formmail, mail form, form mailer etc. As the name suggests, it sends the contents of a form by email. A form is a device used on a website that accepts input from a visitor in a structured manner. This input (the form data) is then sent in an email to a pre-specified recipient when the visitor submits the form.

The data submitted from the form is processed by a form processor script. The script takes the input, validates it if desired, then sends an email to the intended recipient containing the data entered on the form.

The protocol requires two separate parts: 1. A form. 2. A form processor script. The form is shown on the website. The script is in the background.

This is what a form looks like (this is a dummy one):

Email address

A visitor will enter the relevant information (data) and send the form by clicking the send/submit button. The contents of the form will go to an email address that is coded into the script. When a visitor enters their email address, this lets the recipient know the address and allows them to reply to the visitor.

The form is written in HTML and appears on a page on a website. The form in itself does nothing, it simply gathers user-entered data. When the visitor hits the submit button, their browser passes on the form information in a particular way to the form processor script. The script is written in a programming/scripting language (PHP for example). It is the script that does the work. It will typically validate the data, then send it by email to a specified recipient.

The email address of the recipient is coded into the script. Previously this email address was coded into the HTML of the form in a hidden field. This proved to be very bad for two reasons: 1. The email address was visible to the outside world in the source code of the webpage. 2. It allowed spammers to pass email addresses to the script which would then relay spam messages.

The form processor script resides on the web server. The contents of it are not visible to the outside world. It is what is known as a "server side" script. The script is not downloaded to the visitor's browser when a form is submitted to it. It just sits there and does its job. It might issue error messages, in which case it will output these to the visitor's browser. It might also issue a "thank you" message to the visitor's browser. In both cases it's just the message that is downloaded.

The browser needs to know where to send the form data. It needs to know the location of the form processor script. It gets this information from the "action" attribute of the <form> tag in the HTML code. Here is an example opening HTML <form> tag:

<form action="FormToEmail.php" method="post">

The above example tells the browser that the form processor script is called FormToEmail.php and that it is in the same directory/folder as the form, so the browser knows where to send the submitted data.

The script can be anywhere, it can be in a different directory/folder or even be on a different server, so you might see form actions like these:

<form action="/support/contact/FormToEmail.php" method="post">

<form action="" method="post">

The above examples show the "post" method. Forms can also be sent using the "get" method. Like this:

<form action="FormToEmail.php" method="get">

The main difference between the two is visibility. With the "post" method the submitted data is not seen. With the "get" method the submitted data is appended to the URL (action) of the form, and shows in the address bar of the browser, like this example:

To recap. You have a form on a webpage written in HTML, you have an "action" in the form code that tells the browser the location of the form processor script which handles the submitted form data. When the form is submitted, the data goes to the script and gets processed, any errors are issued then the script sends an email to a specified recipient and issues a thank you message. This is a typical procedure.

How do you specify a recipient for the email that the script sends? This is coded into the script. This is one huge advantage of modern form processors because it virtually cuts spam relaying at a stroke. The outside world cannot see the script code and cannot access it. A form processor script is just a plain old text file. The code is written in text. You can open the script in any text editor, such as Notepad. The email address is coded into the script by opening the script in a text editor, entering the email address at the appropriate place then saving the script and uploading it to the webserver.

The script can contain any number of email addresses and will send the form data to them. It can also issue an autoresponse wherby it will send an email to the person who submitted the form (this assumes that the form had an email input where the visitor entered their email address). Equally, some forms have a choice of recipients that the visitor can choose from. The email addresses of the recipients are not shown on the form but are coded into the script.

In addition to sending an email, the script can attach a file (or files) to the email. Typically this would be a file that the visitor uploads from their own computer via a file input on the form. The file is uploaded to the server where the form processes it and attaches it to the email. The script can also attach any file it has access to, not just a file uploaded by a visitor.

Additionally the script can output the form data to another file, such as a CSV (Comma Separated Values) file and store a copy of it on the server or attach it to the email. There is virtually no limit to what the script can do with the submitted data but this primer is concerned with form-to-email which is a very common protocol.

Why use a form? Why not just invite the visitor to send you an email? Using a form in conjunction with a modern form processor script, means that you do not need to display your email address on your website. This means that spammers do not have access to it and automated email harversters do not have access to it either. It allows you to have control over the submitted data. It allows you to structure it in a way that you can deal with easily when you receive the email. Take an order form for example, it is so much easier to handle the data when structured in a consistent manner rather than simply asking the visitor to send you an email with their requirements. Using a form and script also allows you to validate the submitted data. You might have required fields, you might have options from a list that you want the visitor to select from, you might want to check the syntax of a submitted email address, you might want to check for rude words. All of this (and more) can be done with a form and a script.