Comcast MX follies - Dallas in a bad IPv6 neighborhood?
First I ran into greylisting (fair enough, I suppose, but irritating just the same). Then one day, I got a message bounce, and discovered to my horror that my IPv6 address was listed in Spamhaus SBL-CSS, the blocklist that is intended to catch "snowshoe" spammers who send small spam runs through large numbers of IP addresses. My server logs showed no spam being sent through the system. I delisted the address, and it has since stayed delisted.
Though I've always had an SPF record, and have valid reverse DNS on both IPv6 and IPv4, I decided to go ahead and set up DKIM and DMARC as well, since this system hosts more than one domain. A quick check by way of sending a message to my Gmail address verified that the SPF, DKIM, and DMARC records pass, and Gmail didn't delay the mail.
Nonetheless, Comcast went back to greylisting. I managed to get a message through to my father after a long delay with multiple tries, but then this morning when I tried sending another message to him, I got a "421 Too many sessions opened" from their MX, which according to them means more than 25 simultaneous connections were open. This is clearly BS, since this is a single email message, nothing else was in the mail queue, and the log clearly shows only one connection being established.
I finally hit on a way to force the message to go via IPv4 - by setting ip6tables REJECT rules against the Comcast IPv6 MX addresses, in both the INPUT and OUTPUT chains. The next time Sendmail tried to send the delayed message, it went through to the IPv4 MX immediately without any 421 business.
I'm wondering if this Linode's IPv6 is in an address block that has been, or is being abused by someone else? My most recent checks against the well-known DNSBLs pass, but maybe Comcast is using their own blacklist.
3 Replies
The problem is that for IPv6 a network is considered to be a /64. Anyone filtering for abuse in IPv6 will automatically take into account of all traffic from a single network. If you're using the IPv6 address automatically assigned from router advertisements - it's in the same /64 as all other servers.
Request a routed /64 if you don't have one already.
@-Alex-:
Which outgoing IPv6 address are you using?
The problem is that for IPv6 a network is considered to be a /64. Anyone filtering for abuse in IPv6 will automatically take into account of all traffic from a single network. If you're using the IPv6 address automatically assigned from router advertisements - it's in the same /64 as all other servers.
Request a routed /64 if you don't have one already.
That makes sense, as I'm using the autoconfigured IPv6 address. Shortly after I made my post, I thought that perhaps this might be the problem. Once I get some free time I think I'll go ahead and request my own /64.
In the meantime, firewalling the Comcast IPv6 MX hosts seems to be doing the trick.
Edit: I just thought of something else I could do: make an application-specific firewall rule to prevent Sendmail from speaking IPv6 at all on outgoing connections, at least until I get the /64 in place. Since, in practice, I'm not sending email to parts of the world where IPv4 connectivity is problematic, that would work even if Comcast changes its MX addresses. That might be more trouble than it's worth, though.