Why would Spamhaus continue to add an IP to the CSS when that IP hasn't sent email recently?How to stop Sendmail sending mail from IPv6 instead of IPv4Exchange 2003 Spamhaus SettingsSending mail through local MTA while domain MX records point to Google AppsWhy is it a bad idea to use a customer email as the from addressPostfix: Gmail marking my email as spamExchange 2013 IPBlockListProvider blocking some (but not all) matched IPsFalse IP blacklisting on CBL and Spamhaus ZENHow to configure an email server so that outgoing emails are not classified as spamReceiving email to ec2 mailserver from MailGun/SESspamassassin has false-positives with emails originating from dialup addressesReceiving spam from my own email address. postfix
Why do testers need root cause analysis?
Why isn't Tyrion mentioned in 'A song of Ice and Fire'?
Are cells guaranteed to get at least one mitochondrion when they divide?
How to create a `range`-like iterable object of floats?
Unary Enumeration
How would a developer who mostly fixed bugs for years at a company call out their contributions in their CV?
Did significant numbers of Japanese officers escape prosecution during the Tokyo Trials?
Who were the members of the jury in the Game of Thrones finale?
How to write numbers and percentage?
resolution bandwidth
One word for 'the thing that attracts me'?
To exponential digit growth and beyond!
Is a world with one country feeding everyone possible?
Why'd a rational buyer offer to buy with no conditions precedent?
Keeping the dodos out of the field
Would cybernetic implants allow humans to use biofeedback to boost their performance to superhuman levels? If so how far could we take it?
Was this scene in S8E06 added because of fan reactions to S8E04?
Is superuser the same as root?
(For training purposes) Are there any openings with rook pawns that are more effective than others (and if so, what are they)?
Prince of Darkness goes cryptic
Why did it take so long for Germany to allow electric scooters / e-rollers on the roads?
Moons and messages
What is to the west of Westeros?
Why do the i8080 I/O instructions take a byte-sized operand to determine the port?
Why would Spamhaus continue to add an IP to the CSS when that IP hasn't sent email recently?
How to stop Sendmail sending mail from IPv6 instead of IPv4Exchange 2003 Spamhaus SettingsSending mail through local MTA while domain MX records point to Google AppsWhy is it a bad idea to use a customer email as the from addressPostfix: Gmail marking my email as spamExchange 2013 IPBlockListProvider blocking some (but not all) matched IPsFalse IP blacklisting on CBL and Spamhaus ZENHow to configure an email server so that outgoing emails are not classified as spamReceiving email to ec2 mailserver from MailGun/SESspamassassin has false-positives with emails originating from dialup addressesReceiving spam from my own email address. postfix
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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 "showshoe" 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).
spam spamassassin
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
|
show 5 more comments
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 "showshoe" 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).
spam spamassassin
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
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 2:02
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 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 '17 at 7:15
|
show 5 more comments
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 "showshoe" 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).
spam spamassassin
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
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 "showshoe" 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).
spam spamassassin
spam spamassassin
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
asked Dec 20 '17 at 22:07
JamesGJamesG
1368
1368
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 2:02
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 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 '17 at 7:15
|
show 5 more comments
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 2:02
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 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 '17 at 7:15
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
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
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 2:02
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 2:02
1
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 6:16
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 6:16
3
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 7:15
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 7:15
|
show 5 more comments
1 Answer
1
active
oldest
votes
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.
edited Jan 5 '18 at 7:18
JamesG
1368
answered Dec 25 '17 at 0:24
anxanx
2,0751823
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 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 '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 5 '18 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 '18 at 10:19
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "2"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f889111%2fwhy-would-spamhaus-continue-to-add-an-ip-to-the-css-when-that-ip-hasnt-sent-ema%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
edited Jan 5 '18 at 7:18
JamesG
1368
answered Dec 25 '17 at 0:24
anxanx
2,0751823
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 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 '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 5 '18 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 '18 at 10:19
add a comment |
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.
edited Jan 5 '18 at 7:18
JamesG
1368
answered Dec 25 '17 at 0:24
anxanx
2,0751823
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 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 '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 5 '18 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 '18 at 10:19
add a comment |
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.
edited Jan 5 '18 at 7:18
JamesG
1368
answered Dec 25 '17 at 0:24
anxanx
2,0751823
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.
edited Jan 5 '18 at 7:18
JamesG
1368
answered Dec 25 '17 at 0:24
anxanx
2,0751823
edited Jan 5 '18 at 7:18
JamesG
1368
edited Jan 5 '18 at 7:18
JamesG
1368
edited Jan 5 '18 at 7:18
JamesG
1368
1368
answered Dec 25 '17 at 0:24
anxanx
2,0751823
answered Dec 25 '17 at 0:24
anxanx
2,0751823
answered Dec 25 '17 at 0:24
anxanx
2,0751823
2,0751823
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 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 '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 5 '18 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 '18 at 10:19
add a comment |
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 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 '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 5 '18 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 '18 at 10:19
2
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 6:01
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 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 '18 at 23:08
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 '18 at 23:08
1
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 '18 at 9:26
@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 '18 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 '18 at 10:19
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 '18 at 10:19
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f889111%2fwhy-would-spamhaus-continue-to-add-an-ip-to-the-css-when-that-ip-hasnt-sent-ema%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 2:02
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 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 '17 at 7:15