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

Don't think bounce handling is important?

James from Cloudmark has his own insight on spamtraps.

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

Why is bounce handling so hard

It should be easy, right? Except it’s not. So why is it so hard?
With one-on-one or one-to-few email it’s pretty simple. The rejections typically go back to a human who reads the text part of the rejection message and adapt and makes the decision about future messages. The software handles what to do with the undeliverable message based on the SMTP response code.
In the case of a 5xy response the server stops attempting delivery and alerts the original sender the mail failed. One example from helping a client troubleshoot a delivery problem recently.

There’s useful information in the text portion of this email from my mail server. It says there was a permanent failure (550) and that my message won’t be delivered. It also says the email is quarantined in reply to the end of DATA. That’s actually a critical piece of information. It means Barracuda saw the entire message before deciding to reject it. It’s likely a problem with the content of the email and so I need to look at links in the message.
This type of plain text explanation is great for a human to read and act on. But it’s not that simple for list handling software to identify the relevant information in the text message and act on future emails to that recipient. Different MTA vendors and ESPs have done a lot of work to try and correctly parse bounce messages to pull out relevant information.
ISPs have tried to help the situation by giving more descriptive rejection messages. They’re still using the SMTP required 3 digit numbers, but they include short, parseable codes in the text portion of the message. In many cases they also include URLs and links that open up webpages explaining the meaning of the code. They even post a list of the most common codes on their postmaster webpages.
All of these things make it somewhat easier to handle bounces automatically. Kinda.
I’ve been working on some bounce handling recommendations for a client using a few different ESPs. I spent a good few days digging into the bounces returned by their different ESPs. It was an interesting exercise as it demonstrated how very differently ESPs handle bounces. But it also clarified for me that there are a lot of different kinds of bounces.

Read More