Getting Onto a Blocklist Without Sending Any Spam

We recently assisted a customer in Asia with a serious problem: Their entire IP range had become blocklisted by the popular UCEProtect blocklist – in the dreaded so-called “UCEProtect Level 3” blocklist. The customer is an ISP with a large base of consumer and small business subscribers, based in a developing Asian nation. They are one of the world’s largest originators of spam, and we hope to release a case study soon that will provide more detail into what we were able to do for them with our transparent outbound spam filtering solution. But, unlike many ISPs, they are also really trying hard to do the right thing, and have invested many person-years of per-capita GDP in purchasing our transparent outbound spam filtering system.

When we deployed this customer, however, we found out – to our absolute dismay and horror – that the number of IPs in their network that were blocklisted was actually increasing rather than decreasing. This was going on despite the fact that we were filtering out 99.9% or more of the spam messages emanating from their network. To illustrate, here is a one-day graph showing the percentage of SMTP connections coming from this network that actually included message content (i.e “Scanned” – these connections had content that we could scan with the spam filter), versys the percentage of connections that contained messages that we actually delivered. As you can see, only a TINY proportion of the messages that could have been delivered were actually delivered. Most were rejected.

Despite the fact that we were rejecting most of this customer’s spam traffic, they were still getting blocklisted. Why would this be happening? Shouldn’t spam traps actually receive a message before they judge that someone is sending spam? If you don’t send a spam message, but do connect to a spam trap, does this make you a spammer?

The diagram below tries to illustrate visually what I mean:

Even if an ISP deploys a really great transparent spam filter that removes 100% of spam message content by intercepting DATA and responding with a “550 Rejected” message, the mere act of connecting to a spam trap server (1) and attempting to validate recipients (2, if one of those recipients happens to be a spam trap email address) may cause the IP to be added to the blocklist (3).

Is this the right approach to running a blocklist? I don’t know. In one sense, only spammers ought to be connecting to spam traps, so the mere fact that an IP connects to a spam trap server or tries to validate a spam trap address ought to cause that IP to be listed. But what if there is a filter that is diligently removing the spam? A network that removes the spam is indeed fixing the spam problem – shouldn’t blocklists reflect this in their data? What is an ISP to do if even rejecting spam traffic is ineffective in having their IPs removed from the blocklists?

The solution is simple: Make sure the blocklists don’t see traffic from the bad IPs in your network. Doing this without affecting legitimate email traffic is tricky, but possible. I hope to fill you in on how we have tackled this problem quite successfully in a future post.