UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget
Hello, I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. There have been controversial positions about this blacklist recently: 1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... [1] 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html [2] UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '_Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'_) [http://www.uceprotect.net/en/rblcheck.php [3]]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called _Cart00ney_ (http://www.uceprotect.net/en/index.php?m=8&s=0 [4]; http://www.uceprotect.org/cart00neys/index.html [5]). And the other type of threatening: http://www.uceprotect.org/ Does RIPE NCC have any position on this specific blacklist? Thank you! Links: ------ [1] https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... [2] https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html [3] http://www.uceprotect.net/en/rblcheck.php [4] http://www.uceprotect.net/en/index.php?m=8&s=0 [5] http://www.uceprotect.org/cart00neys/index.html
Il 02/03/2021 00:08 Kristijonas Lukas Bukauskas via anti-abuse-wg <anti-abuse-wg@ripe.net> ha scritto:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems:
I stress that the problem is not in blacklisting entire providers, something that may be justified if those providers are lenient in fighting abuse on their networks, but in blacklisting entire providers with very weak criteria (so weak that most big European hosters end up at least in the level 3 blacklist) and then asking for money to remove them. This is actually prohibited by RFC 6471 (section 2.2.5) because indeed, especially when done at scale, it looks a lot like extortion.
UCEPROTECT states, 'Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers') [http://www.uceprotect.net/en/rblcheck.php http://www.uceprotect.net/en/rblcheck.php ].
It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/),
It abuses people who decide to challenge their blacklist by publishing conversations in their so-called Cart00ney (http://www.uceprotect.net/en/index.php?m=8&s=0 http://www.uceprotect.net/en/index.php?m=8&s=0 ; http://www.uceprotect.org/cart00neys/index.html http://www.uceprotect.org/cart00neys/index.html ).
They recently published a disgustingly sexist "ad feminam" to blame a person that dared to complain about their methods: http://www.uceprotect.org/cart00neys/2021-001.html They start with the argument that since she is a woman she is stupid and "emotional rather than objective", because she is a woman, and so they quote her message in pink colour. This is completely unacceptable and I strongly recommend that RIPE distances itself as far as it can from these people - as a minimum, please stop using or referring to this blacklist in any way. Regards, -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy
On 02.03.21 10:49, Vittorio Bertola via anti-abuse-wg wrote:
Il 02/03/2021 00:08 Kristijonas Lukas Bukauskas via anti-abuse-wg <anti-abuse-wg@ripe.net> ha scritto:
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems:
I stress that the problem is not in blacklisting entire providers, something that may be justified if those providers are lenient in fighting abuse on their networks, but in blacklisting entire providers with very weak criteria (so weak that most big European hosters end up at least in the level 3 blacklist) and then asking for money to remove them. This is actually prohibited by RFC 6471 (section 2.2.5) because indeed, especially when done at scale, it looks a lot like extortion.
They don't ask for money to be removed from the the list. The listing gets automatically removed after 7 days of taking care of the issue, without money changing hands. Please stop spreading lies. And yes, if they stick to they listing policy, this is ok. It is up to users of the DNSBL to judge if they DO provide a useful service or not. If course if your IP is listed, and you're part of collateral damage, it is uncomfortable.
UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>].
It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>),
Well, yes. The complaint from those who end up being collateral damage is that "we didn't spam". The last time I checked (quite a while ago), the DNSBLs that escalate listings (causing collateral damage) generally don't let individual IPs out of the hook. I'm not sure which one is better.
It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>).
Thanks for reminding me of this, it was very entertaining. The point is NOT retaliating those challenging them, point is making fun of those who threatening with legal consequences without going thru with it (thus cartooney). Threatening with lawyers is just pathetic. If you do that, you should follow up with it, as well.
They recently published a disgustingly sexist "ad feminam" to blame a person that dared to complain about their methods:
http://www.uceprotect.org/cart00neys/2021-001.html <http://www.uceprotect.org/cart00neys/2021-001.html>
They start with the argument that since she is a woman she is stupid and "emotional rather than objective", because she is a woman, and so they quote her message in pink colour.
This is completely unacceptable and I strongly recommend that RIPE distances itself as far as it can from these people - as a minimum, please stop using or referring to this blacklist in any way.
Yes, this was definitely bad form. I have no problem making fun of cartooneys, but putting sexist spin on it is definitely not ok Now, if RIPE should boycott UCEPROTECT because of this faux pass is something we could discuss. I'd rather have someone contacting UCEPROTECT team and get an attitude adjustment in place, but that's me. -- Mr Esa Laitinen IM: https://threema.id/2JP4Y33R <https://threema.id/2JP4Y33R> or https://signal.org/install <https://signal.org/install> Skype: reunaesa Mobile: +4178 838 57 77
On 2021-03-02 13:12, Esa Laitinen wrote:
Now, if RIPE should boycott UCEPROTECT because of this faux pass is something we could discuss. I'd rather have someone contacting UCEPROTECT team and get an attitude adjustment in place, but that's me.
Is there a way to contact them that anybody is aware of? On their website (http://www.uceprotect.net/en/index.php?m=2&s=0; Q17), they say:
A17: Spammers are criminal gangs. In 2004 and since, many other blacklists stopped after they were threatened or attacked. We also got a package from Ukraine with a dead rat inside and a message: "You are next!" For security reasons we moved to a new location and have chosen to continue our war against spammers. Art 34 Abs 5 BayMeldeG (Bavarian Law) grants that only national authorities can find out about us.
On Tue 02/Mar/2021 12:12:33 +0100 Esa Laitinen wrote:
On 02.03.21 10:49, Vittorio Bertola via anti-abuse-wg wrote:
Il 02/03/2021 00:08 Kristijonas Lukas Bukauskas via anti-abuse-wg <anti-abuse-wg@ripe.net> ha scritto:
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems:
I stress that the problem is not in blacklisting entire providers, something that may be justified if those providers are lenient in fighting abuse on their networks, but in blacklisting entire providers with very weak criteria (so weak that most big European hosters end up at least in the level 3 blacklist) and then asking for money to remove them. This is actually prohibited by RFC 6471 (section 2.2.5) because indeed, especially when done at scale, it looks a lot like extortion.
They don't ask for money to be removed from the the list. The listing gets automatically removed after 7 days of taking care of the issue, without money changing hands. Please stop spreading lies.
Hm... perhaps they remove records after some time. However, they ask money for whitelisting, which sorts out the same effect as delisting. From whitelisted.org website: Registration is available for 1 Month (25 CHF), 6 Month (50 CHF), 12 Month (70 CHF), 24 Month (90 CHF) . Best Ale --
On 02.03.21 12:12, Esa Laitinen wrote:
Now, if RIPE should boycott UCEPROTECT because of this faux pass is something we could discuss.
RIPE shouldn't boycott uceprotect because of this faux pas. They should boycott uceprotect because the whole history of cartooneys is a huge concatenation of faux passes, hate speech, and GDPR violations.
I'd rather have someone contacting UCEPROTECT team and get an attitude adjustment in place, but that's me.
Where trying to contact them leads to can be seen in their cartooney gallery.
On 2021-03-02 13:12, Esa Laitinen wrote:
On 02.03.21 10:49, Vittorio Bertola via anti-abuse-wg wrote:
Il 02/03/2021 00:08 Kristijonas Lukas Bukauskas via anti-abuse-wg <anti-abuse-wg@ripe.net> ha scritto:
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: I stress that the problem is not in blacklisting entire providers, something that may be justified if those providers are lenient in fighting abuse on their networks, but in blacklisting entire providers with very weak criteria (so weak that most big European hosters end up at least in the level 3 blacklist) and then asking for money to remove them. This is actually prohibited by RFC 6471 (section 2.2.5) because indeed, especially when done at scale, it looks a lot like extortion.
They don't ask for money to be removed from the the list. The listing gets automatically removed after 7 days of taking care of the issue, without money changing hands. Please stop spreading lies. Interestingly -- but not unexpectedly -- enough they may add you to the uceprotect-level1 list if they see you attempted a payment but haven't paid. So, for reasons not related to spamming. The whole autonomous system of my cloud provider got listed in uceprotect-level3. I wanted to check how their whitelisting works. They blacklisted the public IP of my home internet connection, with a reason (https://pasteboard.co/JQShns8.png):
Payment attempts with invalid credit cards.
Needless to say: my home ISP doesn't allow sending mail, has port 25 blocked, and I haven't entered any card data to get my IP of Cloud server whitelisted whatsoever, only initiated the payment and closed the browser tab once I was routed to their payment provider. Regards, Kristijonas
On 03.03.21 09:35, Kristijonas Lukas Bukauskas wrote:
Interestingly -- but not unexpectedly -- enough they may add you to the uceprotect-level1 list if they see you attempted a payment but haven't paid. So, for reasons not related to spamming.
The whole autonomous system of my cloud provider got listed in uceprotect-level3. I wanted to check how their whitelisting works. They blacklisted the public IP of my home internet connection, with a reason (https://pasteboard.co/JQShns8.png <https://pasteboard.co/JQShns8.png>):
Payment attempts with invalid credit cards.
Needless to say: my home ISP doesn't allow sending mail, has port 25 blocked, and I haven't entered any card data to get my IP of Cloud server whitelisted whatsoever, only initiated the payment and closed the browser tab once I was routed to their payment provider.
This indeed puts the uceprotect in a different category in my books. Please forget what I wrote earlier in this chain. Yours esa -- Mr Esa Laitinen IM: https://threema.id/2JP4Y33R or https://signal.org/install Skype: reunaesa Mobile: +4178 838 57 77
Hi, On Wed, Mar 03, 2021 at 11:57:13AM +0100, Esa Laitinen wrote:
This indeed puts the uceprotect in a different category in my books. Please forget what I wrote earlier in this chain.
I do have my own opinion about uceprotect (and it's not favourable), but we do not need to actually discuss "do we as community like their service or not" or "do we endorse it or not". The RIPE-Stats-Plugin provides *reporting*, and if someone's IP space ends up on a blacklist that is actually used by people, it is useful information to be told about it. This is why uceprotect is listed there, not because "RIPE endorses it". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi. Let me disagree on this misconcept of "endorsement" or "reference" or "reporting". There are **plenty** blacklists out there. RIPE reports specifically UCEPROTECT and SPAMHAUS. This kind of usage and reference by RIPE empirically supports/endorses/make those as a reference. (or a troll feeded) If ripe community dont feel it that way then, imo they should either: a) add more blacklists checks and not only those (in order to avoid discrimination to other blacklist operators) or b) remove blacklist reports at all, so it keeps a neutral position on this. btw, how many of you already got fresh allocations from RIPE that were blacklisted from some of those, and had challenges to start using those and/or get them scrubbed raise the hand. cheers /nuno On Wed, 2021-03-03 at 12:16 +0100, Gert Doering wrote:
Hi,
On Wed, Mar 03, 2021 at 11:57:13AM +0100, Esa Laitinen wrote:
This indeed puts the uceprotect in a different category in my books. Please forget what I wrote earlier in this chain.
I do have my own opinion about uceprotect (and it's not favourable), but we do not need to actually discuss "do we as community like their service or not" or "do we endorse it or not".
The RIPE-Stats-Plugin provides *reporting*, and if someone's IP space ends up on a blacklist that is actually used by people, it is useful information to be told about it.
This is why uceprotect is listed there, not because "RIPE endorses it".
Gert Doering -- NetMaster
True. If you’re listing only two BLs - one reputable and the other UCEPROTECT.. there are many other public block lists, ok fewer than there were in the 2000s but still .. --srs ________________________________ From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Nuno Vieira via anti-abuse-wg <anti-abuse-wg@ripe.net> Sent: Wednesday, March 3, 2021 5:01:51 PM To: Gert Doering <gert@space.net>; Esa Laitinen <esa@laitinen.org> Cc: Nuno Vieira <nuno@hashpower.pt>; anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget Hi. Let me disagree on this misconcept of "endorsement" or "reference" or "reporting". There are **plenty** blacklists out there. RIPE reports specifically UCEPROTECT and SPAMHAUS. This kind of usage and reference by RIPE empirically supports/endorses/make those as a reference. (or a troll feeded) If ripe community dont feel it that way then, imo they should either: a) add more blacklists checks and not only those (in order to avoid discrimination to other blacklist operators) or b) remove blacklist reports at all, so it keeps a neutral position on this. btw, how many of you already got fresh allocations from RIPE that were blacklisted from some of those, and had challenges to start using those and/or get them scrubbed raise the hand. cheers /nuno On Wed, 2021-03-03 at 12:16 +0100, Gert Doering wrote:
Hi,
On Wed, Mar 03, 2021 at 11:57:13AM +0100, Esa Laitinen wrote:
This indeed puts the uceprotect in a different category in my books. Please forget what I wrote earlier in this chain.
I do have my own opinion about uceprotect (and it's not favourable), but we do not need to actually discuss "do we as community like their service or not" or "do we endorse it or not".
The RIPE-Stats-Plugin provides *reporting*, and if someone's IP space ends up on a blacklist that is actually used by people, it is useful information to be told about it.
This is why uceprotect is listed there, not because "RIPE endorses it".
Gert Doering -- NetMaster
There are plenty of blacklists and there is no need to "support" just those two. So i totally agree that the RIPE should expand the list or remove it Am 03.03.21 um 12:31 schrieb Nuno Vieira via anti-abuse-wg:
Hi.
Let me disagree on this misconcept of "endorsement" or "reference" or "reporting".
There are **plenty** blacklists out there.
RIPE reports specifically UCEPROTECT and SPAMHAUS.
This kind of usage and reference by RIPE empirically supports/endorses/make those as a reference. (or a troll feeded)
If ripe community dont feel it that way then, imo they should either:
a) add more blacklists checks and not only those (in order to avoid discrimination to other blacklist operators)
or
b) remove blacklist reports at all, so it keeps a neutral position on this.
btw, how many of you already got fresh allocations from RIPE that were blacklisted from some of those, and had challenges to start using those and/or get them scrubbed raise the hand.
cheers /nuno
On Wed, 2021-03-03 at 12:16 +0100, Gert Doering wrote:
Hi,
On Wed, Mar 03, 2021 at 11:57:13AM +0100, Esa Laitinen wrote:
This indeed puts the uceprotect in a different category in my books. Please forget what I wrote earlier in this chain. I do have my own opinion about uceprotect (and it's not favourable), but we do not need to actually discuss "do we as community like their service or not" or "do we endorse it or not".
The RIPE-Stats-Plugin provides *reporting*, and if someone's IP space ends up on a blacklist that is actually used by people, it is useful information to be told about it.
This is why uceprotect is listed there, not because "RIPE endorses it".
Gert Doering -- NetMaster
-- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support@artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478
Dear colleagues, RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights. UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists. RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services. Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this. RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful. Regards, Christian On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... <https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security> 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
uceful :) randy
Do you see email providers of significant size using it? --srs ________________________________ From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Christian Teuschel <cteusche@ripe.net> Sent: Wednesday, March 3, 2021 9:57:50 PM To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget Dear colleagues, RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights. UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists. RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services. Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this. RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful. Regards, Christian On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... <https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security> 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems:
UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>].
It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>),
It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>).
And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/>
Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
On 2021-03-04 01:54, Suresh Ramasubramanian wrote:
Do you see email providers of significant size using it?
--srs
Potentially Microsoft [https://www.e-shot.net/insights/help/half-of-the-internet-is-blacklisted-uce...]. Office 365 Support has referred to uceprotect-level3 as a possible cause of why my mail gets delivered to the junk mail folder for their clients (https://pasteboard.co/JQYtxM2.png). -- Regards, Kristijonas
As far as I can see that is probably an artefact of an overly helpful customer service person trying to troubleshoot mail delivery for you --srs ________________________________ From: Kristijonas Lukas Bukauskas <ripe@n0.lt> Sent: Thursday, March 4, 2021 5:47:38 AM To: Suresh Ramasubramanian <ops.lists@gmail.com> Cc: christian.teuschel@ripe.net <christian.teuschel@ripe.net>; anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget On 2021-03-04 01:54, Suresh Ramasubramanian wrote: Do you see email providers of significant size using it? --srs Potentially Microsoft [https://www.e-shot.net/insights/help/half-of-the-internet-is-blacklisted-uce...]. Office 365 Support has referred to uceprotect-level3 as a possible cause of why my mail gets delivered to the junk mail folder for their clients (https://pasteboard.co/JQYtxM2.png). -- Regards, Kristijonas
On 2021-03-04 03:26, Suresh Ramasubramanian wrote:
As far as I can see that is probably an artefact of an overly helpful customer service person trying to troubleshoot mail delivery for you
I've seen various sources (not sure if they are sufficient to drive any conclusions though) that Microsoft actually does use uceprotect. But you might be right. Microsoft has odd filtering algorithms: I've experienced their very own e-mails (from SNDS, Microsoft Azure, even auto-replies from Business Conduct and Compliance) delivered to the junk unless you manually mark them as not junk. I'm having the higher -- Customer Relationship Management -- to clarify it for me. But I'm not that positive that they will disclose if they use uceprotect. -- Regards, Kristijonas
Hi Christian, while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial. You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC. my 2 cents, Elvis On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... <https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security> 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems:
UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>].
It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>),
It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>).
And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/>
Does RIPE NCC have any position on this specific blacklist?
Thank you!
Hi Elvis and Suresh, dear colleagues, Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value. If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations. Best regards, Christian On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html> UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
Christian, Speaking purely personally, I would certainly be in favour of RIPEstat featuring more RBLs, yes. Brian Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet@heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270 ________________________________ From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Christian Teuschel <cteusche@ripe.net> Sent: Thursday 4 March 2021 16:16 To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget CAUTION[External]: This email originated from outside of the organisation. Do not click on links or open the attachments unless you recognise the sender and know the content is safe. Hi Elvis and Suresh, dear colleagues, Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value. If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations. Best regards, Christian On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsuccess.tr...
2) https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.sucur... <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.sucuri.net%2F2021%2F02%2Fuceprotect-when-rbls-go-bad.html&data=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BTvsNRt4eyvmEkZT4rq2x09%2FJ%2FsIjRpMx%2FgpCRV0x6o%3D&reserved=0>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprot... <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprotect.net%2Fen%2Frblcheck.php&data=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yKEjd8cb%2BalJ440LDeiSqKWRZJwkNByV1MxCJ9Z36ZE%3D&reserved=0>]. It asks for a fee if some individual IP address wants to be whitelisted (https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.whiteli... <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.whitelisted.org%2F&data=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RZRKBzzZ5URWLRov0TpfqnMECng%2FC7Xp09aDC6VfYUE%3D&reserved=0>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprot... <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprotect.net%2Fen%2Findex.php%3Fm%3D8%26s%3D0&data=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tcTOzuCEh9X4PScwIWD4K9O5mCjZ0KeX%2FgJH6qFigGc%3D&reserved=0>; https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprot... <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprotect.org%2Fcart00neys%2Findex.html&data=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wILz2CGHYrLz2S2tqsE6lA9PAzJETAPvaCEkGQx0pGg%3D&reserved=0>). And the other type of threatening: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprot... <https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uceprotect.org%2F&data=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f5c4kh0%2FM1kBzOOt4IBOScm8O0PmN5tVcCpaPR51dP8%3D&reserved=0> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
On 2021-03-04 18:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
Hello, Christian, Thank you for your response. Let me express how I see this. I've checked the content explanation of the Blacklist entries widget:
This visualisation is based on data from different sources. The blacklists were selected based on availability and data access policies, and _are not necessarily the best representation_ of the vast number of blacklists which currently exist.
I do understand the approach of remaining neutral and thank you for clarification that RIPE neither endorses nor supports UCEProtect practices. The intention to hear from the community while some providers still use this blacklist seems logical to me. But I would disagree with usefulness to be the only criterion to be taken into consideration. Being an RIR, RIPE NCC and its tools inevitably are/may not only viewed in the light of usefulness but as a trustful and reliable source. In other words: we are neutral, but we trust this source, at least to some extend. And I don't believe the RIR's goal of being viewed as simply representing the existing reality that some providers still use UCEProtect can be fully achieved. RIPEStat, contrary to let's say MXToolbox that decided to keep UCEprotect for now ('We will watch this issue but will also continue to show UCEPROTECT listings as long as they are being used for email delivery decisions') [https://blog.mxtoolbox.com/2021/02/12/recent-spikes-on-uce-protect-level-3/], is not intended for email diagnostics specifically. (Or is it?) Given that, if RIPE NCC and its community doesn't trust UCEProtect and if RIPEStat is not an email diagnostics tool, I'd say against keeping them in the widget. -- Regards, Kristijonas
Given that, if RIPE NCC and its community doesn't trust UCEProtect
my impression is that this wg does not really like or trust anything. it's all about not liking and rage at the machine. imiho, it is very useful that ripe stat has longitudinal measurement data on a few anti-spam technologies. if you want change, perhaps we should play to the up side, and suggest a few, stress few, more. i use dnswl, mail-abuse.org, sorbs, and spamhaus. and i am utterly bored by comments that one or more of them is the spawn of satan. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header mangling
El jue, 04-03-2021 a las 17:16 +0100, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
Hello Christian I think there are two issues at hand here. First one is the realiability of uceprotect. A dnsbl SHOULD be neutral. A blacklist which accepts payments for delisting seems shady by itself, even if actually done with the best intentions. Due to this it has long been considered as not a source to trust or care about (unlike their policy with many other blacklists). But a network choosing to care (or not) for a blacklist, or a BL deciding to seek payments, are their own decisions. However, what I find really worrying are the reports of uceprotect intentionally increasing their to list more addresses, or even inserting "hits" for ip addresses which cannot have produced the alledged hits. This would make them misleading at best, if not directly mischievous. PLease note this is just from a technical point of view. Issues of "non-professionalism" are a separate matter. A blacklist operator should be able to know why and even justify, if needed, why it listed an IP address. To a trusted third party, for instance. If it is / became a predatory blacklist, that's enough reason not to include it, as that would be a way of promoting it. Second issue is the number of entries. I would consider that the more (good) blacklists included, the better. I would still not include a predatory blacklist there, as the mere listing gives them a sense of legitimacy. This can be conflated with the number of lists but is actually different. If you include many blacklists (e.g. mxtoolbox checks 94), it's easier to include lower-quality ones, as the exposure given to them is more diluted. If you only list a couple of lists, that makes them look like they are "the important ones". Even if it was never the intent. Best regards PS: And yes, the NP-hard problem is telling apart the good from the evil. In some cases it can be simple, but it often is not. -- INCIBE-CERT - Spanish National CSIRT https://www.incibe-cert.es/ PGP keys: https://www.incibe-cert.es/en/what-is-incibe-cert/pgp-public-keys ==================================================================== INCIBE-CERT is the Spanish National CSIRT designated for citizens, private law entities, other entities not included in the subjective scope of application of the "Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público", as well as digital service providers, operators of essential services and critical operators under the terms of the "Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información" that transposes the Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union. ==================================================================== In compliance with the General Data Protection Regulation of the EU (Regulation EU 2016/679, of 27 April 2016) we inform you that your personal and corporate data (as well as those included in attached documents); and e-mail address, may be included in our records for the purpose derived from legal, contractual or pre-contractual obligations or in order to respond to your queries. You may exercise your rights of access, correction, cancellation, portability, limitationof processing and opposition under the terms established by current legislation and free of charge by sending an e-mail to dpd@incibe.es. The Data Controller is S.M.E. Instituto Nacional de Ciberseguridad de España, M.P., S.A. More information is available on our website: https://www.incibe.es/proteccion-datos-personales and https://www.incibe.es/registro-actividad. ====================================================================
i think two things are being confused here; what the measurement folk find useful and what the anti-spam folk find useful. the ncc and ripe stat is not supplying the latter. it is the mail operators' choice of which anti-spam techniques to use, and i do that with one hat. but with a different hat i am interested in longitudinal measurement of internet infrastructure, anti-spam services being a small part of it. i suspect that what you really want is (for example) maawg to measure availibility and quality of *all* anti-spam services. while worthwhile, that is not the ripe stat's measurement mission. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header mangling
Since you brought up m3aawg I will note that it does have a best current practice for block lists which specifically declares that asking for payment for removal is not acceptable RIPE should consider only listing block lists that are managed according to accepted best practices https://www.m3aawg.org/sites/default/files/m3aawg-blocklist-help-bp-2018-02.... There are also blocklists that expect payment for delisting. M3AAWG strongly discourages the practice of blocklist operators charging delisting fees in any form; we acknowledge that under some exigent situations, listed entities may choose to pay such fees. For example, paying a delisting fee may be a viable option for senders who are able to quickly identify the underlying problem, solve it, and have no issue paying such fees. However, failure to identify and solve the problem sets the sender up for future listings and, thus, future delisting fees. Furthermore, a payment does not preclude future listings for repeated problems or different issues. --srs ________________________________ From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Randy Bush <randy@psg.com> Sent: Friday, March 5, 2021 1:21:18 AM To: "Ángel González Berdasco" <angel.gonzalez@incibe.es> Cc: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget i think two things are being confused here; what the measurement folk find useful and what the anti-spam folk find useful. the ncc and ripe stat is not supplying the latter. it is the mail operators' choice of which anti-spam techniques to use, and i do that with one hat. but with a different hat i am interested in longitudinal measurement of internet infrastructure, anti-spam services being a small part of it. i suspect that what you really want is (for example) maawg to measure availibility and quality of *all* anti-spam services. while worthwhile, that is not the ripe stat's measurement mission. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header mangling
On Thu 04/Mar/2021 17:16:34 +0100 Christian Teuschel wrote:
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
https://stat.ripe.net/data-sources mentions spamhaus and uceprotect. Couldn't it just mention multirbl.valli.org? Best Ale --
Hi Christian, As others have pointed out, even purely on a technical level, they are not any kind of trustworthy source as paying to be delisted creates a very bad incentive for them. I agree that in general more lists should be added, but uceprotect should be removed, because just listing it does (whether intended or not) give it some legitimacy in the eyes of many (I assume). I can understand that the sexist comments could be overlooked from the point of view of RIPEstat if you had a list far larger including pretty much every list that is semi-common. However, the fact that it is basically based on extortion inherently results in a very low quality blocklist. I know I have repeated myself a bit here, but I feel it is important to point out that disregarding their awful business practices, it is just very bad on a technical level too. -Cynthia On Thu, Mar 4, 2021 at 5:16 PM Christian Teuschel <cteusche@ripe.net> wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1)
https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
<
https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE
NOT!
Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by
On 04/03/2021 09:54, Elvis Daniel Velea wrote: publishing
conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
Hi! Let me start saying that it seems to me that UCEPROTECT doesn't follow their own stated policies. If it is so, it is a bad list. But I'd like to discuss a principle here which I think I'd like to know opinions of. On 05.03.21 11:38, Cynthia Revström via anti-abuse-wg wrote:
As others have pointed out, even purely on a technical level, they are not any kind of trustworthy source as paying to be delisted creates a very bad incentive for them.
We have a situation where your IP address has landed in a DNSBL as collateral damage. You're hosted in the same subnet with a spammer, for example, so it is an escalation listing. Which one is preferable? 1. no chance of whitelisting your IP (as is the case with SORBS, and I think many other DNSBL operators), so you either need to move out, or convince the hosting provider to fix the issue 2. you can get a whitelisting done (possibly for a (relatively small) fee). Personally I'd prefer to have an option of 2. Having a small fee would motivate me to talk with the hosting provider first, to get their act together. Let's forget how UCEPROTECT is messing up, let's discuss this as a principle. Yours, esa -- Mr Esa Laitinen IM: https://threema.id/2JP4Y33R or https://signal.org/install Skype: reunaesa Mobile: +4178 838 57 77
I personally feel like it's impossible to have a neutral list if you charge for delisting. Regardless of what might be the best solution, I feel like there is no way* to do this that isn't subject to abuse. Like if your business model is getting fees for delist requests, it's going to be close to impossible to keep it neutral. * Within reason, like you come up with ideas as proof of donation to a charity if you want to have a filter against people spamming. But that will always have some issues too. -Cynthia On Fri, Mar 5, 2021, 11:59 Esa Laitinen <esa@laitinen.org> wrote:
Hi!
Let me start saying that it seems to me that UCEPROTECT doesn't follow their own stated policies. If it is so, it is a bad list. But I'd like to discuss a principle here which I think I'd like to know opinions of.
On 05.03.21 11:38, Cynthia Revström via anti-abuse-wg wrote:
As others have pointed out, even purely on a technical level, they are not any kind of trustworthy source as paying to be delisted creates a very bad incentive for them.
We have a situation where your IP address has landed in a DNSBL as collateral damage. You're hosted in the same subnet with a spammer, for example, so it is an escalation listing.
Which one is preferable?
1. no chance of whitelisting your IP (as is the case with SORBS, and I think many other DNSBL operators), so you either need to move out, or convince the hosting provider to fix the issue
2. you can get a whitelisting done (possibly for a (relatively small) fee).
Personally I'd prefer to have an option of 2. Having a small fee would motivate me to talk with the hosting provider first, to get their act together.
Let's forget how UCEPROTECT is messing up, let's discuss this as a principle.
Yours,
esa
-- Mr Esa Laitinen IM: https://threema.id/2JP4Y33R or https://signal.org/install Skype: reunaesa Mobile: +4178 838 57 77
I feel the same. You cannot be neutral if you charge for a delisting. Moreover it's obvious that the charging for delisting is there business modell. 89CHF (about 80€) for a single ip in Level-1?! 249CHF Level-2 and 449CHF Level-3. Sorry Esa, that's not a small fee. And even if they would charge a fee, it's not ok. If we all agree with it it would open the door for more and more blacklists to establish such a model. I think everyone can imagine that your ip will be listed rather sooner than later because they make money in such a way. So you cannot be a neutral blacklist and nobody should accept and better, use, such blacklists. I understand that the widget should give an overview about listings but it doesn't make sense with just two lists and moreover one of them is UCEPROTECT. If you want to be a neutral player you should extend the widget (more sth like MXToolbox). If it's not possible the widget should be set aside because you give UCEPROTECT a false legimacy (even if you don't want that). Am 05.03.21 um 13:25 schrieb Cynthia Revström via anti-abuse-wg:
I personally feel like it's impossible to have a neutral list if you charge for delisting.
Regardless of what might be the best solution, I feel like there is no way* to do this that isn't subject to abuse.
Like if your business model is getting fees for delist requests, it's going to be close to impossible to keep it neutral.
* Within reason, like you come up with ideas as proof of donation to a charity if you want to have a filter against people spamming. But that will always have some issues too.
-Cynthia
On Fri, Mar 5, 2021, 11:59 Esa Laitinen <esa@laitinen.org <mailto:esa@laitinen.org>> wrote:
Hi!
Let me start saying that it seems to me that UCEPROTECT doesn't follow their own stated policies. If it is so, it is a bad list. But I'd like to discuss a principle here which I think I'd like to know opinions of.
On 05.03.21 11:38, Cynthia Revström via anti-abuse-wg wrote: > As others have pointed out, even purely on a technical level, they are > not any kind of trustworthy source as paying to be delisted creates a > very bad incentive for them.
We have a situation where your IP address has landed in a DNSBL as collateral damage. You're hosted in the same subnet with a spammer, for example, so it is an escalation listing.
Which one is preferable?
1. no chance of whitelisting your IP (as is the case with SORBS, and I think many other DNSBL operators), so you either need to move out, or convince the hosting provider to fix the issue
2. you can get a whitelisting done (possibly for a (relatively small) fee).
Personally I'd prefer to have an option of 2. Having a small fee would motivate me to talk with the hosting provider first, to get their act together.
Let's forget how UCEPROTECT is messing up, let's discuss this as a principle.
Yours,
esa
-- Mr Esa Laitinen IM: https://threema.id/2JP4Y33R <https://threema.id/2JP4Y33R> or https://signal.org/install <https://signal.org/install> Skype: reunaesa Mobile: +4178 838 57 77
-- Mit freundlichem Gruß Artfiles New Media GmbH Andreas Worbs Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support@artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478
i am just a measurement guy who wandered over here because who doesn't like the smell of blood in the water. as this discission is about what ripe stat has been doing measurement stats on since dirt was invented, perhaps the mat wg should have been where this discussion occurred. at least it should be consulted now. randy
Dear colleagues, Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there. Let me know if this approach works for you. Best regards, Christian On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html> UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
May I suggest that you add as many more blocklists as you can (RBL is a specific blocklist founded by MAPS and now acquired by Trend Micro so that term isn’t used in the industry), as long as they are well maintained and conform to best practices. Thanks --srs From: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> on behalf of Christian Teuschel <cteusche@ripe.net> Date: Tuesday, 9 March 2021 at 3:07 PM To: anti-abuse-wg@ripe.net <anti-abuse-wg@ripe.net> Subject: Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget Dear colleagues, Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there. Let me know if this approach works for you. Best regards, Christian On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
On Tue 09/Mar/2021 10:37:17 +0100 Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
May I suggest this list of 345 RBLs? http://multirbl.valli.org/list/ Best Ale --
Dear colleagues, I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March. We will then get started on an analysis that we will share with the community a little later in the year. Kind regards Christian On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html> UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel RIPE NCC | @christian_toysh
Hi Christian, as IPv4 Broker, V4Escrow has been scanning IP blocks in blacklists almost since its inception. We've done this to offer interested parties enough information to do a due diligence as complete as possible (we also provide them with routing information history from ripe stats, whois and whowas information from whoever makes it available, transfer history, geolocation information, etc). We've noticed that our customers appreciate it to know whether the IPs they want to transfer are listed in blacklists. Both offering parties are interested in this information (and most of the times they will 'clean' the IPs before listing them for sale) and, more importantly, receiving parties. We've noticed that a large majority of our customers will definitely refuse to purchase rights to IPs if these are listed in some specific blacklists while some others don't really care about that and only want to purchase the rights to the cheapest IPs. That's why sometimes the rights to the IPs listed in blacklists will sell for less. From our experience, one of the most important blacklist is the Spamhaus DROP. Then follow (in no particular order) the Spamhaus SBL, the Sorbs, the Barracudas, junkermail, justspam, spamrats, spamcop, uceprotect and a few others. We've noticed that some blacklists require money to delist the blocks. We try to give them less importance when calculating the 'cleanliness' score of an IP block. We believe that the process of cleaning an IP or a block of IPs should be swift and simple - as soon as the abuse has stopped (some blacklists remove an IP automatically after 7 days) or once the holder of the IPs can prove there is no more abuse coming from those IPs. What we were amazed to see is that some IPs which have been allocated, returned to the free pool, re-allocated and then transferred (3-4 different orgs over the timespan of 10-15 years) are still listed because the initial org has done something (wrong) in 2010.. That was very strange to see.. moreover, getting those IPs cleaned from some blacklists has proven to be very challenging. We've generated a list of blacklists that we maintain constantly. I'll paste below the complete list of blacklists we check against with every IP block we broker: "0spam.fusionzero.com", "0spamtrust.fusionzero.com", "0spam-killlist.fusionzero.com", "0spamurl.fusionzero.com", "uribl.zeustracker.abuse.ch", "ipbl.zeustracker.abuse.ch", "rbl.abuse.ro", "uribl.abuse.ro", "spam.dnsbl.anonmails.de", "dnsbl.anticaptcha.net", "dnsbl6.anticaptcha.net", "orvedb.aupads.org", "rsbl.aupads.org", "block.ascams.com", "superblock.ascams.com", "aspews.ext.sorbs.net", "ips.backscatterer.org", "b.barracudacentral.org", "bb.barracudacentral.org", "list.bbfh.org", "l1.bbfh.ext.sorbs.net", "l2.bbfh.ext.sorbs.net", "l3.bbfh.ext.sorbs.net", "l4.bbfh.ext.sorbs.net", "all.v6.ascc.dnsbl.bit.nl", "all.dnsbl.bit.nl", "ipv6.all.dnsbl.bit.nl", "bitonly.dnsbl.bit.nl", "rbl.blakjak.net", "netscan.rbl.blockedservers.com", "rbl.blockedservers.com", "spam.rbl.blockedservers.com", "list.blogspambl.com", "bsb.empty.us", "bsb.spamlookup.net", "query.bondedsender.org", "plus.bondedsender.org", "dnsbl1.dnsbl.borderware.com", "dnsbl2.dnsbl.borderware.com", "dnsbl3.dnsbl.borderware.com", "dul.dnsbl.borderware.com", "blacklist.sci.kun.nl", "whitelist.sci.kun.nl", "dul.blackhole.cantv.net", "hog.blackhole.cantv.net", "rhsbl.blackhole.cantv.net", "rot.blackhole.cantv.net", "spam.blackhole.cantv.net", "cbl.anti-spam.org.cn", "cblplus.anti-spam.org.cn", "cblless.anti-spam.org.cn", "cdl.anti-spam.org.cn", "cml.anti-spam.org.cn", "cbl.abuseat.org", "rbl.choon.net", "rwl.choon.net", "ipv6.rbl.choon.net", "ipv6.rwl.choon.net", "dnsbl.cyberlogic.net", "bogons.cymru.com", "v4.fullbogons.cymru.com", "v6.fullbogons.cymru.com", "origin6.asn.cymru.com", "tor.dan.me.uk", "torexit.dan.me.uk", "ex.dnsbl.org", "in.dnsbl.org", "rbl.dns-servicios.com", "dnsbl.calivent.com.pe", "dnsbl.mcu.edu.tw", "dnsbl.net.ua", "dnsbl.othello.ch", "dnsbl.rv-soft.info", "dnsblchile.org", "dnsrbl.org", "list.dnswl.org", "vote.drbl.caravan.ru", "work.drbl.caravan.ru", "vote.drbldf.dsbl.ru", "work.drbldf.dsbl.ru", "vote.drbl.gremlin.ru", "work.drbl.gremlin.ru", "bl.drmx.org", "dnsbl.dronebl.org", "rbl.efnet.org", "rbl.efnetrbl.org", "tor.efnet.org", "bl.emailbasura.org", "rbl.fasthosts.co.uk", "bl.fmb.la", "communicado.fmb.la", "nsbl.fmb.la", "sa.fmb.la", "short.fmb.la", "fnrbl.fast.net", "88.blocklist.zap", "hil.habeas.com", "accredit.habeas.com", "sa-accredit.habeas.com", "hul.habeas.com", "sohul.habeas.com", "hostkarma.junkemailfilter.com", "nobl.junkemailfilter.com", "dnsbl.cobion.com", "spamrbl.imp.ch", "wormrbl.imp.ch", "dnsbl.inps.de", "dnswl.inps.de", "rbl.interserver.net", "rbl.iprange.net", "iadb.isipp.com", "iadb2.isipp.com", "iddb.isipp.com", "wadb.isipp.com", "whitelist.rbl.ispa.at", "mail-abuse.blacklist.jippg.org", "dnsbl.justspam.org", "dnsbl.kempt.net", "spamlist.or.kr", "bl.konstant.no", "admin.bl.kundenserver.de", "relays.bl.kundenserver.de", "schizo-bl.kundenserver.de", "spamblock.kundenserver.de", "worms-bl.kundenserver.de", "spamguard.leadmon.net", "rbl.lugh.ch", "dnsbl.madavi.de", "blacklist.mailrelay.att.net", "bl.mailspike.net", "rep.mailspike.net", "wl.mailspike.net", "z.mailspike.net", "bl.mav.com.br", "rbl.megarbl.net", "dnsbl.forefront.microsoft.com", "bl.mipspace.com", "combined.rbl.msrbl.net", "images.rbl.msrbl.net", "phishing.rbl.msrbl.net", "spam.rbl.msrbl.net", "virus.rbl.msrbl.net", "web.rbl.msrbl.net", "relays.nether.net", "trusted.nether.net", "unsure.nether.net", "ix.dnsbl.manitu.net", "no-more-funn.moensted.dk", "wl.nszones.com", "sbl.nszones.com", "ubl.nszones.com", "dnsbl.openresolvers.org", "blacklist.mail.ops.asp.att.net", "blacklist.sequoia.ops.asp.att.net", "spam.pedantic.org", "pofon.foobar.hu", "ispmx.pofon.foobar.hu", "uribl.pofon.foobar.hu", "safe.dnsbl.prs.proofpoint.com", "bad.psky.me", "psbl.surriel.com", "whitelist.surriel.com", "all.rbl.jp", "dyndns.rbl.jp", "short.rbl.jp", "url.rbl.jp", "virus.rbl.jp", "rbl.schulte.org", "rbl.talkactive.net", "rbl.zenon.net", "rbl.realtimeblacklist.com", "access.redhawk.org", "eswlrev.dnsbl.rediris.es", "mtawlrev.dnsbl.rediris.es", "abuse.rfc-clueless.org", "bogusmx.rfc-clueless.org", "dsn.rfc-clueless.org", "elitist.rfc-clueless.org", "fulldom.rfc-clueless.org", "postmaster.rfc-clueless.org", "whois.rfc-clueless.org", "dnsbl.rizon.net", "mailsl.dnsbl.rjek.com", "urlsl.dnsbl.rjek.com", "dynip.rothen.com", "dnsbl.rymsho.ru", "rhsbl.rymsho.ru", "all.s5h.net", "public.sarbl.org", "rhsbl.scientificspam.net", "bl.scientificspam.net", "reputation-domain.rbl.scrolloutf1.com", "reputation-ip.rbl.scrolloutf1.com", "reputation-ns.rbl.scrolloutf1.com", "tor.dnsbl.sectoor.de", "exitnodes.tor.dnsbl.sectoor.de", "rf.senderbase.org", "query.senderbase.org", "sa.senderbase.org", "bl.score.senderscore.com", "score.senderscore.com", "singular.ttk.pte.hu", "dnsbl.sorbs.net", "problems.dnsbl.sorbs.net", "proxies.dnsbl.sorbs.net", "relays.dnsbl.sorbs.net", "safe.dnsbl.sorbs.net", "nomail.rhsbl.sorbs.net", "badconf.rhsbl.sorbs.net", "dul.dnsbl.sorbs.net", "zombie.dnsbl.sorbs.net", "block.dnsbl.sorbs.net", "escalations.dnsbl.sorbs.net", "http.dnsbl.sorbs.net", "misc.dnsbl.sorbs.net", "smtp.dnsbl.sorbs.net", "socks.dnsbl.sorbs.net", "rhsbl.sorbs.net", "spam.dnsbl.sorbs.net", "recent.spam.dnsbl.sorbs.net", "new.spam.dnsbl.sorbs.net", "old.spam.dnsbl.sorbs.net", "web.dnsbl.sorbs.net", "korea.services.net", "geobl.spameatingmonkey.net", "backscatter.spameatingmonkey.net", "badnets.spameatingmonkey.net", "bl.spameatingmonkey.net", "fresh.spameatingmonkey.net", "fresh10.spameatingmonkey.net", "fresh15.spameatingmonkey.net", "bl.ipv6.spameatingmonkey.net", "netbl.spameatingmonkey.net", "uribl.spameatingmonkey.net", "urired.spameatingmonkey.net", "netblockbl.spamgrouper.to", "bl.spamcannibal.org", "bl.spamcop.net", "_vouch.dwl.spamhaus.org", "pbl.spamhaus.org", "sbl.spamhaus.org", "sbl-xbl.spamhaus.org", "swl.spamhaus.org", "xbl.spamhaus.org", "feb.spamlab.com", "rbl.spamlab.com", "all.spamrats.com", "dyna.spamrats.com", "noptr.spamrats.com", "spam.spamrats.com", "spamsources.fabel.dk", "bl.spamstinks.com", "dul.pacifier.net", "bl.suomispam.net", "dbl.suomispam.net", "gl.suomispam.net", "multi.surbl.org", "srn.surgate.net", "dnsrbl.swinog.ch", "uribl.swinog.ch", "rbl.tdk.net", "st.technovision.dk", "dob.sibl.support-intelligence.net", "dbl.tiopan.com", "bl.tiopan.com", "dnsbl.tornevall.org", "r.mail-abuse.com", "q.mail-abuse.com", "rbl2.triumf.ca", "wbl.triumf.ca", "truncate.gbudb.net", "dunk.dnsbl.tuxad.de", "hartkore.dnsbl.tuxad.de", "dnsbl-0.uceprotect.net", "dnsbl-1.uceprotect.net", "dnsbl-2.uceprotect.net", "dnsbl-3.uceprotect.net", "ubl.unsubscore.com", "virbl.dnsbl.bit.nl", "all.rbl.webiron.net", "babl.rbl.webiron.net", "cabl.rbl.webiron.net", "crawler.rbl.webiron.net", "stabl.rbl.webiron.net", "ips.whitelisted.org", "blacklist.woody.ch", "ipv6.blacklist.woody.ch", "uri.blacklist.woody.ch", "db.wpbl.info", "bl.blocklist.de", "dnsbl.zapbl.net", "rhsbl.zapbl.net", Out of all these, in the past couple of years we have stopped using some (see the following list, and more) as we were getting bogus data/responses: bl.emailbasura.org rbl.megarbl.net bl.spamcannibal.org hartkore.dnsbl.tuxad.de dunk.dnsbl.tuxad.de v6.fullbogons.cymru.com query.senderbase.org sa.senderbase.org Hope this can help. Kind regards, Elvis Velea V4Escrow CEO www.v4escrow.com On 3/12/21 12:51 AM, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html>
UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
Dear colleagues, Thank you for your suggestions and input. Here is an update on what we plan to do next: We will continue looking at blocklist candidates and prepare an analysis/implementation plan. This will be done with a small group of experts who volunteered to help with the vetting process (contact me off-list if you would like to join this group). This work will start in Q3. Once implemented, the changes will be available via the new RIPEstat UI. We might also add filters that allow you to decide which sources to use - with a smaller set of blocklists selected by default. Another outcome is that we will also change the name from "blacklist" to "blocklist". This will have an impact on API endpoints, widgets and documenation. Work on this will start next week. We will update this working group once our analysis is ready. In the meantime, if you are interested in RIPEstat, we also post developments on Twitter under #RIPEstat. Best regards, Christian On 12/03/2021 09:51, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote:
Hello,
I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget.
There have been controversial positions about this blacklist recently:
1) https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R...
2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html> UCEPROTECT blacklists the whole range of IP addresses, including the full IP range of some autonomous systems: UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! Your IP was NOT directly involved in abuse but has a bad neighborhood. Other customers within this range did not care about their security and got hacked, started spamming, or were even attacking others, while your provider has possibly not even noticed that there is a serious problem. We are sorry for you, but you have chosen a provider not acting fast enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php <http://www.uceprotect.net/en/rblcheck.php>]. It asks for a fee if some individual IP address wants to be whitelisted (http://www.whitelisted.org/ <http://www.whitelisted.org/>), It abuses people who decide to challenge their blacklist by publishing conversations in their so-called /Cart00ney/ (http://www.uceprotect.net/en/index.php?m=8&s=0 <http://www.uceprotect.net/en/index.php?m=8&s=0>; http://www.uceprotect.org/cart00neys/index.html <http://www.uceprotect.org/cart00neys/index.html>). And the other type of threatening: http://www.uceprotect.org/ <http://www.uceprotect.org/> Does RIPE NCC have any position on this specific blacklist?
Thank you!
-- Christian Teuschel | @christian_toysh RIPE NCC
Dear colleagues, I would like to share a short update regarding the Blocklist project for RIPEstat. As you might have noticed, we changed the name to “blocklist” earlier this year in March. This month, we started evaluating new blocklists with the support of a panel of seven domain experts. Once the evaluation phase has been completed, we will share a fresh update. You can follow more detailed design decisions on our public feature tracker: https://ripestat.featureupvote.com/suggestions/196464/project-blocklists-202... To make sure you get all the latest news and updates on Twitter, follow #RIPEstat Best regards, Christian On 19/03/2021 14:24, Christian Teuschel wrote:
Dear colleagues,
Thank you for your suggestions and input. Here is an update on what we plan to do next:
We will continue looking at blocklist candidates and prepare an analysis/implementation plan. This will be done with a small group of experts who volunteered to help with the vetting process (contact me off-list if you would like to join this group).
This work will start in Q3. Once implemented, the changes will be available via the new RIPEstat UI. We might also add filters that allow you to decide which sources to use - with a smaller set of blocklists selected by default.
Another outcome is that we will also change the name from "blacklist" to "blocklist". This will have an impact on API endpoints, widgets and documenation. Work on this will start next week.
We will update this working group once our analysis is ready. In the meantime, if you are interested in RIPEstat, we also post developments on Twitter under #RIPEstat.
Best regards,
Christian
On 12/03/2021 09:51, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote:
Dear colleagues,
RIPEstat is a neutral source of information and we aim to provide users with access to as many data sources as possible to provide insights.
UCEProtect was added as a data source prior to 2010 and is still used by several network operators to filter traffic into their networks. Including it as a data source in RIPEstat allows users to see whether resources are included in their lists.
RIPE NCC does not pay for, support or endorse their practices, although we understand that continuing to include UCEProtect as a data source could be misunderstood as such. We also do not use their lists to filter traffic on our services.
Our goal remains to provide the best visibility and tools for network operators to diagnose their networks. We have also heard your feedback regarding including more RBLs. It is something that we have considered in the past, and we are open to revisiting this.
RIPEstat is driven by the community. We would like to hear from you about whether including UCEProtect as a data source is useful.
Regards, Christian
On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote: > Hello, > > I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and > uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. > > There have been controversial positions about this blacklist recently: > > 1) > https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... > > <https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security> > > 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html > <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html> > > UCEPROTECT blacklists the whole range of IP addresses, including the > full IP range of some autonomous systems: > UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! > Your IP was NOT directly involved in abuse but has a bad neighborhood. > Other customers within this range did not care about their security and > got hacked, started spamming, or were even attacking others, while your > provider has possibly not even noticed that there is a serious problem. > We are sorry for you, but you have chosen a provider not acting fast > enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php > <http://www.uceprotect.net/en/rblcheck.php>]. > It asks for a fee if some individual IP address wants to be > whitelisted > (http://www.whitelisted.org/ <http://www.whitelisted.org/>), > It abuses people who decide to challenge their blacklist by publishing > conversations in their so-called /Cart00ney/ > (http://www.uceprotect.net/en/index.php?m=8&s=0 > <http://www.uceprotect.net/en/index.php?m=8&s=0>; > http://www.uceprotect.org/cart00neys/index.html > <http://www.uceprotect.org/cart00neys/index.html>). > And the other type of threatening: http://www.uceprotect.org/ > <http://www.uceprotect.org/> > Does RIPE NCC have any position on this specific blacklist? > > Thank you!
-- Christian Teuschel @christian_toysh RIPE NCC
Dear colleagues, In preparation for the upcoming AA-WG session, I want to provide an update on the status of the revamp of the blocklist feature on RIPEstat. In 2021 and since the last status update we collected and reviewed a set of blocklists that we would see ideal to be included. We did this together with the help of our panel of domain experts. Following the review, we performed a technical feasibility analysis, which filtered the blocklists related to supported resource type (IP and domain) and access method (DNS). For each of the remaining blocklists, we started to contact the respective operator and asked for permission to use the blocklist on RIPEstat. The technical implementation of the required backend started with a delay but we are glad to report that we finished the development last month and released the feature a week ago. Currently, the best way to use the new feature is via this RIPEstat widget: https://stat.ripe.net/widget/dns-blocklists Some details on the current solution: - The data is fetched in realtime unless cached (with a maximum cache time of 2 hours) - The supported resource type is a single IP address (IPv4 & Ipv6) - To prevent abuse a daily rate limit of 100 uncached queries per user is in place What we want to do next: - Extend the number of blocklists - Add support for domain queries - Include the feature in the new UI (UI2020) - Add a similar API for whitelists As we are still reaching out to some blocklist operators it is unclear how many blocklists will be included but we expect the number to be significantly higher than the old blocklist API call. Soon we will also review whether the new blocklist feature is mature enough to replace the old one. All details on the project planning are available here: https://ripestat.featureupvote.com/suggestions/196464/project-blocklists-202... Last but not least I want to thank the participants of the panel for their invaluable input and support! I hope you find the new feature useful and I am looking forward to your feedback. All the best, Christian On 08/07/2021 10:21, Christian Teuschel wrote:
Dear colleagues,
I would like to share a short update regarding the Blocklist project for RIPEstat. As you might have noticed, we changed the name to “blocklist” earlier this year in March.
This month, we started evaluating new blocklists with the support of a panel of seven domain experts. Once the evaluation phase has been completed, we will share a fresh update.
You can follow more detailed design decisions on our public feature tracker: https://ripestat.featureupvote.com/suggestions/196464/project-blocklists-202...
To make sure you get all the latest news and updates on Twitter, follow #RIPEstat
Best regards, Christian
On 19/03/2021 14:24, Christian Teuschel wrote:
Dear colleagues,
Thank you for your suggestions and input. Here is an update on what we plan to do next:
We will continue looking at blocklist candidates and prepare an analysis/implementation plan. This will be done with a small group of experts who volunteered to help with the vetting process (contact me off-list if you would like to join this group).
This work will start in Q3. Once implemented, the changes will be available via the new RIPEstat UI. We might also add filters that allow you to decide which sources to use - with a smaller set of blocklists selected by default.
Another outcome is that we will also change the name from "blacklist" to "blocklist". This will have an impact on API endpoints, widgets and documenation. Work on this will start next week.
We will update this working group once our analysis is ready. In the meantime, if you are interested in RIPEstat, we also post developments on Twitter under #RIPEstat.
Best regards,
Christian
On 12/03/2021 09:51, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote: > Dear colleagues, > > RIPEstat is a neutral source of information and we aim to provide users > with access to as many data sources as possible to provide insights. > > UCEProtect was added as a data source prior to 2010 and is still used by > several network operators to filter traffic into their networks. > Including it as a data source in RIPEstat allows users to see whether > resources are included in their lists. > > RIPE NCC does not pay for, support or endorse their practices, although > we understand that continuing to include UCEProtect as a data source > could be misunderstood as such. We also do not use their lists to filter > traffic on our services. > > Our goal remains to provide the best visibility and tools for network > operators to diagnose their networks. We have also heard your feedback > regarding including more RBLs. It is something that we have considered > in the past, and we are open to revisiting this. > > RIPEstat is driven by the community. We would like to hear from you > about whether including UCEProtect as a data source is useful. > > Regards, > Christian > > On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote: >> Hello, >> >> I noticed that RIPE NCC uses uceprotect-level1, uceprotect-level2 and >> uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. >> >> There have been controversial positions about this blacklist recently: >> >> 1) >> https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-R... >> >> <https://success.trendmicro.com/solution/000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security> >> >> 2) https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html >> <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html> >> >> UCEPROTECT blacklists the whole range of IP addresses, including the >> full IP range of some autonomous systems: >> UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! >> Your IP was NOT directly involved in abuse but has a bad neighborhood. >> Other customers within this range did not care about their security and >> got hacked, started spamming, or were even attacking others, while your >> provider has possibly not even noticed that there is a serious problem. >> We are sorry for you, but you have chosen a provider not acting fast >> enough on abusers'/) [http://www.uceprotect.net/en/rblcheck.php >> <http://www.uceprotect.net/en/rblcheck.php>]. >> It asks for a fee if some individual IP address wants to be >> whitelisted >> (http://www.whitelisted.org/ <http://www.whitelisted.org/>), >> It abuses people who decide to challenge their blacklist by publishing >> conversations in their so-called /Cart00ney/ >> (http://www.uceprotect.net/en/index.php?m=8&s=0 >> <http://www.uceprotect.net/en/index.php?m=8&s=0>; >> http://www.uceprotect.org/cart00neys/index.html >> <http://www.uceprotect.org/cart00neys/index.html>). >> And the other type of threatening: http://www.uceprotect.org/ >> <http://www.uceprotect.org/> >> Does RIPE NCC have any position on this specific blacklist? >> >> Thank you! >
-- Christian Teuschel @christian_toysh RIPE NCC
Good evening, Will it be possible to show per country? Kind regards, Jeroen -----Oorspronkelijk bericht----- Van: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Namens Christian Teuschel Verzonden: woensdag 18 mei 2022 21:46 Aan: anti-abuse-wg@ripe.net Onderwerp: Re: [anti-abuse-wg] Blocklists on RIPEstat (Was: UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget) Dear colleagues, In preparation for the upcoming AA-WG session, I want to provide an update on the status of the revamp of the blocklist feature on RIPEstat. In 2021 and since the last status update we collected and reviewed a set of blocklists that we would see ideal to be included. We did this together with the help of our panel of domain experts. Following the review, we performed a technical feasibility analysis, which filtered the blocklists related to supported resource type (IP and domain) and access method (DNS). For each of the remaining blocklists, we started to contact the respective operator and asked for permission to use the blocklist on RIPEstat. The technical implementation of the required backend started with a delay but we are glad to report that we finished the development last month and released the feature a week ago. Currently, the best way to use the new feature is via this RIPEstat widget: https://stat.ripe.net/widget/dns-blocklists Some details on the current solution: - The data is fetched in realtime unless cached (with a maximum cache time of 2 hours) - The supported resource type is a single IP address (IPv4 & Ipv6) - To prevent abuse a daily rate limit of 100 uncached queries per user is in place What we want to do next: - Extend the number of blocklists - Add support for domain queries - Include the feature in the new UI (UI2020) - Add a similar API for whitelists As we are still reaching out to some blocklist operators it is unclear how many blocklists will be included but we expect the number to be significantly higher than the old blocklist API call. Soon we will also review whether the new blocklist feature is mature enough to replace the old one. All details on the project planning are available here: https://ripestat.featureupvote.com/suggestions/196464/project-blocklists-202... Last but not least I want to thank the participants of the panel for their invaluable input and support! I hope you find the new feature useful and I am looking forward to your feedback. All the best, Christian On 08/07/2021 10:21, Christian Teuschel wrote:
Dear colleagues,
I would like to share a short update regarding the Blocklist project for RIPEstat. As you might have noticed, we changed the name to “blocklist” earlier this year in March.
This month, we started evaluating new blocklists with the support of a panel of seven domain experts. Once the evaluation phase has been completed, we will share a fresh update.
You can follow more detailed design decisions on our public feature tracker: https://ripestat.featureupvote.com/suggestions/196464/project-blocklis ts-2021
To make sure you get all the latest news and updates on Twitter, follow #RIPEstat
Best regards, Christian
On 19/03/2021 14:24, Christian Teuschel wrote:
Dear colleagues,
Thank you for your suggestions and input. Here is an update on what we plan to do next:
We will continue looking at blocklist candidates and prepare an analysis/implementation plan. This will be done with a small group of experts who volunteered to help with the vetting process (contact me off-list if you would like to join this group).
This work will start in Q3. Once implemented, the changes will be available via the new RIPEstat UI. We might also add filters that allow you to decide which sources to use - with a smaller set of blocklists selected by default.
Another outcome is that we will also change the name from "blacklist" to "blocklist". This will have an impact on API endpoints, widgets and documenation. Work on this will start next week.
We will update this working group once our analysis is ready. In the meantime, if you are interested in RIPEstat, we also post developments on Twitter under #RIPEstat.
Best regards,
Christian
On 12/03/2021 09:51, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote:
Hi Christian,
while it may be useful to have their data source, it only shows the RIPE NCC favors one or two operators and I think that is damaging to the whole idea of being impartial.
You either include a good list of blacklist operators and their data or none. Including only a couple will lead to the impression that only those are important enough to be considered by the RIPE NCC.
my 2 cents, Elvis
On 3/3/21 8:27 AM, Christian Teuschel wrote: > Dear colleagues, > > RIPEstat is a neutral source of information and we aim to > provide users with access to as many data sources as possible to provide insights. > > UCEProtect was added as a data source prior to 2010 and is still > used by several network operators to filter traffic into their networks. > Including it as a data source in RIPEstat allows users to see > whether resources are included in their lists. > > RIPE NCC does not pay for, support or endorse their practices, > although we understand that continuing to include UCEProtect as > a data source could be misunderstood as such. We also do not use > their lists to filter traffic on our services. > > Our goal remains to provide the best visibility and tools for > network operators to diagnose their networks. We have also heard > your feedback regarding including more RBLs. It is something > that we have considered in the past, and we are open to revisiting this. > > RIPEstat is driven by the community. We would like to hear from > you about whether including UCEProtect as a data source is useful. > > Regards, > Christian > > On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote: >> Hello, >> >> I noticed that RIPE NCC uses uceprotect-level1, >> uceprotect-level2 and >> uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. >> >> There have been controversial positions about this blacklist recently: >> >> 1) >> https://success.trendmicro.com/solution/000236583-Emails-being- >> rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-S >> ecurity >> >> <https://success.trendmicro.com/solution/000236583-Emails-being >> -rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email- >> Security> >> >> 2) >> https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.htm >> l >> <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.ht >> ml> >> >> UCEPROTECT blacklists the whole range of IP addresses, >> including the full IP range of some autonomous systems: >> UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! >> Your IP was NOT directly involved in abuse but has a bad neighborhood. >> Other customers within this range did not care about their >> security and got hacked, started spamming, or were even >> attacking others, while your provider has possibly not even noticed that there is a serious problem. >> We are sorry for you, but you have chosen a provider not acting >> fast enough on abusers'/) >> [http://www.uceprotect.net/en/rblcheck.php >> <http://www.uceprotect.net/en/rblcheck.php>]. >> It asks for a fee if some individual IP address wants to be >> whitelisted (http://www.whitelisted.org/ >> <http://www.whitelisted.org/>), >> It abuses people who decide to challenge their blacklist by >> publishing conversations in their so-called /Cart00ney/ >> (http://www.uceprotect.net/en/index.php?m=8&s=0 >> <http://www.uceprotect.net/en/index.php?m=8&s=0>; >> http://www.uceprotect.org/cart00neys/index.html >> <http://www.uceprotect.org/cart00neys/index.html>). >> And the other type of threatening: >> http://www.uceprotect.org/ <http://www.uceprotect.org/> >> Does RIPE NCC have any position on this specific blacklist? >> >> Thank you! >
-- Christian Teuschel @christian_toysh RIPE NCC -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
Dear Jeroen, I am not sure I understand your question correctly but if you mean country statistics for listed IPs, that is not possible in the current model. Our data access to the blocklists is only ad-hoc and for a single resource per query, so not suitable for statistics. The main use case will probably be for network operators to quickly check the listing of their mail server's IP in various blocklists. This way one can troubleshoot mail delivery issues for MTAs using any of those blocklists. HTH, Christian On 18/05/2022 22:10, jeroen@hackersbescherming.nl wrote:
Good evening,
Will it be possible to show per country?
Kind regards,
Jeroen
-----Oorspronkelijk bericht----- Van: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Namens Christian Teuschel Verzonden: woensdag 18 mei 2022 21:46 Aan: anti-abuse-wg@ripe.net Onderwerp: Re: [anti-abuse-wg] Blocklists on RIPEstat (Was: UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget)
Dear colleagues,
In preparation for the upcoming AA-WG session, I want to provide an update on the status of the revamp of the blocklist feature on RIPEstat.
In 2021 and since the last status update we collected and reviewed a set of blocklists that we would see ideal to be included. We did this together with the help of our panel of domain experts.
Following the review, we performed a technical feasibility analysis, which filtered the blocklists related to supported resource type (IP and domain) and access method (DNS). For each of the remaining blocklists, we started to contact the respective operator and asked for permission to use the blocklist on RIPEstat.
The technical implementation of the required backend started with a delay but we are glad to report that we finished the development last month and released the feature a week ago.
Currently, the best way to use the new feature is via this RIPEstat widget:
https://stat.ripe.net/widget/dns-blocklists
Some details on the current solution: - The data is fetched in realtime unless cached (with a maximum cache time of 2 hours) - The supported resource type is a single IP address (IPv4 & Ipv6) - To prevent abuse a daily rate limit of 100 uncached queries per user is in place
What we want to do next: - Extend the number of blocklists - Add support for domain queries - Include the feature in the new UI (UI2020) - Add a similar API for whitelists
As we are still reaching out to some blocklist operators it is unclear how many blocklists will be included but we expect the number to be significantly higher than the old blocklist API call. Soon we will also review whether the new blocklist feature is mature enough to replace the old one.
All details on the project planning are available here: https://ripestat.featureupvote.com/suggestions/196464/project-blocklists-202...
Last but not least I want to thank the participants of the panel for their invaluable input and support!
I hope you find the new feature useful and I am looking forward to your feedback.
All the best, Christian
On 08/07/2021 10:21, Christian Teuschel wrote:
Dear colleagues,
I would like to share a short update regarding the Blocklist project for RIPEstat. As you might have noticed, we changed the name to “blocklist” earlier this year in March.
This month, we started evaluating new blocklists with the support of a panel of seven domain experts. Once the evaluation phase has been completed, we will share a fresh update.
You can follow more detailed design decisions on our public feature tracker: https://ripestat.featureupvote.com/suggestions/196464/project-blocklis ts-2021
To make sure you get all the latest news and updates on Twitter, follow #RIPEstat
Best regards, Christian
On 19/03/2021 14:24, Christian Teuschel wrote:
Dear colleagues,
Thank you for your suggestions and input. Here is an update on what we plan to do next:
We will continue looking at blocklist candidates and prepare an analysis/implementation plan. This will be done with a small group of experts who volunteered to help with the vetting process (contact me off-list if you would like to join this group).
This work will start in Q3. Once implemented, the changes will be available via the new RIPEstat UI. We might also add filters that allow you to decide which sources to use - with a smaller set of blocklists selected by default.
Another outcome is that we will also change the name from "blacklist" to "blocklist". This will have an impact on API endpoints, widgets and documenation. Work on this will start next week.
We will update this working group once our analysis is ready. In the meantime, if you are interested in RIPEstat, we also post developments on Twitter under #RIPEstat.
Best regards,
Christian
On 12/03/2021 09:51, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote: > Hi Christian, > > while it may be useful to have their data source, it only shows > the RIPE NCC favors one or two operators and I think that is > damaging to the whole idea of being impartial. > > You either include a good list of blacklist operators and their > data or none. Including only a couple will lead to the impression > that only those are important enough to be considered by the RIPE NCC. > > my 2 cents, > Elvis > > On 3/3/21 8:27 AM, Christian Teuschel wrote: >> Dear colleagues, >> >> RIPEstat is a neutral source of information and we aim to >> provide users with access to as many data sources as possible to provide insights. >> >> UCEProtect was added as a data source prior to 2010 and is still >> used by several network operators to filter traffic into their networks. >> Including it as a data source in RIPEstat allows users to see >> whether resources are included in their lists. >> >> RIPE NCC does not pay for, support or endorse their practices, >> although we understand that continuing to include UCEProtect as >> a data source could be misunderstood as such. We also do not use >> their lists to filter traffic on our services. >> >> Our goal remains to provide the best visibility and tools for >> network operators to diagnose their networks. We have also heard >> your feedback regarding including more RBLs. It is something >> that we have considered in the past, and we are open to revisiting this. >> >> RIPEstat is driven by the community. We would like to hear from >> you about whether including UCEProtect as a data source is useful. >> >> Regards, >> Christian >> >> On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote: >>> Hello, >>> >>> I noticed that RIPE NCC uses uceprotect-level1, >>> uceprotect-level2 and >>> uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. >>> >>> There have been controversial positions about this blacklist recently: >>> >>> 1) >>> https://success.trendmicro.com/solution/000236583-Emails-being- >>> rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-S >>> ecurity >>> >>> <https://success.trendmicro.com/solution/000236583-Emails-being >>> -rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email- >>> Security> >>> >>> 2) >>> https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.htm >>> l >>> <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.ht >>> ml> >>> >>> UCEPROTECT blacklists the whole range of IP addresses, >>> including the full IP range of some autonomous systems: >>> UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! >>> Your IP was NOT directly involved in abuse but has a bad neighborhood. >>> Other customers within this range did not care about their >>> security and got hacked, started spamming, or were even >>> attacking others, while your provider has possibly not even noticed that there is a serious problem. >>> We are sorry for you, but you have chosen a provider not acting >>> fast enough on abusers'/) >>> [http://www.uceprotect.net/en/rblcheck.php >>> <http://www.uceprotect.net/en/rblcheck.php>]. >>> It asks for a fee if some individual IP address wants to be >>> whitelisted (http://www.whitelisted.org/ >>> <http://www.whitelisted.org/>), >>> It abuses people who decide to challenge their blacklist by >>> publishing conversations in their so-called /Cart00ney/ >>> (http://www.uceprotect.net/en/index.php?m=8&s=0 >>> <http://www.uceprotect.net/en/index.php?m=8&s=0>; >>> http://www.uceprotect.org/cart00neys/index.html >>> <http://www.uceprotect.org/cart00neys/index.html>). >>> And the other type of threatening: >>> http://www.uceprotect.org/ <http://www.uceprotect.org/> >>> Does RIPE NCC have any position on this specific blacklist? >>> >>> Thank you! >> > >
-- Christian Teuschel @christian_toysh RIPE NCC
-- Christian Teuschel @christian_toysh RIPE NCC
Thx for the update, i was thinking about http(s) blocks but that's outside of your scope. -----Oorspronkelijk bericht----- Van: Christian Teuschel <cteusche@ripe.net> Verzonden: woensdag 18 mei 2022 23:45 Aan: jeroen@hackersbescherming.nl; anti-abuse-wg@ripe.net Onderwerp: Re: [anti-abuse-wg] Blocklists on RIPEstat (Was: UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget) Dear Jeroen, I am not sure I understand your question correctly but if you mean country statistics for listed IPs, that is not possible in the current model. Our data access to the blocklists is only ad-hoc and for a single resource per query, so not suitable for statistics. The main use case will probably be for network operators to quickly check the listing of their mail server's IP in various blocklists. This way one can troubleshoot mail delivery issues for MTAs using any of those blocklists. HTH, Christian On 18/05/2022 22:10, jeroen@hackersbescherming.nl wrote:
Good evening,
Will it be possible to show per country?
Kind regards,
Jeroen
-----Oorspronkelijk bericht----- Van: anti-abuse-wg <anti-abuse-wg-bounces@ripe.net> Namens Christian Teuschel Verzonden: woensdag 18 mei 2022 21:46 Aan: anti-abuse-wg@ripe.net Onderwerp: Re: [anti-abuse-wg] Blocklists on RIPEstat (Was: UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget)
Dear colleagues,
In preparation for the upcoming AA-WG session, I want to provide an update on the status of the revamp of the blocklist feature on RIPEstat.
In 2021 and since the last status update we collected and reviewed a set of blocklists that we would see ideal to be included. We did this together with the help of our panel of domain experts.
Following the review, we performed a technical feasibility analysis, which filtered the blocklists related to supported resource type (IP and domain) and access method (DNS). For each of the remaining blocklists, we started to contact the respective operator and asked for permission to use the blocklist on RIPEstat.
The technical implementation of the required backend started with a delay but we are glad to report that we finished the development last month and released the feature a week ago.
Currently, the best way to use the new feature is via this RIPEstat widget:
https://stat.ripe.net/widget/dns-blocklists
Some details on the current solution: - The data is fetched in realtime unless cached (with a maximum cache time of 2 hours) - The supported resource type is a single IP address (IPv4 & Ipv6) - To prevent abuse a daily rate limit of 100 uncached queries per user is in place
What we want to do next: - Extend the number of blocklists - Add support for domain queries - Include the feature in the new UI (UI2020) - Add a similar API for whitelists
As we are still reaching out to some blocklist operators it is unclear how many blocklists will be included but we expect the number to be significantly higher than the old blocklist API call. Soon we will also review whether the new blocklist feature is mature enough to replace the old one.
All details on the project planning are available here: https://ripestat.featureupvote.com/suggestions/196464/project-blocklis ts-2021
Last but not least I want to thank the participants of the panel for their invaluable input and support!
I hope you find the new feature useful and I am looking forward to your feedback.
All the best, Christian
On 08/07/2021 10:21, Christian Teuschel wrote:
Dear colleagues,
I would like to share a short update regarding the Blocklist project for RIPEstat. As you might have noticed, we changed the name to “blocklist” earlier this year in March.
This month, we started evaluating new blocklists with the support of a panel of seven domain experts. Once the evaluation phase has been completed, we will share a fresh update.
You can follow more detailed design decisions on our public feature tracker: https://ripestat.featureupvote.com/suggestions/196464/project-blockli s ts-2021
To make sure you get all the latest news and updates on Twitter, follow #RIPEstat
Best regards, Christian
On 19/03/2021 14:24, Christian Teuschel wrote:
Dear colleagues,
Thank you for your suggestions and input. Here is an update on what we plan to do next:
We will continue looking at blocklist candidates and prepare an analysis/implementation plan. This will be done with a small group of experts who volunteered to help with the vetting process (contact me off-list if you would like to join this group).
This work will start in Q3. Once implemented, the changes will be available via the new RIPEstat UI. We might also add filters that allow you to decide which sources to use - with a smaller set of blocklists selected by default.
Another outcome is that we will also change the name from "blacklist" to "blocklist". This will have an impact on API endpoints, widgets and documenation. Work on this will start next week.
We will update this working group once our analysis is ready. In the meantime, if you are interested in RIPEstat, we also post developments on Twitter under #RIPEstat.
Best regards,
Christian
On 12/03/2021 09:51, Christian Teuschel wrote:
Dear colleagues,
I can see a few suggestions for additional blocklists to include. It would be helpful if we could get any others by 19 March.
We will then get started on an analysis that we will share with the community a little later in the year.
Kind regards Christian
On 09/03/2021 10:37, Christian Teuschel wrote:
Dear colleagues,
Thinking about a course of action - it looks there is an agreement to have more RBLs on RIPEstat. It would be good to have a list of candidates that the community feels would be useful. Once we have this list, we can perform a feasibility analysis and present this to the community. We can then take it from there.
Let me know if this approach works for you.
Best regards, Christian
On 04/03/2021 17:16, Christian Teuschel wrote:
Hi Elvis and Suresh, dear colleagues,
Putting exact numbers on how many operators are using UCEProtect is difficult, but through feedback from users, network operators and members we understand that it is in use and that the provisioning of this RBL on RIPEstat has value.
If I am reading the feedback in this discussion correctly, the sentiment is leaning towards adding more RBLs instead of less and if that is the case we are going to look into how and when we can achieve this. Please let me know if that is aligned with your requirements/expectations.
Best regards, Christian
On 04/03/2021 09:54, Elvis Daniel Velea wrote: > Hi Christian, > > while it may be useful to have their data source, it only shows > the RIPE NCC favors one or two operators and I think that is > damaging to the whole idea of being impartial. > > You either include a good list of blacklist operators and their > data or none. Including only a couple will lead to the > impression that only those are important enough to be considered by the RIPE NCC. > > my 2 cents, > Elvis > > On 3/3/21 8:27 AM, Christian Teuschel wrote: >> Dear colleagues, >> >> RIPEstat is a neutral source of information and we aim to >> provide users with access to as many data sources as possible to provide insights. >> >> UCEProtect was added as a data source prior to 2010 and is >> still used by several network operators to filter traffic into their networks. >> Including it as a data source in RIPEstat allows users to see >> whether resources are included in their lists. >> >> RIPE NCC does not pay for, support or endorse their practices, >> although we understand that continuing to include UCEProtect as >> a data source could be misunderstood as such. We also do not >> use their lists to filter traffic on our services. >> >> Our goal remains to provide the best visibility and tools for >> network operators to diagnose their networks. We have also >> heard your feedback regarding including more RBLs. It is >> something that we have considered in the past, and we are open to revisiting this. >> >> RIPEstat is driven by the community. We would like to hear from >> you about whether including UCEProtect as a data source is useful. >> >> Regards, >> Christian >> >> On 02/03/2021 00:08, Kristijonas Lukas Bukauskas via anti-abuse-wg wrote: >>> Hello, >>> >>> I noticed that RIPE NCC uses uceprotect-level1, >>> uceprotect-level2 and >>> uceprotect-level3 in RIPEStat Anti Abuse Blacklist Entries widget. >>> >>> There have been controversial positions about this blacklist recently: >>> >>> 1) >>> https://success.trendmicro.com/solution/000236583-Emails-being >>> - >>> rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email- >>> S >>> ecurity >>> >>> <https://success.trendmicro.com/solution/000236583-Emails-bein >>> g >>> -rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email >>> - >>> Security> >>> >>> 2) >>> https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.ht >>> m >>> l >>> <https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.h >>> t >>> ml> >>> >>> UCEPROTECT blacklists the whole range of IP addresses, >>> including the full IP range of some autonomous systems: >>> UCEPROTECT states, '/Who is responsible for this listing? YOU ARE NOT! >>> Your IP was NOT directly involved in abuse but has a bad neighborhood. >>> Other customers within this range did not care about their >>> security and got hacked, started spamming, or were even >>> attacking others, while your provider has possibly not even noticed that there is a serious problem. >>> We are sorry for you, but you have chosen a provider not >>> acting fast enough on abusers'/) >>> [http://www.uceprotect.net/en/rblcheck.php >>> <http://www.uceprotect.net/en/rblcheck.php>]. >>> It asks for a fee if some individual IP address wants to >>> be whitelisted (http://www.whitelisted.org/ >>> <http://www.whitelisted.org/>), >>> It abuses people who decide to challenge their blacklist >>> by publishing conversations in their so-called /Cart00ney/ >>> (http://www.uceprotect.net/en/index.php?m=8&s=0 >>> <http://www.uceprotect.net/en/index.php?m=8&s=0>; >>> http://www.uceprotect.org/cart00neys/index.html >>> <http://www.uceprotect.org/cart00neys/index.html>). >>> And the other type of threatening: >>> http://www.uceprotect.org/ <http://www.uceprotect.org/> >>> Does RIPE NCC have any position on this specific blacklist? >>> >>> Thank you! >> > >
-- Christian Teuschel @christian_toysh RIPE NCC
-- Christian Teuschel @christian_toysh RIPE NCC
participants (16)
-
Alessandro Vesely -
Andreas Worbs -
Brian Nisbet -
Christian Teuschel -
Cynthia Revström -
Elvis Daniel Velea -
Esa Laitinen -
Gert Doering -
jeroen＠hackersbescherming.nl -
Kristijonas Lukas Bukauskas -
lukn -
Nuno Vieira -
Randy Bush -
Suresh Ramasubramanian -
Vittorio Bertola -
Ángel González Berdasco