I wrote earlier this week about bad ways to evaluate and choose an ESP. It was all going to end today in an insightful and profound post telling all of you exactly how to find the best ESP.
Then Smartinsights published an insightful and useful article on choosing an ESP yesterday.
So, yeah, just go read what Jordie has to say. I have a couple other things to add, but I’ll drop those in another post.
In the theme of the ongoing discussions about ESPs and their role in the email ecosystem, I thought I’d present some examples of how different ESPs work.
The good ESPs are those that set and enforce higher standards than the ISPs. They invest money and time in both proactive and reactive policy enforcement. On Monday I’ll talk about these standards, and the benefits of implementing these policies.
The typical ESPs are those that have standards equivalent to those of the ISPs. They suspend or disconnect customers when the customers generate problems at the ISPs. They have some proactive policy enforcement, but most of their enforcement is reactive. On Tuesday I’ll talk about these standards and how they’re perceived by the ISPs and spam filtering companies.
The ugly ESPs are those that have low standards and few enforcement policies. They let customers send mail without permission. Some of the ugly ESPs even abuse other ESPs to send some of their mail, thus sharing their bad reputations across the industry. On Wednesday I’ll look at some of their practices and discuss how they affect other players in the industry.
One of my mailing lists was asking questions today about an increase in invitation mailings from Spotify. I’d heard about them recently, so I started digging through my mailbox to see if I’d received one of these invites. I hadn’t, but it clued me into a blog post from early this year that I hadn’t seen before.
Research: ESPs might get you blacklisted.
That article is full of FUD, and the author quite clearly doesn’t understand what the data he is relying on means. He also doesn’t provide us with enough information that we can repeat what he did.
But I think his take on the publicly available data is common. There are a lot of people who don’t quite understand what the public data means or how it is collected. We can use his post as a starting off point for understanding what publicly available data tells us.
The author chooses 7 different commercial mailers as his examples. He claims the data on these senders will let us evaluate ESPs, but these aren’t ESPs. At best they’re ESP customers, but we don’t know that for sure. He claims that shared IPs means shared reputation, which is true. But he doesn’t claim that these are shared IPs. In fact, I would bet my own reputation on Pizza Hut having dedicated IP addresses.
The author chooses 4 different publicly available reputation services to check the “marketing emails” against. I am assuming he means he checked the sending IP addresses because none of these services let you check emails.
He then claims these 4 measures
One of the common statements about blocklists is that if they have bad data then no one will use them. This type of optimism is admirable. But sadly, there are folks who make some rather questionable decisions about blocking mail.
We publish a list called nofalsenegatives. This list has no website, no description of what it does, nothing. But the list does what it says it does: if you use nofalsenegatives against your incoming mailstream then you will never have to deal with a false negative.
Yes. It lists every IP on the internet.
The list was set up to illustrate a point during some discussion many years ago. Some of the people who were part of that discussion liked the point so much that they continued to mention the list. Usually it happens when someone on a mailing list complained about how their current spamfiltering wasn’t working.
Some of the folks who were complaining about poor filtering, including ones who should know better, did actually install nofalsenegatives in front of their mailserver. And, thus, they blocked every piece of mail sent to them.
To be fair, usually they noticed a problem within a couple hours and stopped using the list.
This has happened often enough that it convinced me that not everyone makes informed decisions about blocking. Sure, these were usually small mailservers, with maybe a double handful of users. But these sysadmins just installed a blocklist, with no online presence except a DNS entry, without asking questions about what it does, how it works or what it lists.
Not everyone makes sensible decisions about blocking mail. Our experience with people using nofalsenegatives is just one, very obvious, data point.