Re: Spammers, IPv6 addresses, and dnsbls

2018-03-10 Thread Leandro
>
> 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

2018-03-10 Thread 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.



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

2018-03-08 Thread @lbutlr

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

2018-03-07 Thread Benny Pedersen

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

2018-03-07 Thread Philip

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

2018-03-04 Thread LuKreme
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

2018-03-02 Thread Axb

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

2018-03-02 Thread 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? 


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

2018-03-02 Thread Leandro
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
>
>


Spammers, IPv6 addresses, and dnsbls

2018-03-02 Thread 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