# Réputation des URL et empreintes de contenu

> Comment les filtres de contenu modernes jugent le corps des messages : listes de réputation des URL et des domaines (zones SURBL, mécanique des requêtes, traitement des redirecteurs) et empreintes floues (shingles de rspamd, détection de campagnes quasi identiques), et ce que cela implique pour les domaines de liens et les modèles des expéditeurs.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/reference/reputation-des-url-et-empreintes-de-contenu

Un message peut être entièrement authentifié et envoyé depuis une adresse IP propre, et être quand même filtré à cause de ce qu'il contient. La réputation des adresses IP et des domaines d'envoi ([listes de blocage](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)) juge qui envoie. Les filtres de contenu ajoutent deux contrôles qui jugent ce qui est envoyé : la réputation de chaque domaine lié dans le corps du message, et une empreinte floue du message, comparée aux campagnes de spam déjà vues.

Ces deux contrôles fonctionnent indépendamment de l'authentification et de la réputation d'IP propres à l'expéditeur. Un message qui renvoie vers un domaine inscrit sur une liste de blocage, ou dont l'empreinte correspond à une campagne connue, est filtré quoi qu'il en soit.

## Partie 1 : réputation des URL et des domaines (SURBL)

SURBL est l'exemple type de la **DNSBL d'URI**. Au lieu d'inscrire des adresses IP d'envoi, elle inscrit des domaines (et quelques adresses 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](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus)) fonctionnent de la même manière. Les filtres antispam extraient chaque URL d'un message, réduisent chacune à un domaine et interrogent ces zones pour ce domaine. Une correspondance ajoute généralement un score très élevé ou bloque le message purement et simplement.

### Zones des listes et valeurs de retour

Les données publiques sont servies dans une seule zone combinée à valeurs en masque de bits, **`multi.surbl.org`**, qui réunit ces jeux de données :

| Liste | Signification | Valeur du bit (dernier octet) |
|------|---------|------------------------|
| DM | Domaines d'adresses email jetables | 4 |
| PH | Sites de phishing | 8 |
| MW | Sites de logiciels malveillants | 16 |
| CT | Domaines de suivi des clics (click trackers) | 32 |
| ABUSE | Sites d'abus ou de spam en général | 64 |
| CR | Sites piratés (sites légitimes compromis) | 128 |

- Les réponses sont des enregistrements A de la forme **127.0.0.X**. Un domaine inscrit sur plusieurs listes renvoie la somme de leurs bits. Par exemple, **127.0.0.80 signifie MW plus ABUSE (16 plus 64)**.
- **NXDOMAIN** signifie que le domaine n'est pas inscrit, et un enregistrement A qu'il l'est. SURBL indique que l'enregistrement A est « la réponse fortement privilégiée pour un usage automatisé ».
- Le **TTL par défaut est de 60 secondes** sur la zone multi en production, et 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é à cause d'un volume excessif sur les miroirs publics, et qu'il doit s'inscrire au Sponsored Data Service de SURBL.
- Au-delà de ses listes de domaines, SURBL propose aussi **HASHBL**, des requêtes de réputation fondées sur des empreintes, dans ces catégories : abuse, cracked, malware, phish, email, crypto, phone.
- Pour les opérateurs de filtres, les données sont livrées en DNS (Private Query Service), en rsync (recommandé pour le filtrage d'emails à fort volume), en RPZ (filtrage web), par API REST, en CSV et en RTF (flux JSON en temps réel).

L'existence même de la liste **CT (click tracker)** compte : les domaines de suivi et de redirection sont une catégorie d'inscription à part entière, et non 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, en **résolvant complètement les 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, donc les filtres n'ont pas besoin de normaliser au niveau du domaine enregistré.
3. **Ne pas résoudre les domaines extraits dans le DNS.** 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 à adresse IP numérique** (`http://10.20.30.40/`) sont vérifiées avec les octets inversés, comme le font les DNSBL : `40.30.20.10.multi.surbl.org` (octets en base 10).
6. Tenir une **liste blanche locale** de domaines connus et à 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 qui utilise des caractères génériques ou des redirections et corrompt les résultats ; utilisez un serveur de noms cache local.

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

### Ce qu'implique ce mécanisme

- L'inscription d'un seul domaine touche **chaque message qui renvoie vers lui**, quel que soit l'expéditeur et quelle que soit l'adresse IP. Pour un ESP, l'inscription d'un domaine partagé sur une DNSBL d'URI est un incident qui touche de nombreux clients.
- 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 lorsque 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 par hachage flou (rspamd)

Le hachage flou (fuzzy hashing) détecte 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 et 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 dans les scores partout.

### Comment l'empreinte est construite : les shingles

- Le texte du message est découpé en mots, puis en **séquences de trois mots qui se chevauchent (trigrammes)**, appelées « shingles ».
- Chaque shingle est haché avec **plusieurs fonctions de hachage (32 empreintes par shingle)**, et l'empreinte du message est l'ensemble de ces empreintes. (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 au message candidat et aux empreintes stockées, ce qui donne un pourcentage de correspondance plutôt qu'une égalité stricte.
- Algorithmes d'empreinte pour le texte : `mumhash` (la valeur par défaut actuelle, et recommandée), `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, au moyen d'empreintes blake2b de leur contenu. Un seul octet modifié rompt la correspondance. C'est pourquoi les campagnes de spam par images régénèrent leurs images à chaque envoi, et pourquoi les filtres combinent par ailleurs les empreintes exactes avec des empreintes perceptuelles d'images.

Principales valeurs par défaut de `fuzzy_check` : `min_bytes = 1k` (la taille minimale d'une pièce jointe ou d'une image prise 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/*`), et `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. Il utilise 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, et les domaines des liens sont normalisés en eTLD+1.

L'empreinte combinée est pondérée ainsi : shingles de structure 50 %, **domaines des appels à l'action (CTA) 30 %**, ensemble des domaines des liens 15 %, et décomptes de caractéristiques (balises et liens) 5 %. Pour éviter de correspondre à des modèles génériques, elle 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 message de 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 (l'exemple documenté : une similarité de structure de 0,9 avec des domaines de CTA non concordants donne une similarité combinée de 0,45). À l'inverse, une campagne de spam qui garde son domaine de CTA tout en remaniant son texte correspond toujours.

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

L'empreinte est un grand ensemble d'empreintes de trigrammes de mots qui se chevauchent, comparées de façon probabiliste. Par conséquent :

- **Les petites modifications** (mots échangés, noms insérés, paragraphes réordonnés) ne changent que les shingles qui chevauchent la modification. La plupart des shingles correspondent toujours, et la similarité reste au-dessus du seuil.
- **Le bourrage de jetons** (ajout de mots aléatoires, de texte masqué ou de chaînes destinées à casser les empreintes) ajoute des shingles mais ne supprime pas ceux qui correspondent. Il ne dilue que légèrement 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 même alors, 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 aussi intacte la plupart des shingles communs. 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 augmente à 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` (un seuil sur le poids de l'empreinte). En dessous du seuil, le symbole vaut 0. Le score monte ensuite du seuil jusqu'à **2× le seuil**, selon une courbe en tangente hyperbolique : ≈50 % du poids de la métrique au seuil, et le score complet à 2×. Par exemple, avec un poids de signalement de 1 et un seuil de 20, une empreinte doit recevoir ≥ 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 : le flag 1 correspond au spam confirmé (`FUZZY_DENIED`, max_score 20), le flag 2 au spam probable (`FUZZY_PROB`, max_score 10), et le flag 3 au contenu légitime placé sur liste blanche (`FUZZY_WHITE`, max_score 2). Les numéros de flag doivent être uniques parmi les règles en écriture, et `skip_hashes` place des empreintes précises sur liste blanche.
- Apprentissage : `rspamc -f <flag> -w <weight> fuzzy_add <message>` (ou `-S FUZZY_DENIED`) ajoute une empreinte, et `fuzzy_del` en supprime une. `read_only = true` rend une règle interrogeable uniquement, et une condition d'apprentissage facultative écrite en Lua peut bloquer l'apprentissage ou changer son flag.

Côté exploitation, le worker fuzzy_storage :

- a une architecture à écrivain unique, avec une file de mises à jour synchronisée sur disque tous les `sync = 1min` ;
- stocke les données dans SQLite (par défaut) ou Redis ;
- fait **expirer** les empreintes via `expire` (90d est la valeur initiale recommandée, pour que les anciennes empreintes disparaissent à mesure que les campagnes meurent) ;
- nécessite environ 400k empreintes par 100 Mo de RAM (1,5M ≈ 500 Mo) ;
- n'accepte l'apprentissage que depuis les adresses IP `allow_update` ;
- prend en charge un chiffrement facultatif du transport en Curve25519 (`encrypted_only = true`), et une réplication maître-esclave (TCP 11335) avec traduction des flags pour chaque esclave.

## Conséquences pour les expéditeurs

Ensemble, les deux mécanismes aboutissent à des 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'adresse IP d'envoi.
- **Les clients qui partagent un domaine de suivi partagent son sort.** Un domaine de suivi des clics ou d'habillage des liens utilisé dans tout un ESP réunit 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. Les parades sont des sous-domaines de suivi propres à chaque client sur des domaines qui appartiennent au client (via un CNAME), une surveillance proactive des domaines de suivi sur les DNSBL d'URI, et un contrôle des URL de destination auprès de SURBL, d'URIBL et de la DBL au moment de l'envoi.
- **Les raccourcisseurs publics font plus de mal que de bien.** Les filtres les résolvent de toute façon jusqu'à la destination, et le domaine du raccourcisseur porte la réputation accumulée de tous ceux qui en ont abusé. Voir [Contenu et design pour la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite).
- **Garder des domaines de liens propres est une tâche de surveillance continue**, et non une vérification ponctuelle. Interrogez multi.surbl.org (et la Spamhaus DBL) sur vos domaines de suivi, d'images et de pages de destination aussi souvent que vous vérifiez les listes de blocage d'IP, et vérifiez les URL de chaque campagne sortante avant de l'envoyer.
- **Les empreintes font peser les plaintes sur le reste de l'envoi.** Les quelques milliers de premiers destinataires qui signalent une campagne créent son empreinte floue et lui ajoutent du poids, et le reste du même envoi y correspond ensuite. Envoyer par segments avec des pauses (d'abord aux destinataires les plus engagés, en surveillant les premiers signaux de plaintes, puis en continuant) exploite directement la fenêtre de score entre le seuil et 2× le seuil.
- **Modifier un modèle ne remet pas à zéro la réputation de son contenu.** De petites modifications du texte, la rotation des lignes d'objet ou la personnalisation des champs de fusion laissent intacte l'empreinte par shingles (ainsi que l'empreinte de la structure HTML et des domaines de CTA). La seule vraie remise à zéro 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, et non un problème à régler en travaillant le 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](https://emailmarketing.net/fr/apprendre/reference/listes-de-blocage-et-spamhaus), sur le fonctionnement des DNSBL d'adresses IP et de domaines, dont la Spamhaus DBL et HBL, les autres grands jeux de données de réputation des domaines
- [Contenu et design pour la délivrabilité](https://emailmarketing.net/fr/apprendre/operations/contenu-et-design-pour-la-delivrabilite), avec les règles pratiques de contenu (raccourcisseurs, images, liens) que ces mécanismes expliquent
- [Surveillance de la réputation](https://emailmarketing.net/fr/apprendre/operations/surveillance-et-retablissement-de-la-reputation), sur la place des vérifications des domaines de suivi et de liens sur les DNSBL d'URI dans un programme de surveillance