Re: Spammers, IPv6 addresses, and dnsbls
>
> On 02.03.18 10:12, Leandro wrote:
>
>> If the spammer uses the same domain at rDNS, when rotating IPs, our system
>> will list each new IP at first DNSBL query.
>>
>
> do you verify synthetic rDNS too? when do you blacklist whole /64 ?
>
> I mean: there's 2^64 (18446744073709551616) IPv6 addresses in /64 range and
> there's 2^64 (18446744073709551616) of /64 IPv6 ranges in the IPv6
> namespace.
>
No. Our system lists a /64 for some cases, but not check each rDNS.
It just needs a sample large enough to list the entire /64.
>
> blacklisting either is not in possibilities of present systems.
> I'm curious whether you have any plan what to do when someone starts
> abusing
> IPv6 space and how does the plan look like.
>
Our system uses a CIDR oriented database. This means that system can be
clustering all IPv6 addresses for a minimal equivalent CIDR list.
Example:
show() => []
add("2001:db8::0") => ADDED
show() => ["2001:db8::/128"]
add("2001:db8::1") => JOINED
show() => ["2001:db8::/127"]
add("2001:db8::2") => ADDED
show() => ["2001:db8::/127", "2001:db8::2/128"]
add("2001:db8::3") => JOINED
show() => ["2001:db8::/126"]
listed("2001:db8::1") => TRUE
listed("2001:db8::4") => FALSE
overlap("2001:db8::0/64") => OVERLAPPED
show() => ["2001:db8::/64"]
remove("2001:db8::7fff") => EXTRACTED
show() => ["2001:db8::/114", "2001:db8::4000/115",
"2001:db8::6000/116", "2001:db8::7000/117",
"2001:db8::7800/118", "2001:db8::7c00/119",
"2001:db8::7e00/120", "2001:db8::7f00/121",
"2001:db8::7f80/122", "2001:db8::7fc0/123",
"2001:db8::7fe0/124", "2001:db8::7ff0/125",
"2001:db8::7ff8/126", "2001:db8::7ffc/127",
"2001:db8::7ffe/128", "2001:db8::8000/113",
"2001:db8::1000:0/100", "2001:db8::100:0/104",
"2001:db8::10:0/108", "2001:db8::1:0/112",
"2001:db8::2000:0/99", "2001:db8::200:0/103",
"2001:db8::20:0/107", "2001:db8::2:0/111",
"2001:db8::4000:0/98", "2001:db8::400:0/102",
"2001:db8::40:0/106", "2001:db8::4:0/110",
"2001:db8::8000:0/97", "2001:db8::800:0/101",
"2001:db8::80:0/105", "2001:db8::8:0/109",
"2001:db8::1000:0:0/84", "2001:db8::100:0:0/88",
"2001:db8::10:0:0/92", "2001:db8::1:0:0/96",
"2001:db8::2000:0:0/83", "2001:db8::200:0:0/87",
"2001:db8::20:0:0/91", "2001:db8::2:0:0/95",
"2001:db8::4000:0:0/82", "2001:db8:0:0:0:400:0:0/86",
"2001:db8::40:0:0/90", "2001:db8::4:0:0/94",
"2001:db8::8000:0:0/81", "2001:db8::800:0:0/85",
"2001:db8::80:0:0/89", "2001:db8::8:0:0/93",
"2001:db8::1000:0:0:0/68", "2001:db8::100:0:0:0/72",
"2001:db8::10:0:0:0/76", "2001:db8::1:0:0:0/80",
"2001:db8::2000:0:0:0/67", "2001:db8::200:0:0:0/71",
"2001:db8::20:0:0:0/75", "2001:db8::2:0:0:0/79",
"2001:db8::4000:0:0:0/66", "2001:db8::400:0:0:0/70",
"2001:db8::40:0:0:0/74", "2001:db8::4:0:0:0/78",
"2001:db8::8000:0:0:0/65", "2001:db8::800:0:0:0/69",
"2001:db8::80:0:0:0/73", "2001:db8::8:0:0:0/77"]
add("2001:db8::7fff") => JOINED
show() => ["2001:db8::/64"]
This solution helps to minimize this type of abuse.
> --
> 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.
> There's a long-standing bug relating to the x86 architecture that
> allows you to install Windows. -- Matthew D. Fuller
>
Re: Spammers, IPv6 addresses, and dnsbls
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. 2018-03-02 10:08 GMT-03:00 Matus UHLAR - fantomas : how/who do you list when spammer starts rotating IPs in assigned /64 range? On 02.03.18 10:12, Leandro wrote: If the spammer uses the same domain at rDNS, when rotating IPs, our system will list each new IP at first DNSBL query. do you verify synthetic rDNS too? when do you blacklist whole /64 ? I mean: there's 2^64 (18446744073709551616) IPv6 addresses in /64 range and there's 2^64 (18446744073709551616) of /64 IPv6 ranges in the IPv6 namespace. blacklisting either is not in possibilities of present systems. I'm curious whether you have any plan what to do when someone starts abusing IPv6 space and how does the plan look like. -- 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. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller
Re: Spammers, IPv6 addresses, and dnsbls
On 2018-03-07 (13:12 MST), Philip wrote: > > ps your server blocks .nz domains :P Mine too. I have a short list of TLDs I accept mail from, and everything else gets rejected. New Zealand hasn't come up as a country accounts on my server get mail from… basically, in help checks: /.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|uk|us|tv|info|biz|eu|es|il|it|nl|name|jp|host)$/ DUNNO /.*\.*/ 550 Mail to/from this TLD is not allowed (There's a bit more too it than that, but it's reduce my spam load by massive amounts and I got to completely avoid the .top spamsplosion). -- Competent? How are we going to compete with that?
Re: Spammers, IPv6 addresses, and dnsbls
Philip skrev den 2018-03-07 21:12: Providers like Linode assign a single IPv6 address from a /64. I had to request my own block of /64 to use on my server as my IP neighbors you can masq your ipv6 if you have 2 /64 in your ifconfig info dont blame linode for sleeping with slaac :=) new vps does not have 2 /64 in ifconfig
Re: Spammers, IPv6 addresses, and dnsbls
Hi there, Providers like Linode assign a single IPv6 address from a /64. I had to request my own block of /64 to use on my server as my IP neighbors were always getting the /64 blocked... since I've had my own I've been all good. Before this my IPv6 IP was getting blocked daily because of someone else on that /64. It was quite annoying for myself. Phil ps your server blocks .nz domains :P On 03/03/2018 00:54, Daniele Duca wrote: 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
Re: Spammers, IPv6 addresses, and dnsbls
On Mar 2, 2018, at 03:54, Daniele Duca wrote: > 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. I have heard of at least one provider that assigns a single IPv6 (/128) to each machine, and uses a single /64 for their entire server farm (possibly a different /64 for each location). The simplest solution is blacklist them until they are forced to gain clue points. Might not be realistic for some people, but if you don't cut them off from the Internet, how will they learn? The stupid, it burns. -- My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.
Re: Spammers, IPv6 addresses, and dnsbls
On 03/02/2018 12:54 PM, Daniele Duca wrote: 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. 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 This is not related to SA = Off-Topic There are more adequate lists for this kind of discussion (Mailop list, for example)
Re: Spammers, IPv6 addresses, and dnsbls
2018-03-02 10:08 GMT-03:00 Matus UHLAR - fantomas : > 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? > If the spammer uses the same domain at rDNS, when rotating IPs, our system will list each new IP at first DNSBL query. > But do not use our DNSBL to reject messages. Use only for SA punctuation, >> higher points to 127.0.0.2. >> > >
Re: Spammers, IPv6 addresses, and dnsbls
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 : 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.
Re: Spammers, IPv6 addresses, and dnsbls
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 : > 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 > >
