Reasons Why Scripts Won't Send Email

Here are some reasons why scripts don't send email as they should -- why everything else works, but no email arrives.

1. The location of sendmail is incorrectly specified.

   A common typographical error is forgetting to type the first slash character. Another common error is spelling the "usr" directory as "user".

   Example of incorrect:

   user/bin/sendmail -t
   
   

   Example of correct:

   /usr/bin/sendmail -t
   
   

   Also, the sendmail location is case sensitive. Its location is almost always all lower-case.

   Your hosting company can tell you the sendmail location to use with Perl CGI scripts. Or, you can consult Master Pre-Installation Tester from /software/pit/

   When the location of sendmail is incorrect, the script can't send anything to it for emailing.

2. The -t flag isn't specified.

   With the -t flag, scripts format an email, headers and all, and then send it to sendmail. The sendmail program scans the header lines of the email it received to determine its destination.

   Almost all Perl CGI scripts that use sendmail for emailing also utilize the -t flag. It's easier, and it's more secure.

   However, not all scripts require that you include the -t flag when you specify the sendmail location:

   1. Some scripts require that you include the -t flag. If you don't, the script will error.

   2. Some scripts require that you do not include the -t flag; the script adds the flag to the sendmail location automatically. If you add the -t flag when you specify the sendmail location, in this case, the script will error.

   3. Some scripts don't care whether or not you add the -t flag. The script checks, and if you haven't added the flag then the script does it for you. (Most Master Series CGI programs work this way.)

   If you're unsure whether or not to add the -t flag when you specify the sendmail location, see the instructions or the example. If neither instructions nor example exist, first try adding the flag and, if that doesn't work, remove it.

3. The script is sending the email to an invalid email address.

   To check whether or not the email address the script is sending to is valid:

   1. Open your regular email program and start a new email.

   2. Copy the email address the script is trying to send to.

   3. Paste the email address into the destination area of the new email in your email program. (It is important to copy and paste, otherwise an unseen typographical error won't be transferred.)

   4. Send the new email.

   5. Check whether or not the new email arrives.

4. The sendmail program won't send email to a domain on the same server it is installed on.

   Some sendmail programs are configured so they won't send email to the same domain the script is on or to any domain on the same server.

   If you suspect the email address your script is sending to is on the same server as the sendmail program, you can check it by using a different email address. Give your script a new test email address you are certain is not on the same server, like a @hotmail.com address.

   If the script successfully sends to the new test email address, then inform your hosting company of your tests and ask them to investigate and correct the problem.

5. The sendmail program won't send email to any domain except domains on the same server it is installed on.

   Although this might be intentional, it's probably an inadvertent side effect when the hosting company installed spam fighting software.

   Whether intentional or inadvertent, the hosting company will need to fix it before your script will work.

6. Your hosting company has outgoing email restrictions.

   Some hosting companies (probably in an effort to fight spam) do one or more of the following:

   1. Limit the number of emails that scripts on their servers can send out.

   2. Allow only previously authorized accounts or scripts to send email.

   3. Filter outgoing email for spam-like characteristics.

   If any of the above apply to your account, your hosting company will need to fix things so you can send email with your script. Although the last item might be circumvented by changing the email, it is best not to have the filter applied to you at all.

7. The company where the email box is located has incoming mail filters in place.

   The hosting company or ISP, wherever the destination email box is at, in its fight to control spam, may have installed incoming email filters. Email that doesn't pass the filters may simply be deleted from the system, which may be the fate of the email your script is sending.

   You can test by having the script send an email to a box at a different ISP, one that doesn't apply filters.

8. The person supposed to receive the email has email filters in place.

   Filters at the email's final destination can be:

   1. Stand-alone software that scans the email box contents before downloading.

   2. Software that works with, or is built into, the email program and scans emails as they are being downloaded or immediately upon receipt.

   3. Software integrated into a personal firewall.

   4. Software operating in conjunction with virus protection.

   Filters for the above software can usually be adjusted for strictness. Some allow the filtering rules themselves to be adjusted. Some use public black-lists (be careful with these, some black-lists contain a high proportion of erroneous entries).

   Most of the above software can be told to filter matches into a special folder. Look in this folder to see if the email from your script has been flagged as spam.

The above seem to be the most frequent reasons why a script won't send email or the email it sends doesn't arrive at its destination.

The problems presented by the use of filters are the result of spam, of course. People get too much of it, they complain, and ISP's and hosting companies implement filters and barriers in attempts to stem the tide.

In addition to changing the outgoing email to be less spam-like (according to email filters), here are three things that might, in some cases, trigger a filter rule:

1. Lack of a From: header line.

   If you can find where your script creates the other header lines ("To:", "Subject:", and maybe others), you may be able to insert a From: header line for the script to use. Example:

   From: yourname@yourdomain.com
   
   

   See the multi-part "How To Send Email With Perl" article series linked from /library/ for information about how scripts send email. This might help you when inserting a From: header line.

2. Many office/home computer email programs add an X-Mailer: header line to outgoing email. It identifies the program used to send the email. Here is an example:

   X-Mailer: AnyMail, Version 2.0
   
   

   Lack of an X-Mailer: header line, or one that identifies an email program often used for spamming, might trigger a filter rule.

   If that is the case, the solution is to insert an X-Mailer: header line for the script to use in outgoing email -- just make up a mailing program name for your script.

   See the previous item for information about inserting header lines.

3. When a Perl script uses sendmail, sendmail generates what is sometimes called an "envelope" line. This is inserted at the beginning of the email, immediately above the headers. It consists of the word "From" (no colon character follows this "From") followed by an identification and a date.

   The identification can be the username of your hosting account or an email address. Often, sendmail uses the account username instead of an email address. Many office/home computer email programs, on the other hand, use an email address as identification in the envelope line.

   Username instead of email address might trigger a filter rule.

   You can force sendmail to insert an email address in the envelope line instead of a username. It's done with the -f flag.

   To use the -f flag, add a space after the -t, then -f and the email address you want used in the envelope line. Note that there is no space between the -f and the email address. Here is an example:

   /usr/sbin/sendmail -t -fmyname@domain.com
   
   

As previously stated, there can be other reasons why a script isn't sending mail or why email isn't being received. But one or another of the above will apply to most cases.

Will Bontrager