Sending Mail via the Web

Mr. Lerner continues his look at building a simple, integrated mail system that can be accessed using a web browser.
Moving to the Web

Now that we have seen how to send mail from within our program, we can concentrate on how to create a simple mail-sending facility from within a CGI program. Listing 1 shows an initial stab at send-mail.pl, which is a CGI wrapper around the above functionality.

Listing 1.

As you can see from the top of the program, send-mail.pl imports a large number of modules before it gets down to business. It uses strict and diagnostics to ensure our variables are lexicals (i.e., temporary variables defined with my), only hard references are used, and barewords are not considered subroutine calls. (Bareword is a Perl term for a word in which its use in a program is unclear. Originally, any such words were simply prohibited. Now that subroutines can be called without a leading &, barewords are interpreted as subroutines. This can confuse programmers and lead to buggy programs, so it is usually best to avoid them.)

Then, because this is a CGI program, we import the CGI.pm, a module which provides us with all the CGI functionality we could imagine, useful for receiving user input and sending output to a web browser. We also import CGI::Carp, which provides us with improved messages in the web server's error log. By importing the fatalsToBrowser symbol from CGI::Carp, we also ensure that fatal error messages are sent to the user's browser, as well as the error log. Normally, a fatal error in a CGI program results in an incomprehensible numeric error message on the user's browser. While the output from fatalsToBrowser might not seem much more useful or comprehensible to a non-programmer, it is not as scary as a set of numeric codes. Also, it makes the program much easier to debug than it would be otherwise.

Finally, we import Mail::Sendmail as described previously.

Other than retrieving three HTML form parameters (sender, recipient and message) and using them in the invocation of Mail::Sendmail::sendmail, this program contains little you have not seen before. We do want to ensure the mail is sent before reporting it has been, so we use die to exit with a fatal error; it will end the program after printing an error message to the user's browser and the error log.

We can determine if the mail was sent by checking the return value from the “sendmail” subroutine. If it returns true, we know the mail was sent. If it returns false, the program stopped before it was sent. Here is one simple way to accomplish this:

if (sendmail %mail)
{
# Print a message for success
}
else
{
die "Error sending mail: $Mail::Sendmail::error \n";
}

The variable $Mail::Sendmail::error (i.e., the variable $error inside of the package Mail::Sendmail) contains a detailed description of why the mail was not sent. Since the sendmail subroutine returns true when it succeeds and false when it fails, the above construct tells Perl, “try to send the mail contained in %mail--and if you cannot, exit and print a message describing why it failed.”

If the mail is sent successfully, the user is returned a message indicating the program performed its task. It also prints the contents of the mail. Giving the user detailed feedback of this sort is always better than printing a simple “success” message, since the user might not be sure which e-mail message is being referenced.

Creating the Form

Now that we have a CGI program capable of sending mail, we need some way to invoke it. We could pass parameters as name-value pairs in the URL, but that is difficult and not very user friendly. We will thus send the name-value pairs using POST, which sends them to the program's standard input (STDIN). POST input to a program is generally sent from an HTML form. Here is a sample form that invokes send-mail.pl:

<HTML>
<Head>
<Title>Send e-mail!</Title>
</Head>
<Body>
<H1>Send e-mail!</H1>
<Form method="POST"
  action="/cgi-bin/send-mail.pl">
<P>Sender: <input type="text" name="sender"></P>
<P>Recipient: <input type="text"
  name="recipient"></P>
<P>Message:</P>
<textarea cols="60" rows="20"
  name="message"></textarea>
<P><input type="submit"></P>
</Form>
</Body>
</HTML>

This form has three elements, named sender, recipient and message. These are the same elements we retrieved with the param method in send-mail.pl. If you modify the names of the parameters in the HTML form, make sure to modify the program as well, or the form elements will not be picked up.

All HTML form elements are sent as name-value pairs in which the value is a text string. The CGI program receiving and interpreting the data does not know, and furthermore does not have to know, whether the input field was a text field, a text area, a check box, a radio button or a pull-down menu.

Indeed, we can even substitute a hidden field—which does not appear on the web browser and cannot be changed by the user—for a text field, which comes in handy if we want to hard-code a value, such as that of the recipient. Simply replace the recipient line with

<input type="hidden" name="recipient"
value="reuven@lerner.co.il">

and all mail will be sent to my address.

Similarly, if you want to allow people to send mail to a number of addresses, but still restrict them somewhat, you can use a selection list:

<select name="recipient">
<option value="reuven@lerner.co.il">Reuven
<option value="eviltwin@lerner.co.il">Reuven's evil twin
<option value="ljeditor@linuxjournal.com.com">LJ editor
</select>

Changing our HTML form in any of these ways requires no changes to our CGI program. Once again, send-mail.pl expects to receive a name-value pair in which the name is recipient and the value is a valid e-mail address.

With the above form and CGI program in place, we should be able to send mail to any e-mail address on the Internet.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix