mail() returns TRUE if the email is accepted for delivery. This does not guarantee that the email will be delivered.

Internet email is an unguaranteed delivery system.

Email messages can be lost at any point between your MTA and your user's MUA. This is often caused by a catastrophic disk failure on an MTA, combined with inadequate backups. When email messages are lost, there is no automatic mechanism to trigger re-sending the email message. Lost email messages are never delivered to the intended recipient.

A more common problem is email messages that get rejected by the user's MTA. Causes include

• Inbox over quota

• Email too large to accept

• Disabled user account

• Misspelled email address name

• Virus scanner detected a virus in an attachment

When an MTA rejects an email message, it normally sends back the email message with a description of why the email was rejected. These 'bounced' email messages are never delivered to the intended recipient.

If the email message is successfully delivered to the intended recipient, this can still cause problems. The user might use a filter that bounces email from senders not in a whitelist. The user might have set up a vacation auto-responder, which automatically sends back a message saying that the user is currently out of the office.

It's therefore essential that your PHP application can cope with these situations:

• Every single email you send should have a valid Reply-To: header, to allow receipt of bounced email messages. You should set up a mailbox just for bounces to emails sent from your PHP scripts. It's a good idea to have someone go through the mailbox once a day, just in case there is anything you can do about the bounced email.

• Normally, there should be a way for the user of your PHP script to make your script send the email again.

• Any order confirmations, receipts, and invoices that you send via email should also be available through some other means—either via your website, or via snail mail. Apart from being good customer service, many of these documents are legally important.

Further Reading

The standards for email handling are defined by the RFC series of documents, which you can find at http://www.rfc-editor.org/.

• RFC's 821 and 822 are the current standards on SMTP and plain-text emails, respectively.

• RFC's 2045, 2046, 2047, 2048, and 2049 define the MIME standard.

• RFC 1896 discusses the "text/enriched" MIME content type. This is very similar—but not the same as—HTML email.

• RFC 2557 defines the use of Content-IDs to use attached images in HTML emails.

• RFC 2554 defines the use of SASL for authenticating connections to an MTA.

• Internet Mail Consortium home page http://www.imc.org/. In particular, http://www.imc.org/terms.html is an excellent reference.