Naming Names

One of the things that regularly happens at email conferences is a bunch of representatives from various ISPs and sometimes deliverability companies get up on stage and entertain questions from the audience about how to get email to the inbox. I’ve sat in many of these sessions – on both sides of the stage. The questions are completely predictable.
Almost invariably, someone asks if they can quote the ISP representative, because there is this belief that if you connect a statement with an employee name that will give the statement more weight. Except it doesn’t really. People who aren’t going to listen to the advice won’t listen to it even if there are names attached.
A lot of what I publish here is based on things the ISP reps have said. In some cases the reps actually review and comment on the post before I publish it. I don’t really believe attaching names to these posts will make them any more accurate. In fact, it will decrease the amount of information I can share and will increase the amount of time it takes to get posts out.
Last night I was joking with some folks that I should just make up names for attribution. Al did that many years ago, coining the pseudonym Barry for ISP reps. Even better, many of the ISP employees adopted Barry personas and used them to participate in different online spaces. Barry A. says X.  Barry B. says Y.  Barry C. says W. Barry D.
It doesn’t matter what names I attach.
I think I’m going to start adding this disclaimer to the appropriate blog posts:
Any resemblance to persons living or dead should be plainly apparent to them and those that know them. All events described herein actually happened, though on occasion the author has taken certain, very small, liberties with narrative.
Because, really.
 

Related Posts

Delivery problems are not all spam related

Not every delivery failure is due to poor reputation or spam. Sometimes ISPs just have problems on their mailservers and so mail doesn’t get through. It’s often hard for delivery experts (and their bosses and their customers and their clients) to watch email delays or rejections without being able to do anything about it.
Sometimes, though, there is nothing to do. The rejections are because something broke at the ISP and they have to sort through it. Just this week there’s been a lot of twitter traffic about problems at a major cable company. They are rate limiting senders with very good reputations. They have admitted there is a problem, but they don’t have a fix or an ETA. From what I’ve heard it they’re working with their hardware vendor to fix the problem.
Hardware breaks and backhoes eat fiber. Yes, ISPs should (and all of the large ones do) have backups and redundancies. But those backups and redundancies can’t always handle the firehose worth of mail coming to the ISPs. As a result, the ISPs start rejecting some percentage of mail from everyone. Yahoo even has a specific error message to distinguish between “we’re blocking just you” from “we’re shedding load and temp failing everyone.”

Read More

Truth, myths and realities

For a long time it was a known fact that certain ISPs recycled abandoned addresses into spamtraps. There were long discussions by senders about this process and how it happened. Then at a conference a few years ago representatives of ISPs got up and announced that they do not recycle addresses. This led to quite a bit of consternation about how deliverability folks were making things up and were untrustworthy and deceptive.

In the early 2000’s ISPs were throwing a lot of things at the wall to deal with mail streams that were 80 – 90% bulk. They tried many different things to try and tame volumes that were overwhelming infrastructure. ISPs did try recycled traps. I know, absolutely know, two did. I am very sure that others did, too, but don’t have specific memories of talking to specific people about it.
At that time, a lot of deliverability knowledge was shared through word of mouth. That turned into a bit of an oral history. The problem with oral history is that context and details get lost. We can use the story of the ISP that did/did not recycle traps as an example.
Deliverability folks talk about an ISP that recycles traps. They don’t mention how often it happens. Some folks make the assumption that this is an ongoing process. It’s not, but anyone who knows it’s not risks violating confidences if they correct it. Besides, if senders believe it’s an ongoing process maybe they’ll be better behaved. Eventually, the story becomes all ISPs recycle traps all the time. This is our “fact” that’s actually a myth.
Then an ISP employee goes to a conference an definitively states they don’t recycle traps. I believe he stated the truth as he knows it to be. That ISP moved on from recycled traps to other kinds of traps because there were better ways to monitor spam.
We were talking about this on one of the deliverability lists and I told another story.
[ISP] recycled addresses once – back when JD was there which must have been, oh, around 2005/6 or so. I heard this directly from JD. It wasn’t done again, but a whole bunch of people just assumed it was an ongoing thing. Since my knowledge was a private conversation between JD and me, I never felt comfortable sharing the information. Given the circumstances, I’ve decided it’s OK to start sharing that end of the story a little more freely.
No one set out to create a myth, it just happened. No one intended to mislead. But sometimes it happens.

Read More

iOS List Unsubscribe Functionality

Al did a great post over on Spamresource about the how the new list unsubscribe function in the default mail client from iOS10. What’s been interesting to me is how much I’m hearing from ESP folks about how their customers want it gone.
If you don’t know what we’re talking about, in the default mail client on iOS10, Apple is now offering a way to unsubscribe from list mail by placing an unsubscribe link at the top of the message.
ListUnsub
As you can see, this isn’t just for commercial mail, it’s in place for every mailing list that has a List-Unsubscribe header. (This is a screenshot from something I posted to OI this morning). For me, it’s somewhat intrusive. I’m on a lot of discussion lists – technical, marketing, business and even a couple social ones. Reading them on my phone has become a challenge, as every email in a thread contains the “unsubscribe” button now.
Luckily, you can dismiss the message for all posts to that mailing list by hitting the ⮾⮾⮾⮾x. Interestingly, once you’ve turned it off there seems to be no way to turn it back on for that list.
Senders have different complaints, however, they do not have to do with intrusiveness or usability issues.
I’ve heard complaints about placement and about how easy it makes it to unsubscribe. One person even stated that everyone knows the place for an unsubscribe is at the bottom of a message and it should never be at the top of a message. I find these arguments unpersuasive. Unsubscribing should be easy. Unsubscribing should be trivial. People should be able to stop getting mail on a whim. Particularly here in the US, where unsolicited mail is legal, being able to quickly opt-out is the only thing keeping some of our mailboxes useful.
I’ve also heard some concerns that are a little more understandable. One company was concerned that unsubscribes go directly to their ESP rather than directly to them. This is a somewhat more understandable concern. Good senders use unsubscribes as part of their KPIs and as part of their campaign metrics. They know how much an unsubscribe costs them and will use that as part of their metrics for defining a successful campaign. Still, though, it’s not that big a concern. ESPs are already handling these kinds of unsubscribes from providers like gmail and hotmail.
Almost 7 years ago I blogged about a sender who wanted an unsubscribe link in the email client. It was a bit of snark on my part. The interesting part, though, is that some senders want unsubscribe mediated in the client and others things it’s horrible. I think this tells me that there’s no universal right answer. It Depends might be the most hated statement in deliverability, but it is the absolutely the reality of the situation.
 
 

Read More