Backscatter et BATV

Le backscatter désigne le trafic de rebonds (DSN et, par extension, réponses automatiques et messages de défi) livré à des personnes qui n’ont jamais envoyé le message d’origine. Les spammeurs et les virus inscrivent de vraies adresses usurpées dans le MAIL FROM ; quand le spam ne peut pas être livré, le rebond part vers la victime de l’usurpation. À l’échelle d’une campagne, un domaine innocent peut recevoir un flot de NDR mal dirigés, et les systèmes qui émettent ces rebonds se retrouvent sur des listes de blocage en tant que sources de backscatter. Un ESP est des deux côtés : ses MTA ne doivent pas générer de backscatter, et ses domaines de retour encaissent des flots de faux rebonds.

La cause : accepter puis renvoyer un rebond

Un rebond n’est mal dirigé que s’il est généré après la fin de la transaction SMTP. La doctrine :

• Rejetez pendant la session SMTP (5xx pendant la transaction) chaque fois que c’est possible. Un rejet est renvoyé dans la connexion en cours, à l’hôte qui a réellement soumis le message ; aucun nouveau message n’est créé, donc un MAIL FROM usurpé ne reçoit rien. Les verdicts sur les destinataires inconnus, la politique, la taille et le contenu que vous pouvez établir avant la fin de DATA devraient tous être des rejets synchrones.
• Accepter puis renvoyer un rebond (répondre 250, puis générer plus tard une DSN vers le MAIL FROM) crée un nouveau message destiné à une adresse non vérifiée. Pour du courrier usurpé, cette DSN est du backscatter. Coupables habituels : les passerelles et relais de stockage et retransmission qui acceptent pour des serveurs en aval sans connaître la liste des destinataires valides (« tout accepter, renvoyer les rebonds plus tard »), les filtres antispam et antivirus appliqués après acceptation et configurés pour « avertir l’expéditeur », et les systèmes de défi-réponse.
• Corollaires : validez les destinataires en bordure (vérification en temps réel auprès du serveur en aval, ou liste de destinataires synchronisée) ; si vous devez mettre de côté du spam après acceptation, supprimez-le ou mettez-le en quarantaine, ne renvoyez jamais de rebond ; ne répondez jamais automatiquement à un courrier qui échoue à l’authentification ; et les DSN que vous générez légitimement utilisent toujours MAIL FROM:<> (voir DSN).

Inscription sur une liste de blocage pour backscatter (Backscatterer.org / UCEPROTECT)

• Zone : ips.backscatterer.org. Elle liste les IP observées en train d’envoyer des rebonds mal dirigés, des réponses automatiques mal dirigées et des vérifications d’expéditeur par rappel (les sondes SAV, « sender address verification », sont elles aussi considérées comme un abus).
• Ce n’est explicitement pas une liste de spam (« C’est une liste de Backscatterer !!! »). L’usage recommandé est le SAFE MODE : ne l’interroger que lorsque MAIL FROM vaut <> ou postmaster, c’est-à-dire uniquement pour filtrer du trafic ayant la forme d’un rebond, car les IP listées émettent aussi beaucoup de courrier légitime. (Les sites qui l’interrogent pour tout le courrier causent les dommages collatéraux contre lesquels les opérateurs mettent en garde.)
• Historiquement, les inscriptions expirent d’elles-mêmes après une période sans nouvelle détection (environ quatre semaines), avec une option payante de « retrait de liste express », pratique controversée. Note sur la provenance : les détails sur l’expiration et le tarif ne figuraient pas sur la page d’utilisation consultée et sont indiqués ici d’après la politique largement documentée de l’opérateur ; vérifiez les conditions en vigueur avant de conseiller une dépense pour un retrait de liste. La correction opérationnelle est toujours la même : trouver et arrêter le comportement d’acceptation suivie d’un rebond ou de vérification par rappel, puis laisser l’inscription expirer.
• L’impact pratique d’une inscription est limité (peu de grands fournisseurs utilisent la zone, et seulement en safe mode), mais c’est un symptôme fiable d’une infrastructure mal configurée.

BATV : Bounce Address Tag Validation

BATV permet à un domaine de distinguer les rebonds concernant du courrier qu’il a réellement envoyé des rebonds concernant des usurpations, en signant les parties locales de ses propres MAIL FROM. Spécifié dans draft-levine-smtp-batv-01 (Levine, Crocker, Silberman, Finch ; 2008-05-13, expiré le 2008-11-14 ; jamais publié en RFC, mais déployé depuis dans de nombreux MTA et appliances).

Méta-syntaxe et schéma prvs=

Forme de la partie locale marquée :

local-part = tag-type "=" tag-val "=" loc-core

Le schéma défini est prvs (« private signature », signature par clé privée simple) :

prvs=KDDDSSSSSS=jsmith@example.com
        │ │  └── SSSSSS : 3 premiers octets (6 chiffres hexadécimaux) d'un HMAC-SHA1
        │ └───── DDD : 3 derniers chiffres du nombre de jours depuis 1970 (ancre d'expiration)
        └─────── K : un chiffre de numéro de clé (rotation)

• Entrée du HMAC : K DDD <original MAIL FROM address>, avec pour clé un secret partagé par les signataires sortants et les validateurs entrants du domaine.
• Les MTA sortants réécrivent MAIL FROM:<jsmith@example.com> sous la forme marquée à la frontière de l’ADMD (sans jamais marquer à nouveau les adresses d’autres domaines). L’en-tête From: du message n’est pas modifié : BATV n’agit que sur l’enveloppe.
• Les MTA entrants, pour le courrier adressé à une partie locale prvs= (en pratique, du trafic ayant la forme d’un rebond), vérifient le HMAC et la fenêtre du compteur de jours ; le draft impose une durée de vie de 7 jours pour tenir compte des rebonds retardés. Valide → retirer la marque (tout jusqu’au second = inclus) et livrer à loc-core. Marque invalide ou absente sur un rebond → rejet pendant la session SMTP.
• La méta-syntaxe autorise d’autres schémas, notamment un « marquage public » à clé publique vérifiable par des tiers ; seul prvs a jamais été défini et déployé.

Ce que BATV apporte à un ESP

• Il neutralise les flots de faux rebonds : une DSN non marquée ou mal marquée adressée à votre domaine de retour n’est, de façon prouvée, pas une réponse à votre courrier ; rejetez-la. Cela protège les chaînes de traitement des rebonds contre l’empoisonnement (de faux rebonds qui suppriment de bonnes adresses) et contre les flots de volume.
• Protection faible contre le rejeu seulement (c’est voulu, le draft le dit) : le HMAC tronqué à 6 chiffres hexadécimaux et la fenêtre de 7 jours empêchent de deviner, mais pas le rejeu déterminé d’une adresse marquée récemment collectée ; aucune protection contre la substitution de contenu ; la protection n’existe qu’au domaine de livraison (clé privée), pas le long du chemin.

Problèmes opérationnels (d’après les considérations de déploiement du draft)

BATV et VERP : complémentaires, et largement convergents

Un ESP qui utilise déjà VERP (adresses de retour encodées par destinataire, par exemple bounce-c123-user=example.com@bounces.esp.com) obtient l’essentiel du bénéfice de BATV si le jeton VERP contient un HMAC : tout « rebond » entrant dont la partie locale ne se décode pas en un envoi sortant réel est rejeté ou supprimé. Ce VERP signé et validé est ce qu’utilisent en réalité la plupart des grands ESP au lieu du marquage prvs= littéral : il valide les rebonds par rapport aux envois sortants, identifie le destinataire et la campagne exacts, et évite la casse de BATV sur les listes et les listes blanches, car le domaine de retour est un domaine de rebond dédié avec lequel aucun humain ne correspond.

Position moderne

1. Ne jamais émettre de backscatter : rejeter pendant la session SMTP ; supprimer le spam détecté après acceptation ; pas de vérification SAV par rappel ; DSN uniquement depuis <>.
2. Valider les rebonds entrants par rapport à vos propres envois : VERP signé (ou BATV lorsque tout le courrier du domaine passe par un seul ADMD) ; tout ce qui ne peut pas être vérifié à une adresse de rebond est supprimé avant d’atteindre la logique de suppression d’adresses.
3. L’authentification réduit la matière première des usurpations : l’application généralisée de DMARC fait que moins de courrier usurpé est accepté au départ, donc moins de backscatter est généré vers les domaines qui appliquent une politique.
4. La correction structurelle est en cours : DKIM2 renvoie les DSN saut par saut le long d’une chaîne de responsabilité authentifiée, ce qui rend les rebonds mal dirigés impossibles pour le courrier participant ; c’est l’un de ses objectifs de conception explicites. Encore au stade de draft ; ne comptez pas encore dessus.
5. En cas d’inscription sur ips.backscatterer.org : auditez les chemins d’acceptation suivie d’un rebond et les vérifications par rappel, corrigez la source, puis attendez l’expiration de l’inscription ; traitez-la comme un détecteur de fumée de configuration plutôt que comme une urgence de délivrabilité.

Voir aussi

• Delivery Status Notifications : la règle de l’expéditeur nul et l’analyse de VERP
• Listes de blocage et Spamhaus : la mécanique des DNSBL en général
• DKIM2 : le routage authentifié des rebonds (en cours)