Email is store and forward

Many of us are so used to email appearing instantaneous, we forget that the underlying protocol was never designed for instant messaging. When the SMTP protocol was originally proposed it was designed to support servers that may have had intermittent connectivity. The protocol allowed for email to be spooled to disk and then sent when resources were available. In fact, almost everyone who was around more than 10 years ago knows of a case where an email took weeks, months or even years to deliver.
These days we’re spoiled. We expect the email we send to friends and relatives to show up in their mailbox within moments of sending it. We expect that sales receipt or e-ticket to show up in our mailbox within instants of a purchase. We expect that our ISPs will get us email immediately, if not sooner.
But there are a lot of things that can slow down email delivery. At several points in the process an email may be spooled to disk. It stays on the spool until the next part of the delivery process can happen. Other points of slowdown include the various anti-spam, anti-virus and anti-phishing protections that ISPs must implement. Then add in the extreme volume of email (around 10 billion messages a day) and all of a sudden email delivery is slower than many senders and recipients expect it to be. This delay is not ideal, but the system is designed so that mail is not silently discarded.
While individual emails may be delayed, most users will rarely see that delay in the email that they send. Bulk senders, who may be sending thousands or hundreds of thousands of emails a day, may see more delays in a single send than the average user sees in years of sending one-to-one email.
Email is store and forward, not instant. Sometimes that means there is a delay in getting email into the recipients inbox. And, sometimes there isn’t anything anyone can do to speed up delivery, except to adjust expectations of how email works.

Related Posts

We want your mail to succeed

One thing I hear from a lot of delivery folks, both consultants and those who work at the ESPs, is that their customers and clients fight back whenever they say no. A client or a customer proposes this great idea that involves sending irrelevant email to uninterested people. Then, with bated breath, they ask their delivery consultant to agree it is a brilliant idea. Most of the time, their great idea is actually a bad idea. Those of us who have been around a while can even and provide examples and experiences that back up that it is a bad idea.
The result is similar, when told their idea will hurt their delivery they fight tooth and nail. On good days they will argue and decide to listen. On bad days they go off and do what they were warned not to do.
It can be horribly frustrating for all of us in the delivery field. We actually want customers’ mail to succeed. We tell customers no, not because we want to ruin their day or their business or their ideas, but because we want to help their business. Our job is to make their email work, and sometimes that means saying no.
Next time your delivery consultant, or your ESP delivery expert, tells you that an idea may cause delivery problems, give them some credit for their experience and expertise. We really do have your best interests at heart and really do want your email to succeed.

Read More

Reputation: part 2

Yesterday, I posted about reputation as a combination of measurable statistics, like bounce rates and complaint rates and spamtrap hits. But some mailers who meet those reputation numbers are still seeing some delivery problems. When they ask places, like AOL, why their mail is being put into the bulk folder or blocked they are told that the issue is their reputation. This leads to confusion on the part of those senders because, to them, their reputation is fine. Their numbers are exactly where they were a few weeks ago when their delivery was fine.
What appears to have changed is how reputation is being calculated. AOL has actually been hinting for a while that they are looking at reputation, and even published a best practices document back in April. Based on what people are saying some of that change has started to become sender visible.
We know that AOL and other ISPs look at engagement, and that they can actually measure engagement a lot more accurately than sender can. Senders rely on clicks and image loading to determine if a user opened an email. ISPs, particularly those who manage the email interface, can measure the user actively opening the email.
We also know that ISPs measure clicks. Not just “this is spam” or “this is not spam” clicks in the interface, but they know when a link in an email has been clicked as well.
I expect that both these measures are now a more formal and important part of the AOL reputation magic.
In addition to the clicks, I would speculate that AOL is now also looking at the number of dead addresses on a list. It is even possible they are doing something tricky like looking at the number of people who have a particular from address in their address book.
All ISPs know what percentage of a list is delivered to inactive accounts. After a long enough period of time of inactivity, mail to those accounts will be rejected. However for some period of time the accounts will be accepting mail. Sending a lot of mail to a lot of dead accounts is a sign of a mailer who is not paying attention to recipient engagement.
All ISPs with bulk folders have to know how many people have the from address in their address book. Otherwise, the mail would get delivered incorrectly. In this way, ISPs can monitor the “generic” recipient’s view of the email. Think of it as a similar to hitting the “this is not spam” button preemptively.
This change in reputation at the ISPs is going to force senders to change how they think of reputation, too. No longer is reputation all about complaints, it is about sending engaging and relevant email. The ISPs are now measuring engagement. They are measuring relevancy. They are measuring better than many senders are.
Senders cannot continue to accrete addresses on lists and continue sending email into the empty hole of an abandoned account while not taking a hit on their reputation. That empty hole is starting to hurt reputation much more than it helps reputation.

Read More

AOL and DKIM

Yesterday, on an ESPC call, Mike Adkins of AOL announced upcoming changes to the AOL reputation system. As part of these changes, AOL will be checking DKIM on the inbound. Best estimates are that this will be deployed in the first half of 2009, possibly in Q1. This is something AOL has been hinting at for most of 2008.
As part of this, AOL has deployed an address where any sender can check the validity of a DKIM signature against the AOL DKIM implementation. To check a signature, send an email to any address at dkimtest.aol.com.
I have done a couple of tests, from a domain not signing with either DK or DKIM, from a domain signing with DK and from a domain signing with both DK and DKIM. In all cases, the mail is rejected by AOL. The specific rejection messages are different, however.
Unsighng domain: host dkimtest-d01.mx.aol.com[205.188.103.106] said: 554-ERROR: No DKIM header found 554 TRANSACTION FAILED (in reply to
end of DATA command)
DK signing domain: “205.188.103.106 failed after I sent the message.
Remote host said: 554-ERROR: No DKIM header found
554 TRANSACTION FAILED”
DK/DKIM signing domain: “We tried to delivery your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554-PASS: DKIM authentication verified
554 TRANSACTION FAILED (state 18).”
As you can see, in all cases mail is rejected from that address. However, when there is a valid DKIM signature, the failure message is “554-PASS.”
As I have been recommending for months now, all senders should be planning to sign with DKIM early in 2009. AOL’s announcement that they will be using DKIM signatures as part of their reputation scoring system is just one more reason to do so.

Read More