Backscatter
Le backscatter est le phénomène de pollution d'inboxes par des défis (challenge-response) ou des bounces (NDR) envoyés à des adresses email qui n'avaient pas en réalité émis le mail initial — parce que celui-ci était usurpé.
Scénario type
- Un spammeur envoie un mail à alice@example.fr en se faisant passer pour bob@victime.fr (usurpation `From:`).
- Le serveur d'Alice ne reconnaît pas l'expéditeur → met en quarantaine + envoie un défi à bob@victime.fr.
- Le vrai Bob, qui n'a rien envoyé, reçoit un défi parlant d'un mail mystérieux à Alice. Confusion et frustration.
- Pire : si Bob a beaucoup d'usurpations, sa boîte est inondée de défis pour des mails qu'il n'a pas envoyés.
Conséquences
- Blacklist du domaine émetteur du défi par les anti-spam des serveurs qui reçoivent ces défis non sollicités.
- Perte de réputation IP du serveur émetteur de défis.
- Frustration utilisateur sur les vraies victimes d'usurpation.
- Pollution de l'écosystème mail au sens large.
Pourquoi le défi-réponse historique a mauvaise presse
Dans les années 2000, les premiers anti-spam à défi-réponse (TMDA, Spamarrest premier-gen) ne vérifiaient pas SPF/DMARC. Ils généraient massivement du backscatter. C'est de là que vient la critique « le défi-réponse, c'est lourd et ça pollue ». La critique était valide pour ces implémentations naïves.
Comment FrozenSpam bloque le backscatter
FrozenSpam vérifie SPF et DMARC du domaine de l'expéditeur AVANT de décider d'envoyer un défi. La logique :
- Si SPF passe → envoie le défi (l'expéditeur est probablement vrai)
- Si SPF échoue ou si DMARC est en `p=reject` et rate l'alignement → drop silencieux. Aucun défi envoyé. Le mail disparaît.
C'est la couche 4 de FrozenSpam, le « backscatter guard ». Conséquence pratique : FrozenSpam n'envoie jamais de défi à une adresse usurpée. Pas de pollution, pas de blacklist.