Le ticket arrive un mardi matin : « Aucun email envoyé depuis le site ne parvient à nos clients Gmail ni Outlook, et certains reviennent avec une erreur bizarre ». Après vérification des journaux mail du serveur, le message de rejet est sans ambiguïté : 550 5.7.1 Service refused, IP listed by Spamhaus. L’IP partagée du serveur mutualisé vient de rejoindre une liste noire, probablement à cause d’un autre client hébergé sur la même machine dont un site compromis a servi à envoyer du spam pendant la nuit.
Ce genre de panne ne se règle pas en modifiant un réglage WordPress : la responsabilité de la délivrabilité, une fois l’IP blacklistée, ne dépend plus du site mais de la réputation de l’adresse IP elle-même auprès de Spamhaus. Voici la procédure suivie pour lever le blocage en limitant la casse commerciale du client.
Identifier précisément la liste concernée
Spamhaus ne publie pas une seule liste noire mais plusieurs, chacune avec un sens différent. La confusion entre elles fait perdre un temps précieux :
- SBL (Spamhaus Block List) : IP ayant directement envoyé du spam, souvent suite à une compromission.
- XBL (Exploits Block List) : IP identifiée comme faisant partie d’un botnet ou exploitée à distance.
- PBL (Policy Block List) : plage IP jugée non destinée à envoyer du courrier directement (typiquement des IP résidentielles ou dynamiques).
- CSS (Composite Snowshoe List) : comportement d’envoi en rafale caractéristique du spam de faible volume distribué.
La première étape consiste à interroger l’outil de recherche public de Spamhaus (spamhaus.org/lookup) avec l’IP sortante du serveur. Le résultat indique la liste exacte et, souvent, un identifiant de référence à citer dans la demande de retrait.
Comprendre pourquoi l’IP a été signalée
Avant même de demander le retrait, il faut couper la cause : redemander un délisting sans avoir traité la source ne fait que reproduire l’incident sous quelques jours. Sur un serveur mutualisé, la cause la plus fréquente est un compte compromis (identifiants WordPress volés, plugin vulnérable exploité) qui envoie du spam via wp_mail() ou un script PHP injecté directement.
# Repérer un pic d'envoi anormal dans les journaux Exim ou Postfix
grep -c "cwd=/home/clientX" /var/log/exim_mainlog | sort -rn
# Isoler les fichiers PHP modifiés récemment sur le compte suspect
find /home/clientX/public_html -name "*.php" -mtime -2 -newer /home/clientX/public_html/wp-config.php
Sur ce cas précis, l’analyse a révélé un fichier wp-content/uploads/2023/09/cache.php, injecté via un plugin de galerie photo obsolète, qui envoyait plusieurs milliers de messages par heure vers des domaines russes et brésiliens. Sa suppression, suivie d’un changement de tous les mots de passe du compte et d’une analyse antivirus complète, a coupé la source avant toute demande de délisting.
Soumettre la demande de retrait
Spamhaus met à disposition un formulaire de retrait dédié par liste. Pour une SBL, la demande doit décrire factuellement ce qui a été corrigé, sans formule vague de type « nous avons résolu le problème » : les vérificateurs de Spamhaus rejettent les demandes trop génériques. Une bonne demande mentionne :
- Le fichier malveillant identifié et sa date de suppression.
- La méthode de compromission présumée (plugin, thème, identifiants).
- Les mesures prises pour éviter la récidive (changement de mots de passe, mise à jour, restriction d’accès).
- Un contact technique joignable en cas de question complémentaire du vérificateur.
Délais et vérifications automatiques
Les délais de traitement varient fortement selon la liste : une PBL peut se lever automatiquement en quelques heures dès que le comportement d’envoi redevient conforme, tandis qu’une SBL nécessite souvent une revue humaine côté Spamhaus, avec un délai pouvant s’étendre sur plusieurs jours en période de forte charge. Il est inutile de soumettre plusieurs demandes en parallèle : cela ralentit généralement le traitement plutôt que de l’accélérer.
| Liste | Cause typique | Délai constaté |
|---|---|---|
| PBL | Plage jugée non destinée à l’envoi direct | Quelques heures, souvent automatique |
| XBL | Compromission de type botnet | 1 à 2 jours après nettoyage confirmé |
| SBL | Envoi de spam constaté et tracé | 2 à 5 jours, revue manuelle |
Limiter la casse pendant l’attente
En attendant le délistage, il reste possible de faire transiter les emails critiques du client (confirmations de commande, réinitialisations de mot de passe) par un relais SMTP tiers dont la réputation d’IP est distincte de celle du serveur mutualisé. C’est une solution provisoire, pas une architecture cible, mais elle évite que le client perde des ventes pendant les jours de blocage.
Sur un serveur mutualisé, la réputation de l’IP appartient à tout le monde et à personne : un seul compte compromis peut couper la délivrabilité de dizaines de sites qui n’ont rien fait de mal. C’est un argument de poids pour faire évoluer un client vers une IP dédiée quand le volume d’emails transactionnels le justifie.
En résumé
Sortir d’une liste Spamhaus suit toujours le même ordre : identifier la liste précise, éliminer la cause réelle de l’incident, puis soumettre une demande factuelle et documentée. Sauter la deuxième étape condamne la troisième à l’échec, et vouloir accélérer en multipliant les demandes ralentit généralement le traitement. Sur un hébergement mutualisé, ce type d’incident reste un risque structurel qu’aucune configuration WordPress ne peut éliminer à elle seule.
