Spamhaus IPv6 blocking issues impacting Linodes
Anyway, with the help of a direct contact at Comcast I learned that the IPv6 address of the Linode in question was included on the Spamhaus IPv6 CSS (and therefore in Zen). Why? Because its part of an IPv6 /64 allocation that Spamhaus was listing. See the problem? Collateral damage. Kinda feels like 2002 all over again.
Spamhaus considers Linode's policy of assigning /128s (single IPs) to be "unusual" and told me to have Linode issue us our own /64 that we can move into. I'll be opening a ticket to bring this issue to the attention of the powers that be, but be aware that this can happen to you too.
9 Replies
priorforumtopicsaddress pool assignment
I did open a ticket with Linode and their solution was to disable IPv6 support for sending email. I did not have time to question that solution, so that is what I did.
Now that a pattern has been established, it will be interesting to see what the proper solution will be.
@gbcx:
I won't go into how frustrating it was to find out what was going on, since both Comcast and Spamhaus have no public facing search or removal tools that will accept input of IPv6 addresses.
You should be able to search using nslookup or dig
Querying IPv6 blocklists
IPv4 blocklists are queried by prepending the reversed decimal quad address to the zone to be queried. Legacy queries for IPv6 blocklists will use a similar model; the fully expanded IPv6 address is reversed by hex digit and prepended to the zone to be queried. For example, to query the address 2001:DB8
2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.2.1.0.c.b.a.0.8.b.d.0.1.0.0.2.zen.spamhaus.org
@sweh:
@gbcx:I won't go into how frustrating it was to find out what was going on, since both Comcast and Spamhaus have no public facing search or removal tools that will accept input of IPv6 addresses.
You should be able to search using nslookup or dig
says http://www.spamhaus.org/organization/st … -statement">http://www.spamhaus.org/organization/statement/012/spamhaus-ipv6-blocklists-strategy-statement Querying IPv6 blocklists
IPv4 blocklists are queried by prepending the reversed decimal quad address to the zone to be queried. Legacy queries for IPv6 blocklists will use a similar model; the fully expanded IPv6 address is reversed by hex digit and prepended to the zone to be queried. For example, to query the address 2001:DB8
:abc: 123::42 the IPv6 address would be expanded, reversed and prepended to the zone to be queried, to give an example query of:2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.2.1.0.c.b.a.0.8.b.d.0.1.0.0.2.zen.spamhaus.org
Really? Then help explain this:
From linode:
[jrc@speakup ~]$ telnet mx2.comcast.net 25
Trying 2001:558:fe21:2a::6…
Connected to mx2.comcast.net.
Escape character is '^]'.
554 resimta-ch2-02v.sys.comcast.net comcast 2600:3c00::f03c:91ff:fe56:a64 found on one or more DNSBLs, see
Connection closed by foreign host.
BL000001 supposedly means Zen, and a Comcast tech called me back today and gave me the CSS spiel, and CSS is in Zen.
So … to verify that:
[jrc@speakup ~]$ host 2600:3c00::f03c:91ff:fe56:a64
4.6.a.0.6.5.e.f.f.f.1.9.c.3.0.f.0.0.0.0.0.0.0.0.0.0.c.3.0.0.6.2.ip6.arpa domain name pointer speakup.octothorp.org.
^^^ easiest way to reverse the address without making a mistake
[jrc@speakup ~]$ host 4.6.a.0.6.5.e.f.f.f.1.9.c.3.0.f.0.0.0.0.0.0.0.0.0.0.c.3.0.0.6.2.zen.spamhaus.org
Host 4.6.a.0.6.5.e.f.f.f.1.9.c.3.0.f.0.0.0.0.0.0.0.0.0.0.c.3.0.0.6.2.zen.spamhaus.org not found: 3(NXDOMAIN)
Hmmmmmm. Any ideas? Has anyone got an IPv6 address that actually comes back as bad?
If you are a postfix(1) user, you can get around this by setting the following:
### force postfix to use ipv4 (f****** Comcast)
#
inet_protocols = ipv4
###inet_protocols = all
I'm convinced that Comcast is just being incredibly lazy about this… Email service is a loss leader for them so they have no incentive to make it work correctly. Besides, when you have the gold you can make the rules.
-- sw
I just worked on this issue. The problem is related to spamhaus (probably others) blocking slaac assigned (your automatically assigned linode v6 address) ipv6 addresss pools. I requested a /64 from Linode and configured a secondary interface with a /128 subnet mask, that fixed the problem.
Never had any problems whit Spamhaus IPv6 blocking, running mail hosting for over 4 years.
[@Tntdruid] (/community/user/Tntdruid) The /64 my slaac address was assigned from was on their cbl. They wouldn't remove and suggested I get a /64 which fixed the issue.
Around 2014 industry agreed to consider /64 as the default minimum granularity for blocking, on the basis that this is the minimum default assignment size in most cases- see also here and here. So Spamhaus' CSS and XBL have /64 as minimum blocking size.
So, Linode's /128 SLAAC addresses may be handy, but in practice useless for mail usage, as the /64 blocks which contain them are very likely to be blocked due to infection/malware issues on any other user with an IPv6 address in there.
The solution is simply to request a /64 allocation from the panel and use an address in there for mail. No one should bother configuring a MTA with the SLAAC address.