Receivers take advantage of "Store and Forward", and so should senders

Recently I shed some light on what happens behind the scenes when an email message is sent on its way. The "store and forward" model is not a perfect guarantee of delivery, but is very robust in the face of temporary breakdowns. You may have noticed, however, that if a message has to be passed along through several "hops", only the final "hop" can determine exactly when or even whether the message has reached its intended recipient. To deal with this, the Simple Mail Transfer Protocol (SMTP), the standard way to transmit email over the Internet, defines all the elements necessary to complete a successful transfer of email and to report either a temporary service interruption or a complete failure.

This is where notification messages come in. Often appearing to come from some cryptic sender such as a "Mailer Daemon" (which is just another name for mail transport software), notifications tell us that a recipient does not exist or that a mailbox is full, or about other errors. Each of the "hops" through which a message passes, including the last, may send back one of these "bounces" to let you know that something unexpected is happening to your email.

It's also possible for a sender to request that a notification be sent at final delivery when everything has gone right. Keith Moore's lament, as the NYT reported, is that end-user email software rarely makes it simple enough to answer such a request for it to be worth the sender's effort to ask.

Part of the reason for using the store and forward email model and this system of notifications is its ability to allow receivers of email to make assertions about the availability of their resources. Returning to the analogy of the phone call, when a particular mail exchanger is becoming overloaded, it can "answer the phone" but then immediately request that the sender "call back later," confident that the sender has stored a copy of the message for later forwarding. When you hear the term "soft bounce," it refers to such a delay.

Increasingly, however, receivers are using the "call back later" mechanism to control on the rate at which they accept email from any particular source as a matter only of policy, not of necessity. Recently, the operator of one of the most venerable newsletters on the Internet reported that his deliveries were being blocked by a major ISP. In fact, that ISP was engaging in a delaying tactic, repeatedly asking that the newsletter sender wait and try again.

Intentional delays are, of course, not the only kind. It is rare, for example, that the computer that acts as a mail exchanger is the same one that eventually places the email in a recipient's mailbox, and even more rare for that to be the same computer that eventually presents the email to the recipient. The store and forward model is as prevalent in the systems employed inside domains as it is outside, so it is always possible that a delay is introduced at some point.

So is there anything that you, as an email sender, can do about this? Yes. Remember that the nature of store and forward is to give email the best chance of eventually arriving. It may not get there in an instant, but the chances are that it will get there. This is critical to keep in mind when planning email marketing campaigns. Do you have a last-minute offer? Consider sending it to a smaller, more actively responsive list of recipients, or include a consolation offer so the email remains relevant to those who miss the deadline through no fault of their own. Announcing a one-time event? Plan ahead so there is time for the mail to arrive. You may want to consider a second reminder email, sent closer to the date but only to those who have already reacted to the initial announcement.

Email has persistence by design, as well as (usually) immediacy. It's wise to exploit both.