Hi Danilele! Our DNSBL works with individual /128 IPv6 addresses:

http://spfbl.net/en/dnsbl/

Even if the provider is offering less then /64 to customers, our DNSBL can
list IPv6 of each one.

But do not use our DNSBL to reject messages. Use only for SA punctuation,
higher points to 127.0.0.2.

Regards,

Leandro
SPFBL.net

2018-03-02 8:54 GMT-03:00 Daniele Duca <d...@staff.spin.it>:

> 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
>
>

Reply via email to