Backscatter et BATV

Si votre domaine reçoit des rebonds pour des messages qu’il n’a jamais envoyés, ou si vos propres serveurs ont été inscrits sur une liste pour avoir envoyé de tels rebonds, vous avez affaire au backscatter. Un ESP y est confronté des deux côtés : ses MTA ne doivent pas en générer, et ses domaines de retour en reçoivent des flots.

Le backscatter désigne le trafic de rebonds livré à des personnes qui n’ont jamais envoyé le message d’origine. Il comprend les notifications d’état de livraison (DSN) et, par extension, les réponses automatiques et les messages de défi. 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 personne dont l’adresse a été usurpée. À l’échelle d’une campagne de spam, un domaine innocent peut recevoir un flot de rapports de non-livraison (NDR) mal dirigés, et les systèmes qui envoient ces rebonds se retrouvent sur des listes de blocage en tant que sources de backscatter.

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 pratique admise en découle :

• Rejetez pendant la transaction SMTP (avec un 5xx) 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 une adresse MAIL FROM usurpée ne reçoit rien. Tout verdict que vous pouvez établir avant la fin de DATA, qu’il porte sur un destinataire inconnu, la politique, la taille ou le contenu, devrait être un rejet pendant la session.
• Accepter puis renvoyer un rebond consiste à répondre 250, puis à générer plus tard une DSN vers l’adresse MAIL FROM. Cela crée un nouveau message destiné à une adresse que personne n’a vérifiée, et pour du courrier usurpé, cette DSN est du backscatter. Les causes habituelles sont les passerelles et les relais de stockage et retransmission qui acceptent le courrier 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.
• Plusieurs règles en découlent. Validez les destinataires en bordure (par une vérification en temps réel auprès du serveur en aval, ou par une liste de destinataires synchronisée). Si vous devez traiter du spam après acceptation, supprimez-le ou mettez-le en quarantaine, et ne renvoyez jamais de rebond. Ne répondez jamais automatiquement à un courrier qui échoue à l’authentification. Toute DSN que vous générez légitimement utilise toujours MAIL FROM:<> (voir DSN).

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

• La zone est ips.backscatterer.org. Elle liste les adresses 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 de vérification de l’adresse de l’expéditeur (SAV) 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 qui ressemble à des rebonds, car les adresses IP listées envoient aussi beaucoup de courrier légitime. Les sites qui l’interrogent pour tout le courrier causent les dommages collatéraux contre lesquels ses 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), et il existe une option payante de « retrait de liste express », une pratique controversée. Les détails sur l’expiration et le tarif ne figuraient pas sur la page d’utilisation consultée comme source. Ils sont indiqués ici d’après la politique largement documentée de l’opérateur, donc vérifiez les conditions en vigueur avant de conseiller à quiconque de payer un retrait de liste. La correction 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.
• Une inscription a un impact pratique limité, puisque peu de grands fournisseurs utilisent la zone, et seulement en safe mode. C’est tout de même un signe fiable que votre infrastructure est mal configurée.

BATV : Bounce Address Tag Validation

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

Méta-syntaxe et schéma prvs=

La forme d’une partie locale marquée :

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

Le seul schéma défini est prvs (« private signature », avec une 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)

• L’entrée du HMAC est K DDD <original MAIL FROM address>, avec pour clé un secret que partagent 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 du domaine de gestion administrative (ADMD). Ils ne marquent jamais 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 qui ressemble à des rebonds), vérifient le HMAC et contrôlent que le compteur de jours est dans la fenêtre. Le draft impose une durée de vie de 7 jours, pour tenir compte des rebonds retardés. Si la marque est valide, le MTA la retire (tout jusqu’au second = inclus) et livre à loc-core. Si un rebond porte une marque invalide ou n’en porte pas, le MTA le rejette pendant la session SMTP.
• La méta-syntaxe autorise d’autres schémas, notamment un « marquage public » à clés publiques que des tiers pourraient vérifier. Seul prvs a jamais été défini et déployé.

Ce que BATV apporte à un ESP

• Il arrête les flots de faux rebonds. Une DSN adressée à votre domaine de retour sans marque, ou avec une mauvaise marque, n’est de façon prouvée pas une réponse à votre courrier, donc vous pouvez la rejeter. Cela protège le traitement des rebonds contre l’empoisonnement (de faux rebonds qui suppriment de bonnes adresses) et contre les flots de volume.
• Il n’offre qu’une protection faible contre le rejeu, et c’est voulu, comme le dit le draft lui-même. Le HMAC est tronqué à 6 chiffres hexadécimaux et la fenêtre est de 7 jours, ce qui empêche de deviner, mais pas le rejeu déterminé d’une adresse marquée récemment collectée. Il ne protège pas contre une modification du contenu, et la protection n’existe qu’au domaine de livraison (car la clé est 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 (une adresse de retour encodée pour chaque 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é.

Cette approche, le VERP signé et validé, est ce qu’utilisent en réalité la plupart des grands ESP au lieu du marquage prvs= littéral. Elle valide les rebonds par rapport aux envois sortants et identifie le destinataire et la campagne exacts. Elle évite aussi les problèmes que BATV pose aux listes de diffusion et aux listes blanches, car le domaine de retour est un domaine de rebond dédié avec lequel aucune personne ne correspond.

Pratique actuelle

1. N’envoyez jamais de backscatter. Rejetez pendant la session SMTP, supprimez le spam détecté après acceptation, ne faites pas de vérification SAV par rappel, et n’envoyez de DSN que depuis <>.
2. Validez les rebonds entrants par rapport à vos propres envois, avec du VERP signé (ou BATV lorsque tout le courrier du domaine passe par un seul ADMD). Supprimez tout ce qui ne peut pas être vérifié à une adresse de rebond avant que cela n’atteigne votre logique de suppression d’adresses.
3. L’authentification réduit l’offre d’usurpations. À mesure que davantage de domaines appliquent DMARC, moins de courrier usurpé est accepté au départ, donc moins de backscatter est généré vers ces domaines.
4. La correction structurelle est en cours d’élaboration. 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. Il en est encore au stade de draft, donc ne comptez pas encore dessus.
5. Si vous êtes inscrit 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 l’inscription comme un avertissement sur votre configuration plutôt que comme une urgence de délivrabilité.

Voir aussi

• Delivery Status Notifications, notamment la règle de l’expéditeur nul et l’analyse de VERP
• Listes de blocage et Spamhaus
• DKIM2, sur le routage authentifié des rebonds