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
Regards
Daniele Duca
- Spammers, IPv6 addresses, and dnsbls Daniele Duca
-
