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

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

Reputation

Reputation is the buzzword in delivery these days. Everyone talks about building a good reputation and how to do it. Makes sense, the ISPs are always hammering on reputation and how critical reputation is. The more I talk with delivery folks on the ESP side of thing, the move I realize that there is a fundamental disconnect between what the ESPs mean when they say reputation and what the ISPs mean when they say reputation.
Many people handling delivery think that the bulk of reputation is wrapped up in complaint rates and bounce rates. I think they know the ISPs measure more than just complaints and bounces (spamtraps!) but really believe that most of developing a good reputation is all about keeping those complaints low.
This perspective may have been true in the past, but is becoming less true as time goes on. There are a lot of very smart people managing incoming mail at the ISPs and they are constantly looking for ways to better meet the desires of their customers. Lest we forget, their customers are not the senders, their customers are the end users. Their customers are not senders.
Part of meeting the needs of end users means actually giving them a way to provide feedback. AOL started the trend with the this-is-spam button, and other ISPs (ones that controlled the user interface at least) followed suit. For a very long time, reputation was dominated by complaint percentages, with modifiers for number of spamtrap addresses and number of non-existent users.
The problem is, these numbers were easy to game. Spammers could modify their metrics such that their email would end up in the inbox. In response, the ISPs started measuring things other than complaints, bounces and spamtraps. These other measurements are strong modifiers to complaints, such that mailers with what used to be acceptable complaint rates are seeing their mail end up bulked or even rejected.
Recently, AOL seems to have made some subtle modifications to their reputation scores. The result is mailers who have previously acceptable complaint rates are seeing delivery problems. When asked, AOL is only saying that it is a reputation issue. Lots of senders are trying to figure out what it is that is more important than complaints.
Tomorrow, I will talk about what I think AOL could be measuring.

Read More

Spike in Yahoo error codes

A number of people have mentioned over the last couple weeks that they’re seeing a spike in Yahoo rejecting mail with
554    delivery error: dd Requested mail action aborted
Discussions on various mailing lists indicate these messages are related to inactive accounts. Addresses that bounce at Yahoo with these codes should be handled as inactive addresses and removed from future mailings.

Read More