In other news, I've spent hours today dealing with the fact that Spamhaus says there's malware sending spam from the IPv6 range which is supposedly reserved by Akamai for my mail server.

[Gast]

Spamhaus says their spam-traps are seeing this supposedly coming from my mail server:

(UTC timestamp, HELO value)
2026-06-02 14:00:00 fjcadazovcov.outnorkes.us.com
2026-05-31 00:00:00 server.example.com
2026-05-25 15:15:00 wntqiolkkxdv.optstartin.co.com
2026-05-24 16:10:00 ihfatfiz.xnrhrzpx.poolinfrast.it.com
2026-05-21 12:00:00 server.example.com

I don't suppose anybody recognizes this as the detritus of a particular form of malware they've seen before?
#infosec

[Gast]

@jik None of the mail systems I help manage (MSP, small-mid business) have heard of any of those domains in the past month.

[Gast]

@jik there is no legitimate production use for anything in the example.com domain name as it’s reserved for diocumentation.

So something is behaving badly.

But a question I have is what supporting evidence do they have that it is your server?

I’m not saying that it isn’t.

I like to corroborate the reports with evidence on systems I run.

It’s almost certainly not your MTA as it should HELO -> EHLO as your hostname or a configured name, but consistently.

I’d fire up a long running tcpdump and / or firewall rule to count interesting traffic.

I’d try to get I formation on the running process that originates the traffic as that would help you find things on your system.

Sadly, having hit spam traps that frequently probably means that you are going to end up ban listed, so maybe brace for that.

[Gast]

@jik do you run an IPv6 stack on your server?

Is your server in a shared network segment?

Could someone else be glomming onto the IPv6 addresses you aren’t using?

How many different IPv6 addresses are they saying the traffic is coming from?

Are any of those addresses bound on your system?

Not a fun position to be in.

Feel free to ask questions if you want to.

[Gast]

Akamai says the IPv6 /64 block Spamhaus says spam is coming from is dedicated to my server, so the spam must be coming from my server.
Meanwhile, Spamhaus sent me the address they're seeing spam from; it's not the address I have configured on my server.
I tried using `curl --interface` as root to bind to that address, and the kernel wouldn't let curl bind to it.
So either Akamai is wrong, or malware on my server is running as root and overriding my network config, which seems like a stretch.

[Gast]

Well, I finally figured out what was going wrong and how to fix it. I feel dirty.
At some point in the last year or so a CentOS update forced me to switch from old-fashioned if-up/down scripts to NetworkManager to manage the network interfaces on my server.
Apparently when I did that, the config to force outbound IPv6 connections to come from my server's dedicated /64 block was lost.
Because apparently there is NO SUPPORTED WAY to do that in NetworkManager.
(continued)

[Gast]

So, unbeknownst to me since then, my outbound SMTP connections have been using the default IPv6 address assigned to my Linode when it was created, rather than the dedicated /64 IPv6 block later assigned to me exactly so my mail server wouldn't get blocklisted because of misbehavior by other servers on Linode's network.
(continued)

[Gast]

I just spent hours trying to figure out how to convince NetworkManager to use my dedicated /64 for outbound connections. I even resorted to Copilot, which gave me numerous wrong answers and instructions.
I finally gave up and resorted to modifying my sendmail config to tell sendmail to explicitly bind outbound connections to an address in my dedicated /64.
This is disgusting, but I don't have any more time to waste on this stupidity.

[Gast]

@fifonetworks https://federate.social/@jik/116692967245379942

[Gast]

@jik
Thanks for the follow-up. It's the one-off problems that keep our troubleshooting skills sharp. Don't beat yourself up too bad over this one. It was a non-obvious problem.

[Gast]

@jik hey, sorry for making you think about this again (feel free to tell me you'll get back to me never ) but I've run VPSs of my own over IPV6 and have always just used the machine's given IPV6 address (either A:B:C:D::1 or A:B:C:D:E:F:G:H) as the basis for the block (i.e. A:B:C:D::/64); and all addresses in that block have made it directly to my VPS (either multiple addresses on the VPS, and/or allocated to VPS-hosted containers). Does linode only give you a single ipv6 address by default (::/128)? or why would a freshly assigned block be any less susceptible to blocklisting of Linode IPs than the defalt-assigned block, if all the blocks belong to Linode in the first place?

Or do you actually have an ipv6 block that is yours, that you can get routed to any arbitrary VPS service you select (and if so, how does one get one of those)?

I'm curious because I've recently been diving heavily into ipv6 routing with multiple uplinks (a linux phone with both 5G and wifi), so your post caught my eye.

thanks

[Gast]

@eigen The original IPv6 address for my server is a /128 in a /64 block shared with other servers. I have a separate /64 block assigned to the server that is not shared.
Using the dedicated /64 as the source for outbound connections protects me from getting blocklisted as a result of blowback from malware on other people's servers because no other servers are able to use addresses in that /64, it's reserved for my server alone.

[Gast]

@jik ah, got it; hope that's the last of the difficulties for awhile.

[Gast]

I took the time to write up all the ways in which Copilot led me astray when I attempted to use it to get advice solving this problem, because I thought this might be a useful illustration of why genAI is dangerous, and why it isn't anything like what the grifters claim who are trying to force it down our throats.
https://blog.kamens.us/2026/06/04/case-study-straightforward-tech-question-genai-is-repeatedly-confidently-wrong/
#AI #AIslop #slop #generativeAI