Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Christian Teuschel]

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-Security
>>
>> 
>>
>> 2) 

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Elvis Daniel Velea]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Christian Teuschel]

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-Security
>
> 
>
> 2) 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
> ].
>   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/
> 

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Alessandro Vesely]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Suresh Ramasubramanian]

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  on behalf of Christian 
Teuschel 
Date: Tuesday, 9 March 2021 at 3:07 PM
To: 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-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security
>>>>
>>>> <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 abou

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Christian Teuschel]

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

 

 2) 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
 ].
   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=0
 ;
 http://www.uceprotect.org/cart00neys/index.html
 ).
   And the other type of threatening: http://www.uceprotect.org/
 
   Does RIPE NCC have any position on this specific blacklist?

 Thank you!
>>>
>>
>>
> 

-- 
Christian Teuschel
RIPE NCC | @christian_toysh

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Cynthia Revström via anti-abuse-wg]

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  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-Security
> >>>
> >>> <
> 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
> >>> 
> >>>
> >>> 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
> >>> ].
> >>>   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 

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Suresh Ramasubramanian]

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

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  on behalf of Randy Bush 

Sent: Friday, March 5, 2021 1:21:18 AM
To: "Ángel González Berdasco" 
Cc: 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

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header mangling

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Randy Bush]

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

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header mangling

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Alessandro Vesely]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Ángel González Berdasco]

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
d...@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.

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Randy Bush]

> 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

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header mangling

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Kristijonas Lukas Bukauskas via anti-abuse-wg]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Brian Nisbet]

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.nis...@heanet.ie www.heanet.ie

Registered in Ireland, No. 275301. CRA No. 20036270


From: anti-abuse-wg  on behalf of Christian 
Teuschel 
Sent: Thursday 4 March 2021 16:16
To: 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.trendmicro.com%2Fsolution%2F000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Securitydata=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184253161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yFgzAJGezG7oQtmEAhB0s8Mp9Cq5EgGAJYxlh88v2Ic%3Dreserved=0
>>>
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsuccess.trendmicro.com%2Fsolution%2F000236583-Emails-being-rejected-by-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Securitydata=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184253161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=yFgzAJGezG7oQtmEAhB0s8Mp9Cq5EgGAJYxlh88v2Ic%3Dreserved=0>
>>>
>>> 2) 
>>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.sucuri.net%2F2021%2F02%2Fuceprotect-when-rbls-go-bad.htmldata=04%7C01%7C%7Cd6eabb75245d44d761c208d8df28ed57%7Ccd9e8269dfb648e082538b7baf8d3391%7C0%7C0%7C637504714184263120%7CUnknown%7CTWF

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Christian Teuschel]

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-Security
>>>
>>> 
>>>
>>> 2) 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
>>> ].
>>>   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=0
>>> ;
>>> http://www.uceprotect.org/cart00neys/index.html
>>> ).
>>>   And the other type of threatening: http://www.uceprotect.org/
>>> 
>>>   Does RIPE NCC have any position on this specific blacklist?
>>>
>>> Thank you!
>>
> 
> 

-- 
Christian Teuschel
RIPE NCC | @christian_toysh

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Elvis Daniel Velea]

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

2) 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
].
  
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=0
;
http://www.uceprotect.org/cart00neys/index.html
).
  
And the other type of threatening: http://www.uceprotect.org/


  
Does RIPE NCC have any position on this specific blacklist?


Thank you!

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Kristijonas Lukas Bukauskas via anti-abuse-wg]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Suresh Ramasubramanian]

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 
Sent: Thursday, March 4, 2021 5:47:38 AM
To: Suresh Ramasubramanian 
Cc: christian.teusc...@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-uceprotect].

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Kristijonas Lukas Bukauskas via anti-abuse-wg]

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-uceprotect].


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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Suresh Ramasubramanian]

Do you see email providers of significant size using it?

--srs

From: anti-abuse-wg  on behalf of Christian 
Teuschel 
Sent: Wednesday, March 3, 2021 9:57:50 PM
To: 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-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security
> <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=0
> <http://www.uceprotect.net/en/index.php?m=8=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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Randy Bush]

> 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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Christian Teuschel]

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-Security
> 
> 2) 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
> ].
>  
> 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=0
> ;
> http://www.uceprotect.org/cart00neys/index.html
> ).
>  
> And the other type of threatening: http://www.uceprotect.org/
> 
>  
> Does RIPE NCC have any position on this specific blacklist?
> 
> Thank you!

-- 
Christian Teuschel
RIPE NCC | @christian_toysh

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Andreas Worbs via anti-abuse-wg]

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: supp...@artfiles.de | Web: http://www.artfiles.de
Geschäftsführer: Harald Oltmanns | Tim Evers
Eingetragen im Handelsregister Hamburg - HRB 81478




OpenPGP_signature
Description: OpenPGP digital signature

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Suresh Ramasubramanian]

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  on behalf of Nuno Vieira 
via anti-abuse-wg 
Sent: Wednesday, March 3, 2021 5:01:51 PM
To: Gert Doering ; Esa Laitinen 
Cc: Nuno Vieira ; 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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Gert Doering]

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 14Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


signature.asc
Description: PGP signature

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Esa Laitinen]

   

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Kristijonas Lukas Bukauskas via anti-abuse-wg]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[lukn]

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.

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Alessandro Vesely]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Kristijonas Lukas Bukauskas via anti-abuse-wg]

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

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Esa Laitinen]

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
>  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
>> ].
>>
>> It asks for a fee if some individual IP address wants to be
>> whitelisted (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=0
>> ;
>> 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
> 
>
> 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  or
https://signal.org/install 
Skype: reunaesa
Mobile: +4178 838 57 77  

Re: [anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Vittorio Bertola via anti-abuse-wg]

> Il 02/03/2021 00:08 Kristijonas Lukas Bukauskas via anti-abuse-wg 
>  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-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security
>  
> 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:
> 
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=0 
> http://www.uceprotect.net/en/index.php?m=8=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.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

[anti-abuse-wg] UCEPROTECT DNSBL possibly abusive practice and RIPEStat Blacklist entries widget

[Kristijonas Lukas Bukauskas via anti-abuse-wg]

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-Security 
[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=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-RBL-UCEPROTECL-in-Hosted-Email-Security-and-Email-Security

[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=8s=0
[5] http://www.uceprotect.org/cart00neys/index.html