Réputation des URL et empreintes de contenu

La réputation des IP et des domaines d’envoi (listes de blocage) juge qui envoie. Les filtres de contenu ajoutent deux axes qui jugent ce qui est envoyé : la réputation de chaque domaine lié dans le corps du message, et une empreinte floue du message lui-même, qui le compare aux campagnes de spam déjà vues. Les deux fonctionnent indépendamment de l’authentification et de la réputation d’IP propres à l’expéditeur : un message entièrement authentifié envoyé depuis une IP propre est quand même filtré s’il renvoie vers un domaine inscrit sur une liste de blocage ou si son empreinte correspond à une campagne connue.

Partie 1 : réputation des URL et des domaines, SURBL

SURBL est l’archétype de la DNSBL d’URI : au lieu d’inscrire des IP d’envoi, elle inscrit des domaines (et quelques IP) qui apparaissent dans le corps d’emails non sollicités ou malveillants. URIBL.com et les listes Spamhaus DBL et HBL (voir Listes de blocage et Spamhaus) fonctionnent sur le même modèle. Les filtres anti-spam extraient chaque URL d’un message, réduisent chacune à un domaine et interrogent ces zones ; une correspondance entraîne généralement un score très élevé ou un blocage pur et simple.

Zones des listes et valeurs de retour

Les données publiques sont servies dans une zone combinée à masque de bits, multi.surbl.org, qui agrège ces jeux de données :

• Les réponses sont des enregistrements A de la forme 127.0.0.X ; l’appartenance à plusieurs listes additionne les bits, par exemple 127.0.0.80 = MW + ABUSE (16 + 64).
• NXDOMAIN = non inscrit ; un enregistrement A = inscrit. SURBL indique que l’enregistrement A est « la réponse fortement privilégiée pour un usage automatisé ».
• TTL : 60 secondes par défaut sur la zone multi en production ; les données elles-mêmes sont mises à jour environ toutes les 30 à 40 secondes.
• Une réponse 127.0.0.1 n’est pas une inscription : elle signale que l’accès de l’émetteur de la requête est bloqué (volume excessif sur les miroirs publics ; il faut alors s’inscrire au Sponsored Data Service de SURBL).
• Au-delà des listes de domaines, SURBL propose aussi des requêtes de réputation par empreinte HASHBL dans plusieurs catégories : abuse, cracked, malware, phish, email, crypto, phone.
• Formats de livraison des données pour les opérateurs de filtres : DNS (Private Query Service), rsync (recommandé pour le filtrage d’emails à fort volume), RPZ (filtrage web), API REST, CSV et RTF (flux JSON en temps réel).

Notez que la liste CT (click tracker) existe tout court : les domaines de suivi et de redirection sont une catégorie d’inscription à part entière, pas un cas marginal.

Comment les filtres extraient et interrogent les URL (consignes d’implémentation de SURBL)

Les consignes publiées par SURBL à l’intention des développeurs de filtres décrivent ce que font réellement les filtres de contenu en production :

1. Extraire chaque URI du message, avec résolution complète des redirections jusqu’au domaine cible final : autrement dit, les filtres doivent suivre les redirecteurs et les raccourcisseurs jusqu’à la destination et vérifier ce domaine, et pas seulement le lien visible.
2. Réduire les URI à des domaines ou sous-domaines. Avec la zone multi à caractères génériques, les sous-domaines d’un domaine inscrit correspondent automatiquement : les filtres n’ont pas besoin de normaliser au niveau du domaine enregistré.
3. N’effectuer aucune résolution DNS sur les domaines extraits : c’est la chaîne du domaine elle-même qui sert de clé de recherche.
4. Interroger en ajoutant le domaine devant la zone (domainundertest.com.multi.surbl.org) et en faisant une recherche d’enregistrement A.
5. Les URL à IP numérique (http://10.20.30.40/) sont vérifiées avec les octets inversés, comme pour une DNSBL : 40.30.20.10.multi.surbl.org (octets en base 10).
6. Tenir une liste blanche locale de domaines légitimes à fort trafic (yahoo.com, w3.org, google.com) pour éviter des requêtes inutiles.
7. Vérifier que les réponses se situent dans 127/8 : une réponse hors de 127.0.0.0/8 indique un résolveur DNS à caractères génériques ou redirigeant qui corrompt les résultats ; utilisez un serveur de noms cache local.

Deux interdictions explicites de SURBL, car toutes deux provoquent des faux positifs avec l’hébergement mutualisé : ne pas utiliser les données d’URI du corps pour vérifier les adresses IP des expéditeurs, et ne pas résoudre les domaines inscrits en IP pour inscrire ensuite ces IP sur une liste de blocage.

Ce qu’implique ce mécanisme

• L’inscription d’un seul domaine contamine chaque message qui renvoie vers lui, quel que soit l’expéditeur et quelle que soit l’IP : l’inscription d’un domaine partagé sur une DNSBL d’URI est un incident qui touche plusieurs clients d’un ESP.
• Comme les filtres résolvent les redirections, cacher une mauvaise destination derrière un raccourcisseur ou votre propre domaine de redirection n’échappe pas au contrôle : cela expose au contraire votre domaine de redirection à une inscription quand les destinations qu’il masque font l’objet d’abus (c’est exactement ce que capte la liste CT de SURBL).
• Comme les sous-domaines d’un domaine inscrit correspondent dans la zone à caractères génériques, une inscription au niveau du domaine enregistré fait tomber tous les sous-domaines clients qui en dépendent.

Partie 2 : empreintes de contenu, les empreintes floues (rspamd)

Les empreintes floues (fuzzy hashing) détectent qu’un message est une quasi-copie d’un spam déjà signalé, même après que le spammeur l’a modifié. Le module fuzzy_check et le worker fuzzy_storage de rspamd en sont une implémentation ouverte entièrement documentée ; les systèmes commerciaux d’empreintes (et les réseaux d’empreintes partagées comme Razor, Pyzor ou DCC) suivent les mêmes principes. rspamd fournit aussi un flux d’empreintes floues public et partagé que de nombreuses installations interrogent par défaut, si bien qu’une empreinte apprise n’importe où peut compter partout.

Comment l’empreinte est construite : les shingles

• Le texte du message est découpé en mots, puis en séquences de mots qui se chevauchent (trigrammes), les « shingles ».
• Chaque shingle est haché avec plusieurs fonctions de hachage (32 empreintes par shingle) ; l’empreinte du message est l’ensemble de ces empreintes de shingles. (rspamd cite les travaux de Broder sur la ressemblance et le shingling comme fondement.)
• La comparaison est probabiliste : la similarité est calculée à partir du nombre et de la position des empreintes de shingles communes entre le message candidat et les empreintes stockées, ce qui donne un pourcentage de correspondance plutôt qu’une égalité stricte.
• Algorithmes d’empreinte du texte possibles : mumhash (valeur par défaut actuelle, recommandé), xxhash, fasthash, siphash (ancien). Changer d’algorithme invalide toutes les données stockées.
• Les images et les pièces jointes sont comparées à l’identique, et non de façon floue, via des empreintes blake2b de leur contenu : un seul octet modifié rompt la correspondance, ce qui explique que les campagnes de spam par images régénèrent les images à chaque envoi, et que les filtres combinent ce mécanisme avec des empreintes perceptuelles d’images par ailleurs.

Principales valeurs par défaut de fuzzy_check : min_bytes = 1k (taille minimale des pièces jointes et images prises en compte), min_height/min_width = 32 px pour les images, min_length = 0 (toutes les parties texte sont vérifiées), text_multiplier = 4.0, timeout = 2s, retransmits = 1 ; mime_types sélectionne les types de pièces jointes hachés (par exemple application/*) ; short_text_direct_hash hache à l’identique les textes trop courts pour le shingling.

Empreintes floues de la structure HTML (rspamd v3.14+)

Depuis la v3.14.0, rspamd peut aussi calculer l’empreinte de la structure du DOM indépendamment du texte : des jetons de la forme tagname[.class][@domain] (par exemple a.button@example.com ; seule la première classe CSS est utilisée, les classes de suivi connues sont filtrées, les domaines des liens sont normalisés en eTLD+1). Pondération de l’empreinte combinée : shingles de structure 50 %, domaines des appels à l’action (CTA) 30 %, ensemble des domaines des liens 15 %, décomptes de caractéristiques (balises, liens) 5 %. Garde-fous contre la correspondance avec des modèles génériques : exige au moins min_html_tags (10 par défaut ; les configurations d’exemple utilisent 15), au moins 2 liens et une profondeur de DOM d’au moins 3.

La pondération des domaines de CTA vise le phishing : un phishing qui clone parfaitement le modèle d’une marque obtient une similarité de structure d’environ 0,9, mais avec des domaines de CTA différents la similarité combinée s’effondre (exemple documenté : structure 0,9 × CTA non concordant ⇒ combinée 0,45) ; à l’inverse, une campagne de spam qui garde son domaine de CTA tout en remaniant le texte correspond toujours.

Pourquoi les modifications et le bourrage de jetons ne permettent pas d’y échapper

Parce que l’empreinte est un grand ensemble d’empreintes de trigrammes de mots qui se chevauchent, comparées de façon probabiliste :

• Les petites modifications (mots échangés, noms insérés, paragraphes réordonnés) ne changent que les shingles qui chevauchent la modification ; l’essentiel des shingles correspond toujours, et la similarité reste au-dessus du seuil.
• Le bourrage de jetons (ajout de mots aléatoires, texte masqué, « hash-busters ») ajoute des shingles mais ne supprime pas ceux qui correspondent ; il ne dilue que marginalement le ratio de similarité, tandis que le nombre absolu de shingles connus comme mauvais continue de correspondre. Pour mettre en échec la correspondance par shingles, il faut réécrire pratiquement tout le corps du message, et à ce stade l’empreinte de la structure HTML (v3.14+) correspond encore au modèle et au domaine de CTA inchangés.
• Les champs de fusion propres à chaque destinataire, les URL de désabonnement et les jetons de suivi laissent de même intacte la masse de shingles commune ; c’est exactement pourquoi une campagne, signalée par ses premiers destinataires, est reconnue dans le reste de l’envoi.

Poids, seuils et score progressif

Les empreintes stockées portent un poids qui s’accumule à mesure que des sources (signalements d’utilisateurs, adresses pièges touchées, pots de miel) signalent de nouveau la même empreinte. Le score est volontairement progressif, et non binaire :

• Chaque flag ou règle a un max_score (seuil de poids de l’empreinte). En dessous du seuil, le symbole vaut 0 ; le score monte ensuite du seuil jusqu’à 2 fois le seuil (courbe en tangente hyperbolique : environ 50 % du poids de la métrique au seuil, score complet à 2 fois le seuil). Exemple : avec un poids de signalement de 1 et un seuil de 20, une empreinte doit recevoir au moins 20 plaintes indépendantes avant de compter.
• Les empreintes sont organisées par flags numériques qui associent des catégories à des symboles ; la disposition conventionnelle : flag 1 = spam confirmé (FUZZY_DENIED, max_score 20), flag 2 = spam probable (FUZZY_PROB, max_score 10), flag 3 = contenu légitime ou sur liste blanche (FUZZY_WHITE, max_score 2). Les numéros de flag doivent être uniques parmi les règles en écriture ; skip_hashes place des empreintes précises sur liste blanche.
• Apprentissage : rspamc -f <flag> -w <weight> fuzzy_add <message> (ou -S FUZZY_DENIED), suppression via fuzzy_del ; read_only = true rend une règle interrogeable uniquement ; une condition d’apprentissage Lua facultative peut filtrer l’apprentissage ou changer le flag.

Côté exploitation (worker fuzzy_storage) : architecture à écrivain unique, avec une file de mises à jour synchronisée sur disque tous les sync = 1min ; stockage SQLite (par défaut) ou Redis ; expiration des empreintes via expire (90d recommandé au départ ; les anciennes empreintes disparaissent à mesure que les campagnes meurent) ; dimensionnement d’environ 400k empreintes par 100 Mo de RAM (1,5M ≈ 500 Mo) ; apprentissage restreint aux IP allow_update ; chiffrement facultatif du transport en Curve25519 (encrypted_only = true) et réplication maître-esclave (TCP 11335) avec traduction des flags par esclave.

Conséquences pour les expéditeurs

Les deux mécanismes se combinent en règles concrètes pour quiconque exploite un ESP ou un programme d’envoi :

• Chaque domaine présent dans le corps porte une réputation : domaines des liens, domaines d’hébergement des images, domaines de redirection et de suivi des clics, et même les domaines écrits en texte brut. Leur réputation est évaluée séparément de celle du domaine From et de l’IP d’envoi.
• Les domaines de suivi partagés partagent le même sort. Un domaine de suivi des clics ou d’habillage des liens commun à tout un ESP agrège la réputation des destinations de tous les clients ; un seul client abusif peut le faire inscrire sur une DNSBL d’URI (la catégorie CT de SURBL existe exactement pour cela), ce qui filtre d’un coup les emails de tous les clients. Parades : sous-domaines de suivi par client sur des domaines appartenant aux clients (via CNAME), surveillance proactive des domaines de suivi sur les DNSBL d’URI, et contrôle des URL de destination au moment de l’envoi auprès de SURBL, URIBL et de la DBL.
• Les raccourcisseurs publics sont pires qu’inutiles : les filtres les résolvent de toute façon jusqu’à la destination, et le domaine du raccourcisseur porte lui-même la réputation accumulée de tous ceux qui en abusent ; voir Contenu et design pour la délivrabilité.
• L’hygiène des domaines de liens est une tâche de surveillance, pas une vérification ponctuelle : interrogez multi.surbl.org (et la Spamhaus DBL) sur vos domaines de suivi, d’images et de pages de destination au même rythme que la surveillance des IP sur les listes de blocage, et vérifiez les URL de chaque campagne sortante avant l’envoi.
• Les empreintes rendent la vitesse des plaintes rétroactive : les quelques milliers de premiers destinataires qui signalent une campagne créent ou alourdissent son empreinte floue, et le reste du même envoi y correspond alors. L’envoi par segments avec pause (envoyer d’abord aux plus engagés, surveiller les premiers signaux de plaintes, puis continuer) exploite directement la fenêtre de score entre le seuil et 2 fois le seuil.
• Les variantes de modèle ne remettent pas à zéro la réputation du contenu. De petites modifications du texte, la rotation des lignes d’objet ou la personnalisation par champs de fusion laissent intacte l’empreinte par shingles (et l’empreinte de structure HTML et de CTA). La seule vraie remise à zéro, c’est un contenu réellement différent envoyé à un public qui le souhaite : la réputation du contenu est un symptôme de la qualité de la liste, pas un problème d’ingénierie du contenu.
• Des domaines de CTA constants jouent dans les deux sens : garder vos liens sur vos propres domaines stables et bien réputés aide l’empreinte de structure à vous distinguer des clones de phishing de votre modèle ; disperser les liens sur des domaines jetables ressemble à une tentative de contournement.

Voir aussi

• Listes de blocage et Spamhaus : fonctionnement des DNSBL d’IP et de domaines, Spamhaus DBL et HBL (les autres grands jeux de données de réputation des domaines).
• Contenu et design pour la délivrabilité : les règles pratiques de contenu (raccourcisseurs, images, pratiques de liens) que ces mécanismes expliquent.
• Reputation Monitoring : la place des vérifications des domaines de suivi et de liens sur les DNSBL d’URI dans un programme de surveillance.