Inscriptions Spamhaus en détail : politiques SBL, CSS, PBL et DBL, et retrait de liste

Complément de Listes de blocage et Spamhaus, qui traite du fonctionnement des DNSBL, des tableaux complets des zones et des codes de retour, et des recommandations de Spamhaus aux expéditeurs. Cet article va plus loin, liste par liste : la politique réelle de chaque liste, la façon dont les inscriptions s’étendent, et la procédure exacte de retrait de liste pour chacune ; ce dont un opérateur a besoin quand une IP partagée ou le domaine d’un client est inscrit.

SBL : Spamhaus Blocklist (127.0.0.2)

Tenue manuellement par une équipe de recherche OSINT ; la base compte en moyenne 30 000 à 40 000 inscriptions. La zone est reconstruite et rechargée toutes les 5 minutes, 24 h/24 et 7 j/7, si bien que les nouvelles inscriptions comme les retraits se propagent rapidement.

Ce qui est inscrit

Les IP « sous le contrôle de spammeurs et d’abuseurs, utilisées par eux ou mises à leur disposition pour des emails non sollicités envoyés en masse ou d’autres formes d’abus sur Internet » :

• Plages de snowshoe spam : « des plages et des domaines à l’identification médiocre ou changeant fréquemment ».
• Hébergement de spam : les IP qui hébergent des sites web promus par spam ou des ressources utilisées par des opérations de spam ou de logiciels malveillants (l’inscription n’exige pas que l’IP émette des emails).
• Services de spam : l’hébergement « bulletproof » (« des actions explicites ou tacites visant à ne pas déconnecter les clients qui spamment »), les logiciels de spam (spamware, « des logiciels dont le but principal est de faciliter l’envoi en grand volume d’emails non sollicités »), les outils de scraping d’adresses.
• Menaces de sécurité : serveurs de commande et de contrôle (C&C) de botnets, sites infectés par des logiciels malveillants, pages de phishing, infrastructures de rançongiciels.

Des inscriptions informatives existent à côté des inscriptions bloquantes : « un signal d’alerte précoce indiquant que l’IP inscrite a un mauvais comportement. Les inscriptions informatives sont indicatives et n’entraînent pas le blocage des IP. » Considérez-en une comme le dernier avertissement avant une inscription SBL bloquante.

Politique d’extension des inscriptions

Quand un réseau ignore ses inscriptions, Spamhaus étend l’inscription au-delà des IP abusives, « aux adresses IP de l’infrastructure même de ce réseau, à des plages étendues de ce réseau, voire à ce réseau tout entier ». Déclencheurs :

• ignorer des inscriptions SBL pendant de longues périodes ;
• prétendre supprimer des spammeurs qui réapparaissent sans cesse (en faisant tourner les clients d’une IP à l’autre) ;
• fournir un hébergement bulletproof ;
• des problèmes persistants de spam ou de sécurité.

Pour un ESP, c’est le risque existentiel : tolérer un seul mauvais client peut transformer l’inscription d’une seule IP en inscription du MX de l’entreprise, de son site web ou de toute son allocation.

Retrait de liste SBL

Seul le fournisseur d’accès ou le réseau responsable de l’IP inscrite peut demander le retrait ; les utilisateurs finaux et les clients d’un ESP ne le peuvent pas et doivent passer par leur fournisseur. La procédure :

1. Lisez la page de l’inscription SBL (accessible depuis l’outil de vérification) pour comprendre le problème de spam précis.
2. Corrigez-le définitivement : pour un client spammeur, la remédiation type qu’attend Spamhaus consiste à résilier ou déconnecter le serveur, supprimer les entrées DNS servies par les serveurs DNS principaux du fournisseur d’accès, supprimer les enregistrements PTR, empêcher les serveurs MX d’accepter des emails pour le client, supprimer les entrées SWIP et rWhois (c’est-à-dire tout déprovisionner, et pas seulement suspendre l’envoi).
3. Le service abus ou sécurité du fournisseur d’accès soumet une demande de retrait à la SBL Removals Team en décrivant comment le problème a été résolu : une explication est exigée, pas un simple « merci de retirer l’inscription ».

Il n’existe pas d’engagement de délai publié au-delà de « une fois que l’abus a pris fin » ; les enquêtes peuvent exiger une preuve de consentement et une nouvelle demande d’autorisation auprès de toute la liste en cause (voir Listes de blocage et Spamhaus). Le retrait de liste est toujours gratuit : « Toute offre, d’où qu’elle vienne, de retirer une inscription Spamhaus contre paiement est une escroquerie. »

CSS : Combined Spam Sources (127.0.0.3)

CSS est le composant automatisé de la zone SBL ; il cible « les adresses IP impliquées dans l’envoi d’emails à faible réputation ». Il observe exclusivement le trafic SMTP sur le port 25. Ampleur : 2 à 4 millions d’inscriptions à tout moment, avec 300 000 à 400 000 nouvelles inscriptions toutes les 24 heures ; c’est la liste sur laquelle un client d’ESP légitime mais négligent a le plus de chances de se retrouver.

Détection et granularité

Les inscriptions résultent de « multiples événements et heuristiques » (non divulgués) ; les déclencheurs nommés :

• les opérations de snowshoe : des émetteurs de spam statiques répartis finement sur des IP et des domaines, non détectés par les autres listes ;
• les hôtes compromis : installations non sécurisées, serveurs mal configurés, comptes piratés, exploitation de CMS ;
• la mauvaise hygiène de base de données : des emails non sollicités envoyés par des expéditeurs qui gèrent mal leurs abonnés.

Granularité : IPv4 /32 ; IPv6 /64 (selon la pratique d’attribution de la RFC 4291). Des blocs IPv6 plus larges sont agrégés si de nombreux /64 d’un même réseau se comportent mal ; une raison pour laquelle les ESP qui envoient en IPv6 doivent isoler leurs clients au minimum par /64.

Causes fréquentes pour l’infrastructure d’un ESP

• HELO/EHLO qui n’est pas un FQDN (localhost.localdomain, mail seul) ;
• rDNS absent, ou rDNS qui ne correspond pas au DNS direct (l’aller-retour PTR → nom d’hôte → même IP est exigé) ;
• absence de chauffe d’IP : des IP froides qui émettent du volume ressemblent à du snowshoe (voir Chauffe d’IP) ;
• listes de clients en simple opt-in ou mal entretenues qui touchent des adresses pièges (« utilisez le double opt-in pour éviter les adresses pièges ») ;
• réglages par défaut des panneaux de contrôle (Plesk, cPanel, DirectAdmin) et répartiteurs de charge présentant des identités génériques ; DNS avec caractères génériques.

Expiration et retrait de liste CSS

Expiration automatique : normalement trois jours (72 h) après la dernière détection de spam ; « dans certains cas d’abus chronique, les inscriptions peuvent durer plus longtemps ». Comme l’expiration est automatique, la première décision consiste à choisir entre attendre et demander soi-même le retrait.

Retrait en libre-service via check.spamhaus.org : « La cause du problème DOIT être identifiée et corrigée avant de retirer une IP de CSS. » Les retraits en libre-service sont limités en nombre et la réinscription est immédiate si la cause persiste : épuiser ses retraits sans corriger la cause profonde transforme un désagrément de 72 heures en inscription chronique. La procédure CSS de l’outil de vérification contrôle les bases des RFC 5321/5322 (rDNS, HELO) avant d’autoriser le retrait.

PBL : Policy Blocklist (127.0.0.10 / 127.0.0.11)

La PBL relève de la politique, pas de l’abus : « des plages d’adresses IP d’utilisateurs finaux qui ne devraient pas tenter de livrer directement des emails SMTP non authentifiés à un quelconque serveur de messagerie sur Internet ». Une inscription PBL n’est pas une accusation de spam. Elle contient plus de 1,4 milliard d’adresses IPv4, soit environ 40 % de l’espace IPv4 routable, principalement des plages haut débit et d’accès commuté de fournisseurs d’accès, plus quelques blocs CIDR IPv6. Reconstruction de la zone : toutes les 15 minutes.

Deux sources de données, distinguées par le code de retour :

Retrait en libre-service

L’opérateur d’un serveur de messagerie sur une IP inscrite à la PBL peut retirer une seule IP via le Reputation Checker, si toutes ces conditions sont réunies :

• l’IP est statique (les IP dynamiques doivent plutôt relayer par le smarthost du fournisseur d’accès) ;
• un serveur de messagerie sortant fonctionne réellement sur cette IP ;
• le DNS direct (A) et le DNS inverse (PTR) sont correctement configurés ;
• l’IP est attribuée à la personne ou à l’entreprise qui demande le retrait : les demandes envoyées depuis des adresses de messagerie gratuite (Gmail, Hotmail, Yahoo) sont refusées ; la demande doit provenir d’une adresse d’un domaine correspondant au serveur de messagerie.

Propagation après le retrait : environ 15 minutes. Contraintes : les exclusions expirent au bout d’un an ; elles sont annulées immédiatement si du spam est détecté ; retirer de nombreuses IP une à une entraîne l’annulation des exclusions et la révocation de l’accès ; les retraits de plages multiples doivent être faits par le fournisseur d’accès propriétaire de l’espace d’adresses (important quand un ESP acquiert une plage située dans un bloc PBL d’un réseau d’accès : demandez au fournisseur en amont de l’exclure de son compte PBL, ne multipliez pas les retraits IP par IP).

La bonne solution pour les utilisateurs finaux derrière la PBL n’est pas du tout le retrait, mais la soumission authentifiée sur le port 587/465 vers le smarthost de leur fournisseur. La PBL n’affecte que la livraison directe vers les MX sur le port 25.

Comptes PBL des fournisseurs d’accès

Les réseaux gèrent leur propre espace d’adresses avec un compte PBL. Conditions : au moins une allocation IPv4 /24 ou IPv6 /48 ; un domaine principal vérifiable dans l’IP-Whois, le rWhois ou le rDNS ; une adresse abuse@ fonctionnelle ; une adresse email professionnelle sur le domaine principal (ou un domaine apparenté). Structure : des Master Ranges (l’allocation complète) contenant des inscriptions de zone PBL (les sous-ensembles effectivement inscrits) ; les modifications prennent effet en moins de 15 minutes. Un ESP qui exploite sa propre allocation devrait détenir un compte PBL, ne serait-ce que pour garantir que ses plages transactionnelles et d’envoi sont exclues et pour inscrire tout espace d’accès client qu’il exploite.

DBL : Domain Blocklist (127.0.1.x)

Des domaines uniquement : « Aucune adresse IP n’est inscrite dans la DBL. » Plus de 80 miroirs dans le monde ; les inscriptions sont en majorité automatisées, avec intervention manuelle si nécessaire, et expirent automatiquement une fois que le domaine ne répond plus aux critères d’inscription. Tableau complet des codes de retour dans Listes de blocage et Spamhaus ; la distinction essentielle oppose les codes 127.0.1.2–.6 (le domaine lui-même est mauvais : spam, phishing, logiciel malveillant, C&C de botnet) aux codes 127.0.1.102–.106 (site légitime détourné : un domaine légitime compromis et utilisé à des fins abusives).

Causes d’inscription

Les critères sont délibérément tenus secrets (« Nous ne discutons pas des critères précis que nous utilisons »), mais les principes de réputation affichés sont :

• Une réputation inconnue est par défaut mauvaise : « les réputations se construisent dans le temps, et construire une bonne réputation prend plus longtemps qu’en construire une mauvaise ». Les nouveaux domaines d’envoi partent avec un handicap (voir aussi ZRD pendant les 24 premières heures).
• L’anonymat nuit à la réputation (WHOIS anonymisé, opérateurs cachés).
• Les réputations des domaines et des IP s’influencent mutuellement : un hébergement propre avec un rDNS correct compte pour le domaine.
• La rotation de domaines du snowshoe : de nombreux domaines changeant fréquemment constituent en soi le signal ; « les expéditeurs légitimes investissent dans une infrastructure durable, à long terme ».
• SPF, DKIM et DMARC ne protègent pas contre l’inscription : les spammeurs s’authentifient aussi ; les enregistrements d’authentification ne justifient jamais à eux seuls un retrait de liste.
• Spamhaus n’analyse pas les sites web ; les inscriptions proviennent du trafic observé : « quand nous voyons ces signes, cela signifie avec certitude que le site web ou le serveur n’est pas sécurisé, qu’il est infecté ou compromis ».

Sites légitimes détournés (127.0.1.102–.106)

Des sites légitimes compromis : CMS et extensions obsolètes, identifiants faibles, mauvaise sécurité du serveur. Les inscriptions visent des noms d’hôte plutôt que le domaine entier quand c’est possible, pour éviter de bloquer le site légitime. Étapes de retrait prescrites par Spamhaus : mettre le site hors ligne pendant la correction ; supprimer les fichiers infectés ; mettre à jour le CMS et toutes les extensions ; auditer la sécurité du serveur ; changer tous les mots de passe et activer la double authentification (2FA). Pour un ESP, c’est la famille de codes à vérifier quand le domaine du propre site web d’un client (utilisé dans les liens) est inscrit alors que ses pratiques d’envoi semblent saines.

Règles d’interrogation que les serveurs de réception doivent respecter

• N’interrogez jamais d’IP dans la DBL : une requête d’IP renvoie toujours « inscrit » (127.0.1.255), à dessein, pour qu’un filtre mal configuré qui rejette les emails contenant des liens vers des IP littérales échoue de manière visible.
• Caractères génériques : la DBL inscrit au niveau du domaine enregistré, et chaque nom d’hôte ou sous-domaine qui en dépend renvoie « inscrit » (www.bank.phish.example.tld correspond à une inscription de example.tld). Les variantes ressemblantes du domaine ne correspondent pas.
• À appliquer à trois étapes : domaine rDNS de l’IP qui se connecte, à la connexion ; domaine HELO et MAIL FROM, avant DATA ; URL, domaines des en-têtes et adresses de contact, lors de l’inspection du contenu.
• Points de test : test.dbl.spamhaus.org → 127.0.1.2 (test opérationnel de la RFC 5782) ; dbltest.com.dbl.spamhaus.org → 127.0.1.2 ; tout ce qui n’est pas inscrit → NXDOMAIN.
• Validez les plages de réponse : seules les réponses comprises dans 127.0.1.0/24 sont des inscriptions DBL. C’est important en Chine, où la manipulation du trafic par le Golden Shield peut altérer les réponses DNS ; toute autre valeur signifie non inscrit. (Depuis les miroirs chinois de Spamhaus, la DBL n’est servie qu’en requêtes d’IP ; les utilisateurs chinois obtiennent les réponses sur les domaines depuis l’extérieur.)
• Fonctionne dans les déploiements RPZ / « pare-feu DNS » et pour le filtrage du spam dans les commentaires de blogs. Microsoft Exchange ne prend pas en charge nativement les DNSBL de domaines (des produits tiers sont nécessaires).

Retrait de liste DBL

• Automatique : la plupart des inscriptions expirent d’elles-mêmes une fois l’activité déclencheuse arrêtée ; pour les inscriptions passagères, corriger la cause et attendre suffit souvent.
• Manuel : via le formulaire du Reputation Checker ; « utiliser le formulaire ne garantit pas le retrait », et les demandeurs de retraits excessifs sont bloqués. Les retraits approuvés sont traités immédiatement (en quelques minutes chez Spamhaus), mais les copies locales des serveurs de réception peuvent avoir jusqu’à 24 heures de retard (contactez Spamhaus si l’inscription persiste plus de 24 h après l’approbation).
• La réinscription est automatique en cas de nouvelle détection ; un retrait de liste sans correction de la cause profonde ne tient pas.
• Gratuit, toujours.

Recommandations DBL pour les raccourcisseurs d’URL et les redirecteurs (les domaines de suivi des clics des ESP se comportent exactement de la même façon)

Vérifiez chaque domaine de destination dans la DBL avant de créer un lien court, puis revérifiez plus tard (à environ 1 jour et environ 1 semaine) ; refusez les destinations dont les enregistrements A figurent dans la SBL (et, en option, dans la XBL) ; n’autorisez jamais la modification de l’URL de destination après la création ; n’enchaînez pas par d’autres raccourcisseurs ; suspendez les liens abusifs avec un code 404/410 (pas une page intermédiaire) ; protégez la création par CAPTCHA ou une prévention des robots ; envisagez ZRD pour filtrer les domaines tout neufs ; faites fonctionner abuse@, postmaster@ et des feedback loops pour le service. Un ESP dont le domaine partagé de suivi des clics est inscrit dans la DBL a généralement enfreint plusieurs de ces règles à la fois.

Interroger correctement les zones (FAQ sur l’utilisation des DNSBL)

Règles qu’un serveur de réception doit suivre, y compris un ESP qui filtre son propre trafic entrant ou les emails de sa plateforme :

• N’interrogez que ZEN pour les vérifications d’IP : « Les sous-zones de Zen (SBL, XBL, PBL) ne doivent pas être interrogées séparément », et ne combinez jamais des requêtes ZEN avec des requêtes SBL, XBL ou PBL : une seule réponse ZEN contient déjà tous les codes applicables.
• N’appliquez pas les DNSBL aux emails sortants, « en particulier la PBL » : vos propres clients de smarthost se trouvent légitimement dans l’espace PBL. La surveillance des envois sortants exige d’autres outils (voir Reputation Monitoring).
• N’interrogez jamais via des résolveurs publics (8.8.8.8, Cloudflare, Quad9, résolveurs partagés des fournisseurs d’accès), sauf si le résolveur prend en charge ECS ; le réseau d’origine doit être identifiable. Les requêtes passant par un résolveur anonyme reçoivent la réponse 127.255.255.254. Les requêtes provenant de grands environnements d’hébergement mutualisé sont refusées.
• Traitez les codes d’erreur comme « ne pas bloquer » : 127.255.255.254 (requête anonyme ou via un résolveur public), 127.255.255.255 (volume de requêtes dépassé), 127.255.255.252 (faute de frappe dans le nom de zone) ; un filtre qui les traite comme des inscriptions rejette tous les emails.
• Tests depuis le réseau du serveur de messagerie lui-même : dig 2.0.0.127.zen.spamhaus.org +short doit renvoyer 127.0.0.x ; dig 1.0.0.127.zen.spamhaus.org +short doit renvoyer NXDOMAIN. Le Blocklist Tester, sur blt.spamhaus.com, valide le fonctionnement de bout en bout en envoyant des emails de test.
• Niveaux d’accès : les miroirs publics gratuits sont réservés aux petites et moyennes organisations non commerciales, dans le cadre d’une utilisation équitable (la politique d’utilisation équitable des DNSBL ne publie aucun chiffre ferme ; les services commerciaux de filtrage anti-spam et les fournisseurs d’accès doivent s’abonner quel que soit leur volume). Le niveau gratuit DQS est plafonné à « ne pas dépasser régulièrement 100 000 requêtes par jour », pour un usage non commercial. Au-delà : DQS payant ou le Data Feed par rsync (transfert local de zone, qui exige d’exploiter votre propre résolveur ; DQS donne en plus accès à certains jeux de données exclusifs comme ZRD, HBL et AuthBL).
• Aucune recherche automatisée sur check.spamhaus.org : l’outil de vérification web est destiné à un usage manuel ; l’automatisation fait bloquer l’IP qui interroge par le pare-feu.

Synthèse des procédures de retrait de liste

Toutes les vérifications et demandes commencent sur l’IP & Domain Reputation Checker (gratuit, sans compte pour vérifier ; évalue automatiquement l’IP du visiteur). L’outil en ligne est une application JavaScript protégée contre les robots, et seul son texte d’accueil a pu être capturé (« Do you have problems sending email? … Relax, you’re in the right place », soit « Vous avez des problèmes pour envoyer des emails ? … Pas d’inquiétude, vous êtes au bon endroit », via un instantané de la Wayback Machine du 2026-07-09) ; son comportement décrit ci-dessus provient des pages officielles de Spamhaus sur les listes de blocage et de ses FAQ.

Rappelez-vous que le retrait d’une zone Spamhaus ne débloque pas instantanément la livraison : les serveurs de réception rafraîchissent leurs copies selon leur propre calendrier (quelques minutes pour les utilisateurs de DQS et de ZEN, jusqu’à 24 h pour les plus lents), et l’atteinte à la réputation côté serveur de réception se résorbe séparément.