Blacklists (RBL): SPFBL.net's outrageous 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.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. Options (Leandro) Leandro offered two options for removal: temporarily remove WHOIS protection or pay a fee.
7. 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.
8. 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.
9. 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:

1. 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.
2. 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.
3. 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:

1. 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.
2. 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.
3. 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.

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.