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
>>>
>>> 
>>>
>>> 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%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=%2BTvsNRt4eyvmEkZT4rq2x09%2FJ%2FsIjRpMx%2FgpCRV0x6o%3Dreserved=0
>>> 

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!