Email From Scripts

Although you cannot relay e-mail through our servers from your normal mail client you can of course send e-mail out from our servers using a variety of methods including Perl CGI, PHP, Java servlets, Python, C and so on.

When configuring your server-side software you should normally send e-mail through the sendmail program located on all servers at:-

/usr/lib/sendmail

Some technologies such as PHP are preconfigured to do this when using their standard mailing functions.

We recently added fairly strict anti-SPAM measures to all our shared servers. This was necessary in order that we could properly manage out going e-mail, to be certain who's code was sending e-mail, and to avoid excessive bounces and/or loops. The changes also close up an exploit in use widely with formmail.cgi

The rules that any script or code sending out e-mail from a shared server are as follows:-

1) e-mail addresses in BOTH the To: and the From: headers must contain valid e-mail domains, ie. with valid DNS MX Records.

2) One of EITHER the To: OR the From: e-mail addresses must be using a domain name known to the shared server. This in most cases will be the domain name you use with your web site.

In some cases point 2) may be a problem if your domain e-mail is not handled by us but by a third party and we have no known domain on our server. In this case we can add a particular domain to be allowed, please ask.

Point 2) may also require that some scripts which need to send e-mail from an unknown user to an unknown user (something which effectively provides an Open mail relay and is fairly bad practise anyway, but is often used with e-postcard type scripts) to be altered so that the From: header contains your own domain related e-mail address but the Reply-To: header contains the address you wish replies to go to.

Please note that prior to us making these changes an unqualified address (ie, one with no @ sign or domain name) would have been automatically qualified with the full server name (@proton.positive-internet.com for example). These addresses will no longer work, all e-mail addresses in the From: and the To: header must be fully qualified (ie. have an @ sign and a domain)

We appreciate that this is by no means a perfect solution and could still potentially allow 3rd party abuse to continue, however it does reduce the likelyhood of abuse and also ensures that we can identify and correct any source of outgoing e-mail from PHP or CGI scripts. An alternative to this would have meant a complete audit of all PHP and CGI code on our servers and then enforced control and vetting of all scripts prior to their use in the future. We felt the methods we have chose provide the maximum flexibility and at the same time protect all shared users from the serious issue of total e-mail blacklisting affecting all outgoing and incoming e-mail.

If you would like us to examine any particular form or script to advise on where changes could be made or why you are now getting a particular error we will be happy to do so. Please provide us with the full URL and path to both the form and the code in question.

Ideally your code should have within it "hard coded" e-mail addresses. If you know that the script will always be sending an e-mail to your info@mydomain.com address for example, then rather than reading this address from any hidden HTML form variables this address should be put within a script configuration file or within the actual mail sending code itself.

Likewise where the From: field is known and is not likely to change, this should not be passed to a script via hidden HTML directives but again hard coded within the code or the codes configuration files.

If you are using PHP's mail functions, it does not by default add a valid From: header to outgoing e-mail. This is important since otherwise all PHP scripts run on the server in Apache module mode would generate the same From: headers and tracking down the source of any particular e-mail would be extremely difficult.

When using PHP's mail function therefore you need to manually code in the From: header using the functions extra header parameters.

Since our server is very forthcoming and loud about the SPAM protection error, sending the output of the error with a Content MIME header, to standard out and standard error, it's very likely that your site visitors will see it's output if they provide an incorrect e-mail address or their service provider is having DNS/MX record problems.

We suggest that you choose a form script or code which does it's own e-mail address error checking and can intercept the problem before calling our sendmail program in order to provide users with a more friendly and perhaps understandable output either explaining that they may have mistyped their e-mail address or that their service provider may be experiencing DNS problems and to try a different e-mail address or try again later.

You or your developers may also be able to simply add extra checking to existing code.
In Perl the best module to use for this kind of checking is called Email::Valid (type perldoc Email::Valid from the command line for detailed instructions. With PHP you can make use of the getmxrr() function to check the DNS MX records for the domain part of an e-mail address, (explode the address variable using the @ sign to get the domain part or use substr). Search the PHP manual at http://www.php.net/ for getmxrr to get more details.
If you are using Java, dnsjava may be of interest for checking MX records, see http://www.xbill.org/dnsjava/

There are occasions where you cannot know in advance the e-mail addresses being used for both the sender and the receiver. In these cases we urge caution because you may effectively be providing a third party with a free e-mail relay and allowing them to use your web site name and resources to send e-mail (often in bulk) via your scripts. Electronic postcard scripts and friends recommendation scripts are typical examples of such code.

First we would urge you to think carefully about how easy you make it for people to make use of these scripts, a registration process for example at least provides one step extra for any abuser to have to go through to, and most of the time they will choose to move on and use an easier script somewhere else.

Since our spam protection system won't allow a third party or non-specified e-mail address to be used both in the From: and the To: headers these scripts may initially fail anyway. The solution to making them work is to make use of the Reply-To: header.

You should make sure that all postcards, recommendations or similar have a From: header including your own domain, something along the lines of postcards@mydomain.com or recommendations@mydomain.com. The From: header can be made up of more than just a simple e-mail address however, so for instance the Real Name portion of the header could be gleaned from your web form. Let's say for example John Smith sends a postcard to Mary Jane, both of whom have hogmail.com accounts. The outgoing message can have headers as follows:-

To: Mary Jane <maryjane@hogmail.com>
From: John Smith <postcards@mydomain.com>
Reply-To: John Smith <johnsmith@hogmail.com>
Subject: Postcards from heaven

As you can see, the From: header includes the real name, but the From: e-mail address is the generic address with your own domain name. The Reply-To: header with John's e-mail address ensures that when Mary Jane replies to thank him for such a wonderful postcard, he gets the reply straight back.