This note is aimed at people who are already using a PHP routine to automatically send emails on the BCA web server. (i.e. this is not a PHP email 'tuition' document). For example, you might have an enquiry form, where the customer types an enquiry and his email address; the contents of the form are emailed to you, and a copy sent to the customer.
Summary
To send your customers a sensible-looking email and to avoid bothering the system administrator with your bounces, you should always set both a From: address and a Return Path. The From: address has to be constructed manually as part of the headers argument to PHP's mail() function and the return path is set using the 'additional parameters' argument.
In addition, you should make sure that the return path is a valid email address because some mail servers will simply discard mail that does not have a valid return path. Therefore, if you dont do this, random emails will simply disappear.
Details
In the above scenario – an enquiry form on your web site – a problem arises if the customer types an invalid email address. When the web server attempts to send a message to him it will fail and the mail transport agent (MTA) will attempt to generate a failure notification (a 'bounce' message) but who should it send it to? If you do not tell PHP what to do with bounces they will be sent to the system administrator, which is an annoyance both for him and you!
This note assumes that you already understand* the complexities of generating email messages in PHP (e.g. the required line terminations, line lengths and so on) and it addresses only the problem of setting a correct 'return path' for your automatically generated emails.
*well, OK, you know that headers are separated by \r\n but that the lines of the message are separated only by \n and shouldn’t be > 70 characters? And that you must be careful that the syntax of each of your headers is correct?
Basically, the fifth argument to PHP's mail() function (see http://uk.php.net/manual/en/function.mail.php) is a string representing additional parameters to be passed to the underlying MTA. This is obviously system-dependent, and the following guidance is based on practical observation of the particular set-up currently used on the BCA server. It does not necessarily apply anywhere else! It is known, for example, that the –f parameter is ignored by some MTA installations.
To set an email address of joe@bloggs.name as a return path you should set the fifth argument to mail() to be the string "-fjoe@bloggs.name" with no space between the '-f' and the email address. You should also set a From: address in the 'additional headers', which is the fourth argument to mail() – its arguments being mail($to, $subject, $message, $headers, $parameters). You should specify both a From: address and a return path. If you do not specify both, this is what happens…
- If youre on the BCA web server and you do not specify a return path, the MTA will set a default of nobody@[bca-webserver] and so any bounces will go to the BCA system administrator. (Ive used [bca-webserver] to avoid publishing the actual email address). On other servers, you may get 'nobody@' or perhaps 'anonymous@'.
- If youre on the BCA web server and you do not specify a From: address, the MTA will set the From: username to be 'Nobody' and will take their email address from the Return Path. In other words, if you set a return path of joe@bloggs.name but do not set a From: address then the From: address will default to Nobody <joe@bloggs.name> . If you didn’t set a return path, the From: address would default to Nobody <nobody@[bca-webserver]>.
The other thing you can do to avoid your customers submitting an invalid email address is to test the address before you use it. PHP has routines that will check whether a given domain is valid and whether a given email address has a valid MX record. Unfortunately, in my experience, these do not always work, and particular domains will always return the wrong result. Whether this is due to badly set-up DNS records or what, I dont know, but it happens frequently enough to make this method annoying – i.e. it is annoying for the customer to be told his email address is not valid when he knows that it IS valid.
It is more reliable to simply check that the syntax of an address is correct (and, of course, you can trap typos by making your customer type the address twice). A simple routine in Javascript, to check the syntax of an email address, is
Code: Select all
Function checkEmailSyntax($email)
// If the argument is syntactically correct then return true
// else print a warning message and return false.
{
var $pattern = /^[0-9a-z_]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\.[a-z]{2,4}$/i;
if (!$pattern.test($email))
{ window.alert($email + "\nis not a valid email address"); return false; }
}
