On 02.03.18 09:58, Leandro wrote:
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.

how/who do you list when spammer starts rotating IPs in assigned /64 range?
But do not use our DNSBL to reject messages. Use only for SA punctuation,
higher points to 127.0.0.2.

2018-03-02 8:54 GMT-03:00 Daniele Duca <d...@staff.spin.it>:
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

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol.

Reply via email to