Project Blocklists 2021
Triggered by a discussion on the Anti-Abuse WG mailing list [1], the number and selection of blocklists used on RIPEstat should be improved. A panel of domain experts will join us to help with the vetting. This project has started in July 2021 and we defined the following milestones:
M1: Collection of blocklist candidates - July 2021
M2: Review and selection of blocklist candidates - July/August 2021
M3: Feasibility analysis by RIPEstat team - September 2021
M4: Start of implementation in RIPEstat - Q1 2022 (previously Q4 2021)
We expect the addition of new blocklists to happen in Q2 2022.
[1] https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2021-March/006146.html
Comments: 6
-
08 Jul, '21
Roberto Navarro ReyesA few years ago, in the forum of Spanish abuse teams, we did a similar job. We defined some initial criteria and evaluated a the most popular block lists at the moment. These were the results:
https://www.abuses.es/docus/abuses/urln.html -
08 Jul, '21
Christian Teuschel AdminThanks Roberto for sharing, that is valuable input!
-
08 Jul, '21
Alexander Talos-Zens (ACOnet-CERT)Roberto,
your list of criteria is excellent work!
If I may add two micro-cents of mine:
* Listings MUST be dropped automatically, that is without any intervention of whomever, some time after the last spam event.
* I love your point, that evidence has to be provided. Admittedly, that's only a detail regarding the wording, but an e-mail isn't always available. As an example, if some ip address tries to send mail to spam trap addresses, it's reasonable to blocklist it even if no actual mail has ever been transmitted (DATA command rejected). In that case, obviously, only some kind of MTA logs are available.
* As good spam traps are a precious resource, the BL infrastructure must be allowed to protect them in some way by obviously not disclosing these recipient addresses, not even the exact time stamps. -
13 Jul, '21
francisco monserratThe abuse.es criteria were mainly for SPAM lists, the blocklists are now more generic. It should also be included in the criteria that the entry, stay and exit times of these lists are well defined.
-
13 Jul, '21
Christian Teuschel AdminThanks Francisco, I'll add this criteria as input for M2.
-
17 May, '22
Christian Teuschel AdminAfter the implementation of the new backend finished, the new blocklist feature is now available in RIPEstat.
In UI2013 (aka. old UI) please visit https://stat.ripe.net/widget/dns-blocklists and in UI2020 (aka. new UI) this will be included soon.
Here are some details that are good to know when using this feature:
- Data is fetched in realtime unless it is cached, which is for a maximum of 2 hours
- In order to prevent abuse, there is a daily query limit for uncached lookups per user
Before we add a new blocklist, we ask the operator for permission. Since this process is not in our control, it is hard to say what the definite number of blocklists will be but we expect it to increase significantly in the coming 4 weeks. At one point, we will assess whether the old blocklist feature can be replaced by the new one.