Hello list,

apologies if this is not directly SA related. "Lately" I've started to notice that some (not saying names) VPS providers, when offering v6 connectivity, sometimes tends to not follow the best practice of giving a /64 to their customer, routing to them much smaller v6 subnets, while still giving to them the usual /30 or /29 v4 subnets.

What It's happening is that whenever a spammer buys a VPS with those providers and get blacklisted, most of the time the dnsbls list the whole v6 /64, while still listing only the single ipv4 address. This makes some senses, as it would be enormously resource intensive to track each of the 18,446,744,073,709,551,616 addresses in the /64, but unfortunately not respecting basic v6 subnetting rules causes reputation problems also for the other customers that have the bad luck of living in the same /64 and are using their VPS as an outgoing mail server.

While I'm not judging the reasons why VPS providers are doing this type of useless v6 subnetting (micronetting?), I've started to deploy some countermeasures to avoid FPs. Specifically I wrote a rule that identifies if the last untrusted relay is a v6 address, and then is subsequently used in other meta rules that subtract some points in dnsbl tests that check the -lastexternal ip address on v6-aware lists.

I know that probably is not the best solution, but I've started to see real FPs that worried me. I've even pondered if it could have sense to go back to v4 only connectivity for my inbound mtas.

If you are in a similar situation I would like very much to discuss what would be the best approach to balance spam detection while avoiding fps


Daniele Duca

Reply via email to