I’m at the Messaging, Malware, & Mobile Anti-Abuse Working Group meeting this week. After all of the sessions on Tuesday were over, I was speaking 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.
When dealing with a Spamhaus SBL listing, for instance, I will often take a random sample of 20 addresses from the mailing list(s) which 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 turn immediately to the list, but rather to the client’s data. And, I can tell a lot by the data that comes back from a client in response to this request.
There are four basic responses that come back from a request for opt-in data. Sometimes, I find out that a client isn’t abiding by the anti-spam policy. That’s going to 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-2005. That kind of data probably doesn’t indicate that there’s a problem with opt-in processes, but that there is very likely a list hygiene issue that requires resolution. Still other times, there won’t be much opt-in data at all. This will often require further discussion to determine if the email addresses were purchased, rented, or appended, or if the question wasn’t understood. Finally, I might get data that generally looks good and is all recently acquired. This is more probably to be an issue with the on-boarding 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 the use of randomly selected addresses to be a helpful method of getting to the root of the problem quickly.
- Privacy Notices That Work: Beyond Wall Art for Your Website - 20 December 2024
- 2025 Email: Get Rid of the Training Wheels - 13 December 2024
- Help Me See If There Is A Need For That I Can Fill - 23 September 2024
