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

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 will also look at how to combat these practices.

The opinion of users and service providers faced with 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 scandal and scam about SPFBL.net.

Having contacted their support team (I'll tell you more about it later), I 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: a manifestly unjustified blacklist

The infrastructure server LRob is a perfect example of a system that has been carefully configured and managed for several years. As the 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, DKIM, and DMARC.

Despite these exemplary compliance measures, the server's IPv6 ended up on the black list of SPFBL.net.

Summary of exchanges with SPFBL.net support

Naturally, I contacted the RBL to check whether I had understood their policy correctly and whether it was possible to discuss things with them on an amicable basis. The result: yes, I had understood correctly, and no, I don't think it's possible to talk to them on good terms as things stand.

Here is a ChatGPT summary of the e-mail exchanges:

1. Initial application (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, Leandro from SPFBL asked Robin to temporarily remove the WHOIS privacy protection so that the IP could be removed via their online removal tool.
3. Concerns (Robin) WHOIS: 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 the domain owner's data to predict spam and associate domains under the same owner. They did not provide any further justification for this policy.
5. Objection (Robin) Robin disputed the usefulness of WHOIS information for assessing the behaviour of an IP, describing SPFBL's policy as counter-productive. He reiterated that his IP posed no risk and requested that it be removed 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 pointed out 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 8 and 9 September 2024.

I also have a log showing that they tried to send an email to a non-existent address for testing purposes, so they could check for themselves that the server was correctly configured, and it rejected the email:

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 break down the «rules for free de-listing» according to the policy posted on their site on 9 September 2024, which also tells us about the possible reasons for the initial blacklisting:

Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS validation;	❌ 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;	❌ rDNSs are often technical subdomains, such as «ds.lrob.net». Having an email 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 SMTP works properly, 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 behaviour.

Let's also take a look at the paying conditions:

Only static IPs with configured mail server reverse, even if FCrDNS is invalid;	❌ Under the pretext of paying, an invalid rDNS would be allowed, which is contrary to email configuration standards. This is a circumvention of good practice, which could allow incorrectly configured emails 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 behaviour, 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 the delisting conditions, even in the paid version, they are still abusive. In my opinion, this should have dissuaded any sysadmin from using this RBL by now.

The aim seems to be to make a profit on the backs of users while recovering personal data.

Summary of problems with SPFBL.net

A number of major problems call into question the wisdom of their practices and their negative impact on legitimate businesses.

Here are the main points to remember:

1. Exposure of WHOIS private data
   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. The information contained in the WHOIS has been private by default for several years. This requirement would expose system administrators and companies to risks of abuse or targeted spam, which is contrary to good practice in terms of security and confidentiality.
2. Payment for delisting
   In addition to removing WHOIS protection, SPFBL.net also offers an alternative : pay 2 dollars 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 ineffective 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 behaviour.

A very serious potential impact

The consequences of these practices are numerous and serious for the Internet ecosystem:

1. Impact on businesses When an IP address is wrongly blocked, this 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 The Internet Service Provider (ISP): 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 that WHOIS protection be removed, 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 risks of abuse.

Conclusion

The case SPFBL.net is a flagrant example of the dangers of the dubious practices of certain RBLs.

It's easy to see that those who claim to fight the «bad guys» are not always the «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 favour the 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.