It's time to denounce an organization - SPFBL.net - which, although it claims to fight spam, actually seems to adopt practices contrary to this objective. Instead of fulfilling its role, this provider seems to be taking advantage of its position to engage in absolutely scandalous and unacceptable practices.
Not all RBLs are managed ethically. Today's example is SPFBL.net, a Brazilian RBL born in 2015 (source MXToolbox)which is increasingly coming under the spotlight for its highly questionable practices.
Info: What is RBL?
An RBL (Real-time Blackhole List) is a list of IP addresses suspected of sending spam or other malicious content. Mail servers use these lists to block or filter potentially dangerous e-mails.
In this article, we'll take a look at this situation and explain why this company's practices are not only dubious, but potentially harmful to the entire Internet ecosystem if administrators decide to use this RBL. We'll also look at how to combat these practices.
Users' and service providers' views on the SPFBL blacklist
Let's start by showing the general opinion emerging from this blacklist. A quick search on the search engines shows that the forums (in English) are full of people crying foul about SPFBL.net.
Having contacted their support (I'll tell you more about it later), I'd tend to agree with them... Judge for yourself.
- Dear admins, remove this from your filters | the scam business that is spfbl.com
- Denouncing fake DNSBL BlackList Operator: spfbl.net
"I contacted the operator of this spfbl.net and he threatened me with getting my IP's blocked throughout the internet, how can something like this be allowed to happen."
OPALIT
- Email address likely blacklisted... very confused about what to do next!
- Matrix blacklist matrix.spfbl.net
- hello I have a question about dnsbl.spfbl.net
"We got flagged because we don't have a contact email in our whois record (we have privacy turned on for it). Given that google.com also has that, I conclude that these guys are just a scam who want to be paid to have your domain unrestricted."
someexgoogler
The LRob case: another unjustified blacklisting
The infrastructure server LRob is a perfect example of a system that has been carefully configured and managed for many years. As system administrator of this server, I can say with certainty that no spam has ever been sent from this machine. What's more, all the essential settings are correctly in place: Hostname, rDNS, MX, SPF, DKIMand DMARC.
Despite these exemplary compliance measures, the server's IPv6 ended up on the blacklist of SPFBL.net.
Check result of IP
2a01:4f8:171:28e8:0:0:0:2This is the rDNS found:
- <ds.lrob.net> non-compliance domain.
A domain is considered non-compliant when the WHOIS search result for that domain does not contain the email address of the domain owner. Update the registration data and remove privacy protection for this domain in WHOIS and wait one hour for the cached result of this WHOIS query to expire.
This IP was flagged due to misconfiguration of the e-mail service or the suspicion that there is no MTA at it.
For the delist key can be sent, select the e-mail address responsible for this IP:
- add a PayPal user's email for 2.00 USD.
The rDNS must be registered under your own domain. We do not accept rDNS with third-party domains.
Summary of exchanges with SPFBL.net support
Naturally, I contacted the RBL to check whether I'd understood their policy correctly and whether it was possible to discuss things with them in a spirit of good understanding. Result: yes, I had understood correctly, and no, I don't think it's possible to discuss matters with them as they stand.
Here is a ChatGPT summary of the e-mail exchanges:
- Initial request (Robin) Robin, system administrator, contacted SPFBL to ask for help with the removal of his IPv6 address from their DNS blacklist. He wanted clarification on the reasons for the listing and advice on how to correct any misconfigurations, suspecting a link to WHOIS privacy protection.
- Answer (Leandro) In response, SPFBL's Leandro asked Robin to temporarily remove the WHOIS privacy protection so that the IP could be removed via their online removal tool.
- Concerns (Robin) In a statement, Mr. Robin expressed concern about the requirement to remove WHOIS privacy protection, citing RGPD regulations. He questioned the need to expose personal data, pointing out that no reports of abuse had been issued on his domain.
- Explanation (Leandro) Leandro explained that their system used domain owner data to predict spam and associate domains under the same owner. No further justification for this policy was given.
- Objection (Robin) Robin disputed the usefulness of WHOIS information for assessing IP behavior, calling SPFBL's policy counterproductive. He reiterated that his IP posed no risk and requested its removal from the blacklist.
- Options (Leandro) Leandro offered two options for removal: temporarily remove WHOIS protection or pay a fee.
- Firm response (Robin) Robin firmly rejected both options, describing the practice as dishonest and tantamount to a scam. He stressed that his IP was compliant and threatened to take legal action if the problem was not resolved.
- Final answer (Leandro) Leandro rejected Robin's legal threats, stating that SPFBL respects American law and inviting him to pursue any legal action he deems appropriate.
- Last warning (Robin) Robin recalled that the Internet is a global system, and that no location justifies harming legitimate businesses through dubious ethical practices. He confirmed his intention to take the necessary measures, specifying that his contacts would identify the relevant local authorities if necessary.
These exchanges took place between September 8 and 9, 2024.
In addition, I have a log showing that they tried to send an e-mail to a non-existent address for testing purposes, so that they could check for themselves that the server was correctly configured and rejected the e-mail:
Oct 9 14:55:13 ds postfix/smtpd[899530]: connect from matrix.spfbl.net[54.233.253.229]
Oct 9 14:55:14 ds postfix/smtpd[899530]: NOQUEUE: reject: RCPT from matrix.spfbl.net[54.233.253.229]: 550 5.1.1 : Recipient address rejected: User unknown in virtual mailbox table; from= to= proto=ESMTP helo=
Oct 9 14:55:14 ds postfix/smtpd[899530]: disconnect from matrix.spfbl.net[54.233.253.229] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Oct 9 14:55:14 ds psa-pc-remote[2023328]: Message aborted.The SPFBL.net case: an abusive practice
The case of SPFBL.net highlights alarming practices that run counter to the data protection and ethical standards respected by many other RBLs.
In particular, this RBL blacklists IPs according to abusive criteria, and then imposes highly problematic conditions for untracking IP addresses.
Let's unpack the "rules for free de-listing" according to the policy posted on their site on September 9, 2024, which also informs us about possible reasons for the initial blacklisting:
| Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS for your convenience; | ❌ This criterion is certainly standard, but this check should be carried out by the server receiving the e-mail, not by an RBL, which here adds no value. |
| The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted, and its TLD cannot be free and must have a public and accessible WHOIS without privacy obfuscation; | ❌ The administrator can very well infomanage the mails of a third party, as in my case where the MTA is "lrob.net" and the administration is done via "lrob.fr". This should not justify blocking. ❌ Blocking generic rDNS can be good practice, but that's up to the receiving server, not an RBL. ❌ Requiring a public WHOIS contravenes the RGPD in Europe. The right to send emails should not depend on the visibility of personal information in the WHOIS. |
| The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding; | ❌ rDNS are often technical subdomains, like "ds.lrob.net". Having an e-mail address like "postmaster (at) ds.lrob.net" makes no sense. The postmaster can be contacted via other, more appropriate channels, such as a contact form or a main address. |
| If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and | ❌ While the server does need to listen on port 25 to ensure proper SMTP operation, again it's up to the receiving server to check this, not a blacklist to control it. |
| Reputation of IP should be below 25% of negative points per total send volume | ✅ This criterion is consistent with the very principle of an RBL, which assesses the reputation of an IP address based on its actual behavior. |
Let's also take a look at the paid delisting conditions:
| Only static IPs with configured mail server reverseeven if FCrDNS is invalid; | ❌ Under the pretext of paying, one would allow an invalid rDNS, which is contrary to e-mail configuration standards. This is a circumvention of good practice, which could allow misconfigured mails to be sent. |
| A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse; | ❌ Forcing PayPal to assign an IP address to an account is an unjustified restriction. It limits users' options and has no legitimate reason in a technical framework. |
| The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and | ❌ Publicly exposing the email address associated with the PayPal account is an invasion of privacy and can lead to risks of harassment or abuse. This clearly goes against the principles of confidentiality. |
| Reputation of IP should be below 25% of negative points per total send volume. | ✅ This criterion is acceptable and aligns with the principle of assessing the reputation of an IP address on the basis of its actual behavior, as expected of an RBL. |
In short, this blacklist seems to me to be an attempt to reinvent the wheel with blocking rules that make absolutely no sense from a technical point of view.
As for delisting's conditions, even in its paid version, they remain abusive. From my point of view, this should have dissuaded any sysadmin from using this RBL by now.
Their aim, of course, seems to be to make a profit on the backs of users while recovering personal data.
Summary of problems with SPFBL.net
Several major issues call into question the wisdom of their practices and their negative impact on legitimate businesses.
Here are the main points to remember:
- WHOIS private data exposure
SPFBL.net requires administrators to remove their WHOIS protection in order to be removed from their blacklist. This means that personal and sensitive information, such as the domain owner's email address, must be publicly accessible for the IP address to no longer be blacklisted. In Europe, this request is in total contradiction with the RGPD (General Data Protection Regulation), which guarantees the protection of users' private data. WHOIS information has been private by default for many years. This requirement would expose system administrators and companies to the risk of abuse or targeted spam, which is contrary to good security and privacy practice. - Payment for delisting
In addition to removing WHOIS protection, SPFBL.net also offers an alternative : pay $2 to remove an IP address from the blacklist. This practice is perceived by many as a form of blackmail. Demanding payment to restore the legitimacy of an IP address, when there is no evidence of suspicious or malicious activity, calls into question the transparency of their operations. This approach is likely to drive many legitimate companies to pay simply to avoid the inconvenience of blacklisting. - An inefficient detection model
Grouping domains according to WHOIS information ignores the realities of the modern web, where many legitimate businesses use shared infrastructures, hosted by providers such as Google or OVH. As a result, IP addresses could be unfairly blacklisted simply because they share a domain owner with other users, regardless of their actual behavior.
A very serious potential impact
The consequences of these practices are numerous and serious for the Internet ecosystem:
- Impact on companies : When an IP address is wrongly blocked, it can affect a company's ability to communicate by e-mail with its customers, partners or service providers. Detection errors or abusive demands can disrupt the smooth running of a business.
- Blackmail and extortion : Asking for money to remove an IP address from a blacklist without proof of malicious activity is tantamount to extortion. This approach seriously undermines trust between ISPs and their customers.
- Breach of confidentiality : By requesting the removal of WHOIS protection, SPFBL.net is violating the fundamental principles of personal data protection, particularly in Europe, where the RGPD (General Data Protection Regulation) protects users' private information. By exposing this data, SPFBL.net exposes system administrators and companies to the risk of misuse.
What can I do as an Internet service provider?
1. Stop using this RBL immediately
We must all urge our relations at the major service providers NOT to use this RBL.
It is absolutely essential that Internet service providers stop using SPFBL.net and other RBLs that fail to meet ethical standards. Another such RBL is UCEPROTECT, which blacklists entire IP blocks and then demands money from each of the IP users to unblock them.
Using a dubious RBL can have harmful consequences for end-users, businesses and the entire digital ecosystem.
There are many respectable alternatives that focus on detecting malicious activity based on actual behavior, not private information or arbitrary domain groupings. System administrators must remain vigilant and choose solutions that respect privacy and follow fair and transparent practices.
2. Don't give in
If, like me, you are a victim of this RBL and feel that these practices are abusive, please don't give in to the outrageous demands of this RBL. On the contrary, fight alongside me.
3. Report these practices to the appropriate authorities
Use your connections to get the word out to the French CSIRT (Computer Security Incident Response Team), at the_ANSSI but also to the CNIL for non-compliance with RGPD. If you have contacts at European level, pass on the information. If you're outside France or Europe, contact the organizations you can reach, and don't hesitate to use this article to explain the problem.
If you don't have a contact but understand what's at stake, pass on the info to people in the hosting and web sysadmin fields.
Conclusion
The case SPFBL.net is a blatant example of the dangers of the dubious practices of certain RBLs.
We understand that those who claim to fight the "bad guys" are not always "good guys" themselves.
To protect the integrity of the Internet and the respect of users, it is imperative that Internet service providers stop using this RBL and favor more respectful solutions available.
Fellow sysadmins: don't give in to the grotesque requirements of this RBL.
LRob will not give in, and this article marks the beginning of a fight which will only stop once the community has won its case. It can be done, by contacting the right people. And you can help.
If you are confronted with the abusive practices of SPFBL.net, join us in denouncing these actions and protecting the integrity of the Internet ecosystem. Contact the relevant authorities, share this information with your professional networks, and refuse to give in to these unfair practices.
Leave a Reply