6

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).

JamesG
  • 191
  • 1
  • 9
  • Why do you think that exim4 sent the mail? It could have been malicious software installed after your system was compromised. – Michael Hampton Dec 20 '17 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 '17 at 23:51
  • How are you so certain that your machine isn't compromised and that no email is being sent? Whatever information you base that assessment on, it is not included in your question. – Michael Hampton Dec 21 '17 at 02:02
  • The server in question uses OSSEC in combination with a range of other tools to detect intrusions. The server has been regularly audited by qualified external security consultants who conduct extensive penetration tests. There have been no signs of compromise based on both internal and external monitoring. If this server has been hacked then it is the most seamless hack ever. Having said all that, I will turn the machine **off** for 24 hours and see if the IP address still gets listed. Stay tuned... – JamesG Dec 21 '17 at 02:13
  • Whoops, wait, can't turn that machine off. D'oh! OK, so you might just have to trust me on this one that this machine has not been compromised. There are no signs of malicious activity and the activity in the mail log appears normal, ie. there is the occasional attempted delivery of inbound spam and the normal junk that you see every few minutes. As I said previously, if this machine has been hacked, they have done a pretty amazing job, because everything else is working perfectly they have done a hell of a job making sure my 'cd', 'ls' and 'tail' commands appear as if everything is normal! – JamesG Dec 21 '17 at 02:18
  • 1
    You'd need to monitor port 25 traffic outside the server to be sure. E.g. a logging firewall. – Esa Jokinen Dec 21 '17 at 06:16
  • The server is a VPS hosted by Linode. I will raise a ticket and ask them if they can monitor my outbound traffic on port 25, but as the VPS is of the "unmanaged" variety, I doubt they'll want to expend the effort. FWIW, the server was listed again this morning. I delisted it and seven hours later it was listed again. According to the log, the only activity was two inbound emails that were received by Exim and handed off to the SAAS app for processing. Anyway, I'll get in touch with Linode and see if they can monitor the outgoing traffic. – JamesG Dec 22 '17 at 05:25
  • 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 '17 at 07:15
  • @anx I think you nailed it. I think the entire /64 range has been listed. If you would like to add that as an answer I will happily accept it. – JamesG Dec 24 '17 at 22:33
  • 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 09 '19 at 02:39

1 Answers1

7

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.

JamesG
  • 191
  • 1
  • 9
anx
  • 8,963
  • 5
  • 24
  • 48
  • 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 '17 at 06: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 04 '18 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 05 '18 at 09: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 07 '18 at 10:19