Blacklists (RBL) : Pratiques scandaleuses de SPFBL.net

Il est temps de dénoncer une organisation – SPFBL.net – qui, bien qu’elle prétende lutter contre le spam, semble en réalité adopter des pratiques contraires à cet objectif. Au lieu de remplir son rôle, ce prestataire semble profiter de sa position pour mener des pratiques absolument scandaleuses et inacceptables.

Toutes les RBL ne sont pas gérées de manière éthique. L’exemple du jour est celui de SPFBL.net, une RBL brésilienne née en 2015 (source MXToolbox), qui est de plus en plus mise en lumière pour ses pratiques largement contestables.

Info : Qu’est-ce qu’une RBL ?

Une RBL (Real-time Blackhole List) est une liste d’adresses IP suspectées d’envoyer du spam ou d’autres contenus malveillants. Les serveurs de messagerie s’appuient sur ces listes pour bloquer ou filtrer les e-mails potentiellement dangereux.

Dans cet article, nous allons décortiquer cette situation et expliquer pourquoi les pratiques de cette entreprise sont non seulement douteuses, mais potentiellement nuisibles à l’ensemble de l’écosystème internet si des administrateurs décident d’utiliser cette RBL. Nous verrons également comment combattre ces pratiques.

L’avis des utilisateurs et fournisseurs de services confrontés à la blacklist SPFBL

Commençons par montrer l’avis général ressortant de cette blacklist. Une rapide recherche sur les moteurs de recherche montre que les forums (en anglais) sont remplis de personnes criant au scandale et à l’arnaque au sujet de SPFBL.net.

Pour avoir contacté leur support (je vous détaille cela ensuite), je serais plutôt de leur avis… Jugez par vous-même.

« 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

« 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

Le cas LRob : une blacklist manifestement injustifiée

Le serveur d’infrastructure LRob est un exemple parfait d’un système configuré et géré avec soin depuis plusieurs années. En tant qu’administrateur système de ce serveur, je peux affirmer avec certitude qu’aucun spam n’a jamais été envoyé depuis cette machine. De plus, tous les paramètres essentiels sont correctement mis en place : Hostname, rDNS, MX, SPF, DKIM, et DMARC.

Malgré ces mesures exemplaires de conformité, l’IPv6 du serveur s’est retrouvée sur la liste noire de SPFBL.net.

Check result of IP
2a01:4f8:171:28e8:0:0:0:2

This is the rDNS found:

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.

Résumé des échanges avec le support de SPFBL.net

J’ai bien-sûr contacté la RBL pour vérifier si j’avais bien compris leur politique et s’il était possible de discuter en bonne intelligence. Résultat : oui, j’avais bien compris, et non, il ne me semble pas possible de discuter en bonne intelligence avec eux en l’état.

Voici un résumé ChatGPT des échanges par mail :

  1. Demande initiale (Robin) : Robin, administrateur système, a contacté SPFBL pour demander de l’aide concernant la suppression de son adresse IPv6 de leur liste noire DNS. Il souhaitait obtenir des précisions sur les raisons de l’inscription et des conseils pour corriger d’éventuelles mauvaises configurations, suspectant un lien avec la protection de la confidentialité WHOIS.
  2. Réponse (Leandro) : Leandro, de SPFBL, a répondu en demandant à Robin de retirer temporairement la protection de la confidentialité WHOIS afin de pouvoir retirer l’IP via leur outil de suppression en ligne.
  3. Préoccupations (Robin) : Robin a exprimé des inquiétudes quant à l’exigence de retirer la protection de la confidentialité WHOIS, invoquant les réglementations du RGPD. Il a remis en question la nécessité d’exposer des données personnelles, soulignant qu’aucun rapport d’abus n’avait été émis sur son domaine.
  4. Explication (Leandro) : Leandro a expliqué que leur système utilisait les données du propriétaire du domaine pour prédire le spam et associer des domaines sous le même titulaire. Il n’a pas fourni d’autres justifications pour cette politique.
  5. Objection (Robin) : Robin a contesté l’utilité des informations WHOIS pour évaluer le comportement d’une IP, qualifiant la politique de SPFBL de contre-productive. Il a réitéré que son IP ne présentait aucun risque et a demandé sa suppression de la liste noire.
  6. Options (Leandro) : Leandro a proposé deux options pour la suppression : retirer temporairement la protection WHOIS ou payer des frais.
  7. Réponse ferme (Robin) : Robin a fermement rejeté les deux options, qualifiant cette pratique de malhonnête et assimilable à une escroquerie. Il a souligné que son IP était conforme et a menacé de prendre des mesures légales si le problème n’était pas résolu.
  8. Réponse finale (Leandro) : Leandro a rejeté les menaces légales de Robin, affirmant que SPFBL respecte les lois américaines et l’invitant à poursuivre toute action légale qu’il jugerait appropriée.
  9. Dernier avertissement (Robin) : Robin a rappelé que l’internet est un système global et qu’aucune localisation ne justifie de nuire à des entreprises légitimes à travers des pratiques éthiques douteuses. Il a confirmé son intention de prendre les mesures nécessaires, en précisant que ses contacts identifieraient les autorités locales compétentes si nécessaire.

Ces échanges ont eu lieu entre le 8 et le 9 septembre 2024.

Par ailleurs, je dispose d’un log qui montre qu’ils ont tenté d’envoyer un mail à une adresse inexistante pour test, pouvant vérifier par eux-même la bonne configuration du serveur qui a donc rejeté ce 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 <inexistent-feature-check-192715907d9@lrob.net>: Recipient address rejected: User unknown in virtual mailbox table; from=<admin@spfbl.net> to=<inexistent-feature-check-192715907d9@lrob.net> proto=ESMTP helo=<matrix.spfbl.net>
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.

Le cas SPFBL.net : une pratique abusive

Le cas de SPFBL.net met en lumière des pratiques alarmantes qui vont à l’encontre de la protection des données et des standards éthiques que de nombreuses autres RBL respectent.

En particulier, cette RBL blacklist des IP selon des critères abusifs, puis impose des conditions très problématiques pour le délistage d’adresses IP.

Décortiquons les « règles pour un délistage gratuit » selon la politique affichée sur leur site le 9 Septembre 2024, qui nous informe également sur les raisons possibles au blacklistage initial :

Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS validation;❌ Ce critère est certes standard, mais cette vérification devrait être effectuée par le serveur destinataire de l’e-mail, pas par une RBL, qui ici n’apporte aucune valeur ajoutée.
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;❌ L’administrateur peut très bien infogérer les mails d’un tiers, comme dans mon cas où le MTA est « lrob.net » et l’administration est faite via « lrob.fr ». Cela ne devrait pas justifier un blocage.
❌ Bloquer les rDNS génériques peut être une bonne pratique, mais cela relève du serveur destinataire, pas d’une RBL.
❌ Exiger un WHOIS public contrevient au RGPD en Europe. Le droit d’envoyer des mails ne devrait pas dépendre de la visibilité des informations personnelles dans le WHOIS.
The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;❌ Les rDNS sont souvent des sous-domaines techniques, comme « ds.lrob.net ». Avoir une adresse e-mail du type « postmaster (at) ds.lrob.net » n’a aucun sens. Le postmaster peut être contacté via d’autres canaux plus appropriés, comme un formulaire de contact ou une adresse principale.
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❌ Bien que le serveur doive effectivement écouter sur le port 25 pour assurer le bon fonctionnement du SMTP, c’est encore une fois au serveur destinataire de vérifier cela, pas à une blacklist de le contrôler.
Reputation of IP should be below 25% of negative points per total send volume✅ Ce critère est cohérent avec le principe même d’une RBL, qui évalue la réputation d’une adresse IP en fonction de son comportement réel.

Voyons aussi les conditions payantes :

Only static IPs with configured mail server reverse, even if FCrDNS is invalid;❌ Sous prétexte de payer, on permettrait d’avoir un rDNS invalide, ce qui est contraire aux normes de configuration des e-mails. C’est un contournement des bonnes pratiques, qui pourrait permettre l’envoi de courriers mal configurés.
A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;❌ Forcer l’utilisation de PayPal pour attribuer une adresse IP à un compte est une restriction injustifiée. Cela limite les options des utilisateurs et n’a aucune raison légitime dans un cadre technique.
The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and❌ Exposer publiquement l’adresse email associée au compte PayPal est une atteinte à la vie privée et peut entraîner des risques de harcèlement ou d’abus. Cela va clairement à l’encontre des principes de confidentialité.
Reputation of IP should be below 25% of negative points per total send volume.✅ Ce critère est acceptable et s’aligne avec le principe d’évaluation de la réputation d’une adresse IP sur la base de son comportement effectif, comme attendu d’une RBL.

En somme, cette blacklist me semble tenter de réinventer la roue avec des règles de blocage qui ne font strictement aucun sens d’un point de vue technique.

Quand aux conditions de délisting, même dans sa version payante, les conditions restent abusives. De mon point de vue, cela devrait déjà, à ce stade, avoir dissuadé tout sysadmin d’utiliser cette RBL.

Le but semble bien-sûr être de faire du profit sur le dos des utilisateurs tout en récupérant des données personnelles.

Résumé des problèmes de SPFBL.net

Plusieurs problèmes majeur remettent en question le bienfondé de leurs pratiques et leur impact négatif sur les entreprises légitimes.

Voici les principaux points à retenir :

  1. Exposition des données privées WHOIS
    SPFBL.net exige que les administrateurs retirent la protection de leur WHOIS pour être retirés de leur liste noire. Cela signifie que des informations personnelles et sensibles, comme l’adresse email du propriétaire du domaine, doivent être publiquement accessibles pour que l’adresse IP ne soit plus blacklistée. En Europe, cette demande est en totale contradiction avec le RGPD (Règlement Général sur la Protection des Données), qui garantit la protection des données privées des utilisateurs. Les informations contenus dans le WHOIS sont privées par défaut depuis plusieurs années. Cette exigence exposerait les administrateurs système et les entreprises à des risques d’abus ou de spams ciblés, ce qui est contraire aux bonnes pratiques en matière de sécurité et de confidentialité.
  2. Paiement pour la délistage
    En plus de la suppression de la protection WHOIS, SPFBL.net propose également une alternative : payer 2 dollars pour retirer une adresse IP de la liste noire. Cette pratique est perçue par beaucoup comme une forme de chantage. Exiger un paiement pour rétablir la légitimité d’une adresse IP, alors qu’il n’y a aucune preuve d’activité suspecte ou malveillante, remet en question la transparence de leurs opérations. Cette approche pousse probablement de nombreuses entreprises légitimes à payer simplement pour éviter les désagréments causés par le blacklistage.
  3. Un modèle de détection inefficace
    Regrouper les domaines en fonction des informations WHOIS ignore les réalités du web moderne, où de nombreuses entreprises légitimes utilisent des infrastructures partagées, hébergées par des fournisseurs comme Google ou OVH. En conséquence, des adresses IP pourraient être injustement blacklisted simplement parce qu’elles partagent un propriétaire de domaine avec d’autres utilisateurs, sans considération pour leur comportement réel.

Un impact potentiel très grave

Les conséquences de ces pratiques sont nombreuses et graves pour l’écosystème internet :

  1. Impact sur les entreprises : Lorsqu’une adresse IP est bloquée à tort, cela peut affecter la capacité d’une entreprise à communiquer par e-mail avec ses clients, partenaires ou prestataires. Les erreurs de détection ou les exigences abusives peuvent ainsi perturber le bon fonctionnement d’une entreprise.
  2. Chantage et extorsion : Demander de l’argent pour supprimer une adresse IP d’une liste noire sans preuve d’activité malveillante s’apparente à de l’extorsion. Cette approche nuit gravement à la confiance entre les fournisseurs de services internet et leurs clients.
  3. Violation de la confidentialité : En demandant la suppression de la protection WHOIS, SPFBL.net viole les principes fondamentaux de la protection des données personnelles, particulièrement en Europe, où le RGPD (Règlement Général sur la Protection des Données) protège les informations privées des utilisateurs. En exposant ces données, SPFBL.net expose les administrateurs système et les entreprises à des risques d’abus.

Que faire en tant que fournisseur de services sur internet ?

1. Cessez d’utiliser cette RBL immédiatement

Nous devons tous enjoindre nos relations chez les grands fournisseurs de services à ne surtout PAS utiliser cette RBL.

Il est absolument indispensable que les fournisseurs de services internet cessent d’utiliser SPFBL.net et d’autres RBL qui ne respectent pas les standards éthiques. Une autre RBL de ce type est également UCEPROTECT qui blacklist des blocks d’IP complets et demande ensuite de l’argent à chacun des usagers des IP pour les débloquer.

L’utilisation d’une RBL douteuse peut entraîner des conséquences néfastes pour les utilisateurs finaux, les entreprises et l’ensemble de l’écosystème numérique.

Il existe de nombreuses alternatives respectables qui se concentrent sur la détection des activités malveillantes en se basant sur des comportements réels, et non sur des informations privées ou des regroupements arbitraires de domaines. Les administrateurs système doivent rester vigilants et choisir des solutions qui respectent la vie privée et qui suivent des pratiques équitables et transparentes.

2. Ne cédez pas

Si comme moi vous êtes victime de cette RBL et estimez que ces pratiques sont abusives, ne cédez surtout pas aux prérequis scandaleux de cette RBL. Au contraire, battez-vous à mes côtés.

3. Dénoncez ces pratiques aux autorités compétentes

Faites jouer vos relations pour que cela remonte aux CSIRT français (Computer Security Incident Response Team), à l’ANSSI mais également à la CNIL pour non respect de la RGPD. Si vous avez des contacts au niveau européen, relayez l’info. Si vous êtes en dehors de France ou d’Europe, contactez les organismes à votre portée, et n’hésitez pas à vous appuyer sur cet article pour expliquer le problème.

Si vous n’avez pas de contact mais que vous comprenez l’enjeu, relayez également l’info à des personnes du domaine de l’hébergement et du sysadmin web.

Conclusion

L’affaire SPFBL.net est un exemple flagrant des dangers des pratiques douteuses de certaines RBL.

On comprend que celui qui se prétend combattre les « méchants » n’est pas toujours « gentil » lui-même.

Pour protéger l’intégrité de l’internet et le respect des utilisateurs, il est impératif que les fournisseurs de services internet cessent d’utiliser cette RBL et privilégient les solutions plus respectueuses disponibles.

Confrères sysadmin : ne cédez surtout pas aux prérequis grotesques de cette RBL.

LRob ne cèdera pas, cet article marque d’ailleurs le début d’une lutte qui ne s’arrêtra qu’une fois que la communauté aura eu gain de cause. Cela est possible, en contactant les bonnes personnes. Et vous pouvez aider à ce combat.

Si vous êtes confronté aux pratiques abusives de SPFBL.net, rejoignez-nous pour dénoncer ces actions et protéger l’intégrité de l’écosystème internet. Contactez les autorités compétentes, partagez cette information dans vos réseaux professionnels, et refusez de céder à ces pratiques déloyales.

Catégories

Hébergement Web

Réussissez sur le web

Sécurité, performances, simplicité.
Les meilleurs outils pour vous servir.

Hébergement Nextcloud

Nextcloud

La meilleure suite collaborative libre

Maintenance Incluse

Webmaster Spécialiste WordPress

Gestion de site web WordPress

Webmaster spécialiste WordPress à Orléans

Confiez votre site à un expert en sécurité et maintenance WordPress

fr_FR