Messaging Commands

Form handlers can send email messages by means of the EXEC_SENDEMAIL command. Email messages are considered to be successfully delivered when a mail server acting for the recipient domain, accepts and acknowleges the message. In the general case, email messages are sent first to a mail server acting for the sender domain. Then unless the sender and recipient domains are the same or the mail server for the sender domain is also a mail server for the recipient domain, the mail server acting for the sender domain will relay the message to a mail server acting for the recipient domain. Applications have a choice. They can follow the general case and send the message to the local mail server, OR they can identify mail servers acting for the recipient domain by a DNS lookup and send the message directly.

The outcome of a DNS lookup can be condensed as follows:-

A message relay to a recipient mail server cannot proceed without knowing the IP addresses of the mail server, so it is essential that either the DNS lookup is a success. The relay can have the following outcomes:-

Note that an SMTP conversation with a recipient domain mail server may be for the purpose of address verification, rather than to relay a message. If so outcomes 4, 5 and 6 are the same and success would be taken as confirmation the address exisited. Note also that outcome 5 is potentially critical as it suggests the originating server IP or the sender domain has been banned by the recipient or worse, placed on a general blacklist. Either would be something that needed investigation but the latter would render the application inoperable as many if not all emails would be blocked.

Email addresses can be malformed but checks for this do not depend on outside servers. They can have errors in either or both the address and domain parts, so the stated domain may exist but the address is invalid or the domian does not exists. It is possible the email address exists but is the wrong one and this must be kept in mind when concocting messages to be sent to unconfirmed addresses. It is recomended practice for web applications keep proper track of previously encountered email addresses. Whilst it is clear email addresses of registered users must be properly tied to users, it also makes sense for forms that are open to submission by anyone (e.g. Contact-Us), to recognize returning contacts.

The HTML response to a form submission will depend on the overall outcome of the form handler commands and it is not acceptable for there to be undue delays. Where the form handler has a EXEC_SENDEMAIL command, this must be quickly concluded. To this end, the application usually performs both the DNS lookup and the message relay. The DNS could be down, making it impossible to determine the validity of the email address. It is not recomended for the DNS to simply be retried. If the lookup is a pre-submission AJAX call, the retry can wait until actual submission. If the lookup is due to submission, by all means store the data but the response should not claim an email is on its way when this cannot be true! Likewise when the recipient mail server(s) are offline (outcome 4). The application can send the email via a mail server. This will do the retries for you but it cannot be assumed to report the outcome in real time. HadronZoo::Epistula reports in real time making it the equivelent of direct action by the application, but Epistula cannot be assumed.

In total there are three ways to invoke the EXEC_SENDEMAIL command as follows:-

Note that EXEC_SENDEMAIL is commonly used in background tasks, in addition to form handlers.