Recent Posts

Hunting the Human Representative

Yesterday’s post was inspired by a number of questions I’ve fielded recently from people in the email industry. Some were clients, some were colleagues on mailing lists, but in most cases they’d found a delivery issue that they couldn’t solve and were looking for the elusive Human Representative of an ISP.
There was a time when having a contact inside an ISP was almost required to have good delivery. ISPs didn’t have very transparent systems and SMTP rejection messages weren’t very helpful to a sender. Only a very few ISPs even had postmaster pages, and the information there wasn’t always helpful.
More recently that’s changed. It’s no longer required to have a good relationship at the ISPs to get inbox delivery. I can point to a number of reasons this is the case.
ISPs have figured out that providing postmaster pages and more information in rejection messages lowers the cost of dealing with senders. As the economy has struggled ISPs have had to cut back on staff, much like every other business out there. Supporting senders turned into a money and personnel sink that they just couldn’t afford any longer.
Another big issue is the improvement in filters and processing power. Filters that relied on IP addresses and IP reputation did so for mostly technical reasons. IP addresses are the one thing that spammers couldn’t forge (mostly) and checking them could be done quickly so as not to bottleneck mail delivery. But modern fast processors allow more complex information analysis in short periods of time. Not only does this mean more granular filters, but filters can also be more dynamic. Filters block mail, but also self resolve in some set period of time. People don’t need to babysit the filters because if sender behaviour improves, then the filters automatically notice and fall off.
Then we have authentication and the protocols now being layered on top of that. This is a technology that is benefiting everyone, but has been strongly influenced by the ISPs and employees of the ISPs. This permits ISPs to filter on more than just IP reputation, but to include specific domain reputations as well.
Another factor in the removal of the human is that there are a lot of dishonest people out there. Some of those dishonest people send mail. Some of them even found contacts inside the ISPs. Yes, there are some bad people who lied and cheated their way into filtering exceptions. These people were bad enough and caused enough problems for the ISPs and the ISP employees who were lied to that systems started to have fewer and fewer places a human could override the automatic decisions.
All of this contributes to the fact that the Human Representative is becoming a more and more elusive target. In a way that’s good, though; it levels the playing field and doesn’t give con artists and scammers better access to the inbox than honest people. It means that smaller senders have a chance to get mail to the inbox, and it means that fewer people have to make judgement calls about the filters and what mail is worthy or not. All mail is subject to the same conditions.
The Human Representative is endangered. And I think this is a good thing for email.

Read More

First step in delivery

Ever trawl through your logs and notice that there is a delivery problem somewhere? I’m sure everyone sending email in any volume has.
What’s the first thing you do when you discover a block?

Read More

OOPS!

Y’know those days when it seems everything goes wrong? And you just can’t get it right? A couple companies who send commercial mail have had a day like that.
Yesterday I got an email at 6am from a vendor telling me there was a new, important update to download and install. I put it off because it’s software I don’t use very often and I’m waiting until we have a better idea of our hardware situation before loading too much stuff on my backup laptop. Three hours later, I got another email from the vendor telling me that the link in the email was wrong and here was the right link and they’re sorry for the bad email initially.
Fair enough, stuff breaks and process falls apart and sometimes there are customer facing screw ups. But this vendor wasn’t done! This morning I got a third email telling me that uh, the previous emails were only intended to go out to their Windows using customers, and that the didn’t currently have a Mac version of the software ready. And, well, they’ll email me as soon as they get the Mac version finished.
I made a comment about bad day for mailers and Steve pointed out that he’d gotten 3 different notifications from a shipping company and then a final fourth email that said the company was testing things and they’re sorry for sending multiple test messages out to their whole list this morning.
It’s not even Friday the 13th or anything.

Read More

Forcing those opens

Most email marketers want to see their open rates go up. This particular marketer has come up with a new way to force recipients to load their mail.

Read More

Getting rid of the via at Gmail

There was a question submitted today about the verification process at Gmail.

Read More

Inbox rates and conversion rates

Jeanne Jennings published an interesting bit of research on open rates and inbox rates at ClickZ recently. Essentially she looked at two different industry studies and compared their results.
The first study was the Return Path Global Delivery Survey and the second was the Epsilon North American Trend Results. What Jeanne found is that while Return Path shows a decrease in inbox placement, Epsilon is seeing an increase in average open rate.

There are any number of reasons this could be happening, including simply different ways the numbers are calculated. I am not sure it’s just a numbers issue, though. Many of Epsilon’s clients are very big companies with a very experienced marketing team. The Return Path data is across their whole user base, which is a much broader range of marketers at different levels of sophistication.
I expect that the Epsilon data is a subset of the Return Path data, and a subset at the high end at that. It does hint, though, that when the inbox is less cluttered, recipients are more likely to open the commercial mail that does get in there.

Read More

Ask Ben Lerer anything

Ben Lerer, the co-founder of Thrillist, will be doing an “Ask Me Anything” on Reddit on Tuesday at 10 am.
What is an Ask me Anything? It’s a free wheeling discussion where someone agrees to answer any questions from anyone who posts on Reddit.
Who is Ben Lerer? Ben is the co-founder of Thrillist, a quite successful email business. I worked with Thrillist early on in their business. Their blend of quirky editorials and irreverence drive a very engaged recipient base and great email delivery. Join them tomorrow on Reddit to ask him anything.
Update: Here’s Ben’s AMA.

Read More

Spamtraps mean your list is bad


Spamtraps mean your list is bad. And you should feel bad.
Spamtraps on a list are a symptom, not the disease itself. They’re (usually) a sign of some serious underlying problem, whether it be with address capture, bounce management, list purchase or epending.
We’ve talked about this a lot in the past, but sometimes you need a short summary to refer someone to.

Read More

77% prefer email for marketing

77% of those surveyed preferred email for permission-based promotional messages, soundly beating the next most popular, direct mail, at 9%. Email, still anything but dead.
This, and lots of other interesting things, in ExactTarget’s 2012 Channel Preference Survey.

Read More

The 500 mile email

This is a great story from Trey Harris about a real email delivery issue from the mid 1990s.
Here’s a problem that sounded impossible…  I almost regret posting the story to a wide audience, because it makes a great tale over drinks at a conference. 🙂  The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining.
I was working in a job running the campus email system some years ago when I got a call from the chairman of the statistics department.
“We’re having a problem sending email out of the department.”
“What’s the problem?” I asked.
“We can’t send mail more than 500 miles,” the chairman explained.
I choked on my latte.  “Come again?”
“We can’t send mail farther than 500 miles from here,” he repeated.  “A little bit more, actually.  Call it 520 miles.  But no farther.”
“Um… Email really doesn’t work that way, generally,” I said, trying to keep panic out of my voice.  One doesn’t display panic when speaking to a department chairman, even of a relatively impoverished department like statistics.  “What makes you think you can’t send mail more than 500 miles?”
“It’s not what I think,” the chairman replied testily.  “You see, when we first noticed this happening, a few days ago–”
“You waited a few DAYS?” I interrupted, a tremor tinging my voice.  “And you couldn’t send email this whole time?”
“We could send email.  Just not more than–”
“–500 miles, yes,” I finished for him, “I got that.  But why didn’t you call earlier?”
“Well, we hadn’t collected enough data to be sure of what was going on until just now.”  Right.  This is the chairman of *statistics*. “Anyway, I asked one of the geostatisticians to look into it–”
“Geostatisticians…”
“–yes, and she’s produced a map showing the radius within which we can send email to be slightly more than 500 miles.  There are a number of destinations within that radius that we can’t reach, either, or reach sporadically, but we can never email farther than this radius.”
“I see,” I said, and put my head in my hands.  “When did this start?  A few days ago, you said, but did anything change in your systems at that time?”
“Well, the consultant came in and patched our server and rebooted it. But I called him, and he said he didn’t touch the mail system.”
“Okay, let me take a look, and I’ll call you back,” I said, scarcely believing that I was playing along.  It wasn’t April Fool’s Day.  I tried to remember if someone owed me a practical joke.
I logged into their department’s server, and sent a few test mails.  This was in the Research Triangle of North Carolina, and a test mail to my own account was delivered without a hitch.  Ditto for one sent to Richmond, and Atlanta, and Washington.  Another to Princeton (400 miles) worked.
But then I tried to send an email to Memphis (600 miles).  It failed. Boston, failed.  Detroit, failed.  I got out my address book and started trying to narrow this down.  New York (420 miles) worked, but Providence
(580 miles) failed.
I was beginning to wonder if I had lost my sanity.  I tried emailing a friend who lived in North Carolina, but whose ISP was in Seattle. Thankfully, it failed.  If the problem had had to do with the geography of the human recipient and not his mail server, I think I would have broken down in tears.
Having established that–unbelievably–the problem as reported was true, and repeatable, I took a look at the sendmail.cf file.  It looked fairly normal.  In fact, it looked familiar.
I diffed it against the sendmail.cf in my home directory.  It hadn’t been altered–it was a sendmail.cf I had written.  And I was fairly certain I hadn’t enabled the “FAIL_MAIL_OVER_500_MILES” option.  At a loss, I telnetted into the SMTP port.  The server happily responded with a SunOS sendmail banner.
Wait a minute… a SunOS sendmail banner?  At the time, Sun was still shipping Sendmail 5 with its operating system, even though Sendmail 8 was fairly mature.  Being a good system administrator, I had standardized on Sendmail 8.  And also being a good system administrator, I had written a sendmail.cf that used the nice long self-documenting option and variable names available in Sendmail 8 rather than the cryptic punctuation-mark codes that had been used in Sendmail 5.
The pieces fell into place, all at once, and I again choked on the dregs of my now-cold latte.  When the consultant had “patched the server,” he had apparently upgraded the version of SunOS, and in so doing downgraded Sendmail.  The upgrade helpfully left the sendmail.cf alone, even though it was now the wrong version.
It so happens that Sendmail 5–at least, the version that Sun shipped, which had some tweaks–could deal with the Sendmail 8 sendmail.cf, as most of the rules had at that point remained unaltered.  But the new long configuration options–those it saw as junk, and skipped.  And the sendmail binary had no defaults compiled in for most of these, so, finding no suitable settings in the sendmail.cf file, they were set to zero.
One of the settings that was set to zero was the timeout to connect to the remote SMTP server.  Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.
An odd feature of our campus network at the time was that it was 100% switched.  An outgoing packet wouldn’t incur a router delay until hitting the POP and reaching a router on the far side.  So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by incidental router delays.
Feeling slightly giddy, I typed into my shell:

Read More
Categories
Tags