For the last six months I have been locked in battle with the Spamhaus CSS SBL, having to regularly check if the IPv6 address of my Exim4 server has been listed and, if it has, manually delisting it. I finally conceded defeat last week and switched my SAAS app from using a self-managed (and well configured) Exim4 server to Mailgun. By "well configured" I mean it had SPF, DKIM and DMARC records, sent well-formed, multipart emails, had list-unsubscribe headers, etc. All the so-called "best practice" things.

The CSS SBL is supposed to list "snowshoe" spammers, which means operators sending low volumes of email from multiple IP addresses. Well, for a start, email for the SAAS's domain only ever originated from this one address, so I'm not sure how their algorithms concluded it was a snowshoe spamming operation, but anyway...

Whilst the SAAS app now sends all its email via Mailgun, I left Exim4 running in case other services on the machine needed to send emails to my support email address. Since then, the Exim4 server has sent about five very benign emails to my support email address, which is hosted on a self-managed Ubuntu machine running Postfix and doesn't have any anti-spam modules installed (so I know it isn't talking to Spamhaus).

Despite that, the IP of the Exim4 server continues to get listed in the CSS SBL on an almost daily basis. What is even more perplexing is that the IP address is getting listed even when no email has been sent! By way of example, I delisted the IP address yesterday and when I checked this morning (approximately 20 hours later), it had been re-listed. I checked the Exim4 logs and not a single email had been emitted in that period.

So does anybody know why the IP address would continue to be listed in the CSS SBL even though essentially no email is being sent from that address?

I should add that the IP address has been in use on this server for over three years, the DNS is with Linode and the domain name is registered with GoDaddy with publicly accessible, genuine whois records (ie. no privacy protection).

  • Why do you think that exim4 sent the mail? It could have been malicious software installed after your system was compromised. Dec 20, 2017 at 23:37
  • Thanks for taking the time to respond to my question, but I think you have missed the point. Firstly, the system hasn't been compromised. Secondly, the issue isn't that rogue emails are triggering listing, it's that the IP address is being listed even when no email is being sent.
    – JamesG
    Dec 20, 2017 at 23:51
  • 1
    You'd need to monitor port 25 traffic outside the server to be sure. E.g. a logging firewall. Dec 21, 2017 at 6:16
  • 3
    Figure out whether the listing is not directed at your machine, specifically. Check what size of IP block got listed (simple: query a few IPs similar to yours). E.g. for IPv6, the CSS zone contains subnets >= /64.
    – anx
    Dec 24, 2017 at 7:15
  • 1
    I don't want this to sound like Linode bashing (they've largely been great), but I have run into the same problem and I post for the benefit of others. The IPv4 on my VPS is not in Spamhaus, but my IPv6 keeps being added and re-added. Linode did happily assign me my own /64 but, quite frankly, if I understand the situation correctly it is less effort to set up the same VPS somewhere else where I get my own /64 from the start, and this is what I am doing because this VPS is due to be replaced anyway. I was going to park the new one at Linode too, but now I have to put it somewhere else.
    – CraigH
    May 9, 2019 at 2:39

1 Answer 1


Warning ahead for people experiencing similar issues: NEVER just request unblocking at any spam block list before you figure out what's going on. Those spam blocklist are almost always clever enough to not randomly block you. They may even tell you that additional unblock requests will incur a fee or not be possible at all if you unblock and then get listed again.

There are a number of rules about the CSS blocklist that are not published - intentionally - they do not want the spammers to avoid getting blocked by working around the rules.

One thing that is well known and published is however, that the list contains at least /64 blocks for IPv6. That means, they never block single /128 addresses, they always hit a full block at once. That, in turn, means that spam being sent by people in the same /64 block as you is getting you blocked as well.

If it was listing smaller blocks, the list would be

  • tremendously large (imagine the number of possible ipv6 addresses to keep track of) and
  • very easily circumvented by spammers (they could just use a fresh IP every time they were blocked).

The choice of using /64 blocks is roughly tracking what is common in the industry nowadays - one /64 usually is one customer. That equation was far from always the case 5 years ago - but afaik is the industry standard by now.

For a more detailed and weighed discussion of that decision, there is a lengthy statement about it on the spamhaus site: the "Spamhaus IPv6 Blocklists Strategy Statement"

Possible solutions for your case:

a) Ask your hosting provider

Your hosting provider may or may not effortlessly offer to assign you a larger (at least /64) block (Linode FAQs mention adding IPs), as the assignment of your (smaller) block might very well have historic reasons only - the (so far, still only rough) consensus on using /64 per customer is only 2 years old and before that, many hosting providers just assigned whatever they deemed appropriate - with wildly differing outcomes. My experience: many hosting providers offered that change of prefix size to me without me even asking (couple years ago).

b) Change your hosting provider

If your hosting provider is unable to follow industry standards - and additionally unable to justify doing so (I don't assume there is a good explanation, IPv6 address space is not exactly scarce), question their motives. If the hosting provider intentionally assigns small IPv6 blocks - e.g. to make sure that legitimate and spam mail gets mixed up (that is what the Spamhaus folks are concerned with when they use terms like "snowshoe operations") - it's time to run.

  • 2
    Thanks for adding such excellent detail to this answer! Yeah, Linode pretty much summed it up when they told me, "it's not you, it's your neighbours" and immediately offered me my own /64 subnet. I'm not sure if that's common - I have been with them for eight years and spend a decent amount of money each month - but at any rate, they were extremely helpful and I would highly recommend them. And I'm glad I now understand why Spamhaus doesn't block individual IPs. Thanks again!
    – JamesG
    Dec 25, 2017 at 6:01
  • Although I will probably get voted down for adding this comment, another potential solution is to disable IPv6 on the mail server. According to the Spamhaus statement about IPv6, most mail servers will continue to run on IPv4 for quite some time, as there are many details related to running IPv6 mail servers that people have yet to iron out. This probably explains why I saw so many articles on "Disabling IPv6 in Exim4" when I was researching this issue.
    – JamesG
    Jan 4, 2018 at 23:08
  • 1
    @JamesG Although this reply is only following a funny intro literally asking for downvotes, that spamhaus statement is from 2011. Meanwhile, i experienced a routing failure of all ipv4 traffic at some server.. and barely noticed.
    – anx
    Jan 5, 2018 at 9:26
  • Ahh, good point - so turning off IPv6 and sticking with IPv4 really isn't a wise option. Thanks again for your help.
    – JamesG
    Jan 7, 2018 at 10:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.