Yes, the default SLAAC address space has ended up on some blacklists or been subject to rate-limiting. There are some prior forum topics discussing this issue and its solution (obtaining an address pool assignment). The Linode guide should probably mention this as a reason why someone would want to request an address pool.

I had the exact same problem. It is nice to know the root cause of the problem. The explanation by gbcx also explains why Comcast and Spamhaus considers my ipv6 address to be a "dynamic ip address".

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

http://www.spamhaus.org/organization/st … -statement">http://www.spamhaus.org/organization/statement/012/spamhaus-ipv6-blocklists-strategy-statement says

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

@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

http://www.spamhaus.org/organization/st … -statement">http://www.spamhaus.org/organization/statement/012/spamhaus-ipv6-blocklists-strategy-statement says

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 http://postmaster.comcast.net/smtp-erro … p#BL000001">http://postmaster.comcast.net/smtp-error-codes.php#BL000001

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.