Proper Assumptions
This week, I’m at the Messaging, Malware, & Mobile Anti-Abuse Working Group meeting. After all of the Tuesday sessions were over, I spoke with a colleague from another company about how I handle some aspects of providing client advice, and he suggested that I write that down in a blog post.
For instance, when dealing with a Spamhaus SBL listing, I will often take a random sample of 20 addresses from the mailing list(s) that caused the listing and request that a client give opt-in data for those addresses. There’s no allegation that the addresses are bad or that they’re spamtraps, but I need a quick way of coming up to speed on clients and their lists, and I’ve found this a good method of doing so. Additionally, the client’s opt-in practices and other data surrounding their lists is a far more important piece of the puzzle than the fact of a listing. When a listing happens, we don’t immediately turn to the block list but to the client’s data. And I can tell a lot by the data from a client in response to this request.
Four basic responses come back from a request for opt-in data. Sometimes, I find out a client isn’t abiding by the anti-spam policy. That will require a certain response (in this case, the client will either need to remove the data completely or be terminated for failure to abide by the relevant policy). Other times, I get tons of opt-in data, but it’s all from 2002 to 2005. That kind of data probably doesn’t indicate a problem with opt-in processes, but there is very likely a list hygiene issue that requires resolution. Still, other times, there won’t be much opt-in data. This will often require further discussion to determine whether the email addresses were purchased, rented, or appended or the question wasn’t understood. Finally, I might get data that looks good and is all recently acquired. This is more likely to be an issue with the onboarding pipeline than anything else. In these instances, having some additional from the blacklist provider regarding historical data is useful (i.e., “Is this something that just started happening, or is it something that you’ve been seeing for a while?”).
Each of these four basic responses will require different responses. Sometimes, the information may come from my client, sometimes it might come from the blocklist providing the complaint. But, the underlying issue is with the client’s data.
The problem comes from narrowing down where the issue lies. Other people may have other methods of narrowing things down, but I’ve found that randomly selecting addresses is a helpful method of quickly getting to the root of the problem.
- Introducing: Arcana - 22 November 2024
- Help me see if there is a need for that I can fill - 23 September 2024
- Verkada: Data Protection Issues - 19 September 2024