Recycled addresses, spamtraps and sensors

A few hours ago I was reading an ESP blog post that recommended removing addresses after they were inactive for a year because the address could turn into a spamtrap.  That is not how addresses turn into spamtraps and not why we want to remove active addresses. Moreover, it demonstrates a deep misunderstanding of spamtraps. Unfortunately, there are a lot of myths and misunderstandings of spamtraps in general.

The wrongness here is that any company doing even a half-assed job at bounce handling isn’t going to suddenly discover they’re mailing spamtraps. Yes, some ISPs have, in the past, turned abandoned addresses into spamtraps. Hotmail did it once back in the early 00’s. After that, it became common knowledge that all the mail providers were recycling addresses on a regular basis. Of course, the providers weren’t going to correct this, because it actually had the effect of many mailers being better citizens.

The reality is recycled addresses aren’t a major part of ISP filtering schemes these days. Recycling address  into spamtraps takes work and a lot of time. At a bare minimum addresses must bounce for 12 months. Then they can start receiving mail again, but the mail must be examined to see what is valid and what is invalid mail. One cable provider I spoke with back in 2009 had employees unsubscribing from legitimate looking mail as part of their trap conditioning process. This provider eventually decided that the data wasn’t good enough to justify the work and gave up trying to use recycled traps.

I spend a lot of much time and energy talking about traps, removing traps, fixing the “spamtrap problem.” I can’t count the number of times I’ve been asked by an ESP, “How many pristine spamtrap hits should we allow before we cut off the customer? 3? 5? 10? What about recycled traps?” This all relates to the data from sensor networks multiple companies are providing. To be fair, public documents from both companies don’t call their sensor networks spamtraps. But every sender I know who has access to the data calls them spamtraps.

It frustrates me to no end because I know that these ESPs are really trying to do the best they can with the data they have. And having access to sensor network data is so appealing. They feel like a magic bullet to determining which customers are good and which customers are bad. But when we’re talking about sensor networks, we’re talking about addresses that would simply have hard bounced a few years ago. If you’re going to cut a customer off for hitting 3 or 5 or 10 pristine trap hits from one of the sensor networks, then you should also cut customers off for attempting to send mail to any non-existent domain. There Is No Difference.

This isn’t a new belief of mine. Back in 2014 I was using a presentation deck with this slide:

It’s even more true now that any abandoned domain can be part of a sensor network. Every address on a list that is not deliverable should be treated the same

What does all this mean? It means we need to rethink how we’re monitoring customers and email addresses. Lines are getting blurry and the difference between a spamtrap and a NXDomain or unknown address is all in who owns the address.

Other WttW Spamtrap Posts:

Related Posts

What’s a bounce?

Bounces and bounce handling is one of those topics I’ve avoided writing about for a long time. Part of my avoidance is because there are decades of confusing terminology that hasn’t ever been really defined. Untangling that terminology is the first step to being able to talk sensibly about what to do. Instead of writing a giant long post, I can break it into smaller, more focused posts.

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

February 2017: The Month In Email

Happy March!

As always, I blogged about best practices with subscriptions, and shared a great example of subscription transparency that I received from The Guardian. I also wrote about what happens to the small pool of people who fail to complete a confirmed opt-in (or double opt-in) subscription process. While there are many reasons that someone might not complete that process, ultimately that person has not given permission to receive email, and marketers need to respect that. I revisited an older post on permission which is still entirely relevant.
Speaking of relevance, I wrote about seed lists, which can be useful, but — like all monitoring tools — should not be treated as infallible, just as part of a larger set of information we use to assess deliverability. Spamtraps are also valuable in that larger set of tools, and I looked at some of the myths and truths about how ISPs use them. I also shared some thoughts from an industry veteran on Gmail filtering.
On the topic of industry veterans, myths and truths, I looked at the “little bit right, little bit wrong” set of opinions in the world of email. It’s interesting to see the kinds of proclamations people make and how those line up against what we see in the world.
We attended M3AAWG, which is always a wonderful opportunity for us to catch up with smart people and look at the larger email ecosystem and how important our work on messaging infrastructure and policy really is. I was glad to see the 2017 Mary Litynski Award go to Mick Moran of Interpol for his tireless work fighting abuse and the exploitation of children online. I also wrote about how people keep wanting to quote ISP representatives on policy issues, and the origin of “Barry” as ISP spokesperson (we should really add “Betty” too…)
Steve took a turn as our guest columnist for “Ask Laura” this month with a terrific post on why ESPs need so many IP addresses. As always, we’d love to get more questions on all things email — please get in touch!

Read More