From time to time I’ve had some emails bounce because my mail server’s IP address landed up in a Real Time Blacklist (RBL). Some destinations seemed to be more particular than others. And it wasn’t all the time.
I most cases, all I did was try to contact the recipient domain and see if I could convince them that my server was properly configured and not sending or relaying spam.
Finally, a little while ago one of the reject messages indicated what RBL was listing my server. So I contacted them and found the reason was due to IPv6.
Basically it comes down to:
- My virtual private server (VPS) provider assigns IPv6 addresses out of a /64 pool of addresses.
- The RBL can’t deal with all the possible /128 addresses available in IPv6 so they block things on a /64 subnet level. This makes sense as typical residential IPv6 assignments are /64 allowing many routable addresses for all your devices. So a spammer usually has a /64 address space to pull IPv6 addresses from.
The result is that if any other customer of my VPS provider is running a spam operation my mail server is collateral damage.
The Solution, Easy Part
It turns out that my provider is capable of assigning my VPS with a /64 IPv6 address range of its own and it only took a few minutes to allocate it.
With my own /64 address space, I control all the addresses that are blocked together in the RBL and as long as I keep my server clean I should not be black listed.
The provider has a document on how to configure a new IP address into a VPS instance. It is tailored toward IPv4 but gives the concept for doing this for IPv6. And my instance is running Ubuntu 18 which now uses a facility called NetPlan to configure interfaces.
The Solution, Hard Part
The problem wasn’t adding a IPv6 address out of my /64 block and carrying inbound traffic over it. The problem was that the old automatically assigned IPv6 address was still there and being used for outbound traffic.
My frustration tolerance level is such that I didn’t spend much time in any one session trying to get this to work. But on sessions spread over a week or two I wasn’t having much luck.
The problem was that any way I took to disable or remove the old IPv6 address resulted in IPv6 connectivity failing. And as long as the default original IPv6 address was there it was being preferred for outbound connections.
There is apparently something in the IPv6 router assigned (RA) information that I was unable to set up manually. And as long as I allowed the RA to occur I ended up with the old IPv6 address (in addition to my new manually IPv6 assigned address).
The Fix. Maybe.
Finally, after a lot of reading up on NetPlan, Ubuntu and IPv6 routing, it finally dawned on me that I could approach this from the other direction: Configure Postfix to bind to the IPv6 address I wanted it to use. Turns out that is a trivial and fast thing to do.
I just had to get it out of my head that the fix had to be in the Linux networking stack and think about the application layer.
I have removed Google from my life as much as I possibly can. But I have retained the gmail account specifically for being able to test mail server issues.
Sure enough, sending from my mail server to my gmail account then looking at the full set of headers it looks like the correct IPv6 address is being used. The SPF is working properly (the MX record points to the domain name which has a AAAA record, etc.).
Time will tell, but maybe I am now free from RBL collateral damage.