Feedback loops de plaintes (RFC 6449)

Quand un destinataire clique sur « Signaler comme spam » dans votre message, une feedback loop (FBL) peut vous envoyer un rapport de cette plainte, pour que vous cessiez d’écrire à cette personne et que vous compreniez ce qui n’a pas fonctionné. Les plaintes sont l’un des principaux signaux de réputation que mesurent les fournisseurs de messagerie (voir Fondamentaux de la délivrabilité des emails), et une FBL vous donne un accès direct à ce signal.

La RFC 6449, « Complaint Feedback Loop Operational Recommendations », décrit comment les fournisseurs de messagerie transmettent ces plaintes aux expéditeurs. Son objectif déclaré est de « fournir aux consommateurs de feedback les informations nécessaires pour réduire le spam ou la perception de spam ».

Terminologie

Comment une plainte devient un rapport

1. L’utilisateur clique sur « Signaler comme spam » (Report Spam) dans l’interface webmail ou dans le client de messagerie du fournisseur. Si le fournisseur ne propose pas un tel bouton, une FBL efficace est pratiquement impossible.
2. Le fournisseur rattache le message à un consommateur de feedback inscrit. Il utilise traditionnellement l’adresse IP du dernier saut qui lui a remis le message, et de plus en plus souvent le domaine DKIM d=.
3. Un rapport ARF est généré et envoyé immédiatement, sans examen, si bien que le consommateur le reçoit presque en temps réel.

Routage des FBL par domaine DKIM ou par adresse IP

Une même valeur DKIM d= peut couvrir de nombreux serveurs et adresses IP, et vous pouvez ajouter ou retirer des serveurs sans modifier l’inscription à la FBL (« lorsqu’une feedback loop utilise DKIM, aucune reconfiguration n’est nécessaire, car le domaine signataire ne change pas »). Les FBL fondées sur les adresses IP doivent être mises à jour à chaque modification de l’infrastructure d’envoi. Privilégiez l’inscription par domaine DKIM lorsque le fournisseur la propose. Elle se combine aussi naturellement avec l’alignement DMARC et avec des domaines de signature distincts pour chaque flux (voir Segmentation et allocation avancées des adresses IP).

Le fonctionnement de l’inscription, selon la page de ressources FBL du M3AAWG : l’inscription par domaine exige que le courrier soit signé avec DKIM, et demande à la fois le domaine signataire (la valeur d=) et le sélecteur (la valeur s=) de la signature DKIM. Le sélecteur utilisé sur le courrier de production doit donc être connu et stable au moment de l’inscription.

Les FBL agrégées fonctionnent différemment. Elles totalisent les nombres de plaintes par adresse IP, par domaine ou par un identifiant choisi par l’expéditeur, qui est le modèle que Gmail met en œuvre avec l’en-tête Feedback-ID (voir Google Postmaster Tools). L’annuaire des pages d’inscription de chaque fournisseur est tenu à jour dans Index des documents M3AAWG et écosystème des FBL. La plupart des FBL traditionnelles passent par la Universal Feedback Loop de Validity, sur fbl.validity.com.

Structure d’un rapport ARF (RFC 5965)

Un message ARF est un message MIME multipart/report en trois parties :

Comme l’adresse du destinataire est souvent caviardée, les expéditeurs ne peuvent pas se fier à l’adresse To: du message renvoyé pour identifier qui s’est plaint (voir Automatisation ci-dessous).

Recommandations pour les fournisseurs de feedback (fournisseurs de messagerie)

• Candidature et contrôle : gardez la procédure de candidature simple, et vérifiez que le candidat est habilité pour les adresses IP ou les domaines qu’il revendique. Vérifiez la propriété des adresses IP par l’ASN d’origine, les enregistrements WHOIS ou RWHOIS et le DNS inverse. Vérifiez les contacts par un message de confirmation envoyé à abuse@ ou à postmaster@.
• Refus : vous pouvez refuser une candidature lorsque le candidat semble s’inscrire sous un faux prétexte pour contourner les politiques de livraison, ou qu’il est déjà bloqué pour mauvaise réputation. Maintenez une procédure de recours documentée et transparente.
• Contenu des rapports : incluez une adresse de contact pour les questions (idéalement une adresse reliée à un système de tickets). Vous pouvez aussi inclure des statistiques de livraison résumées (volume, taux de placement en boîte de réception, adresses pièges touchées).
• Maintenance continue : revérifiez régulièrement les consommateurs inscrits au regard des critères en vigueur, et vérifiez que les adresses qui reçoivent les rapports fonctionnent toujours.
• Vie privée : les données des rapports ne doivent pas être transmises au-delà du destinataire approuvé, et tout usage abusif justifie une résiliation immédiate. Les FBL franchissent les frontières, si bien que c’est le droit local de la protection des données qui détermine ce qui peut être caviardé ou partagé. L’adresse email et l’adresse IP du destinataire qui a signalé le message sont les éléments habituellement caviardés.
• Les conditions d’utilisation devraient préciser les obligations de confidentialité, l’obligation de tenir les contacts à jour, le fait que l’accès à une FBL n’accorde aucun privilège d’envoi particulier, et le fait que l’inscription est un privilège qui peut être retiré à tout moment et pour tout motif.
• Les FBL non sollicitées (l’envoi de rapports à des expéditeurs qui ne se sont pas inscrits) restent débattues. Si vous en envoyez, ne les envoyez qu’à des fournisseurs de messagerie ou d’accès, seulement après avoir tenté un contact normal, et uniquement aux adresses abuse publiées dans le WHOIS. Des consommateurs qui ne sont pas préparés peuvent être incapables de gérer le volume ou le format.

Recommandations pour les expéditeurs (consommateurs de feedback)

Avant l’inscription

• Des adresses de rôle qui fonctionnent : abuse@, postmaster@.
• Une adresse dédiée à la réception des rapports de FBL.
• La preuve que vous êtes propriétaire de vos adresses IP : un DNS inverse et des enregistrements WHOIS corrects.
• Des contacts nommés et des points d’escalade.

Traiter chaque plainte

• Traitez une plainte comme un désabonnement. Assurez-vous qu’aucun autre message de cette liste n’atteint ce destinataire : retirez l’adresse, ou ajoutez-la à la liste de suppression.
• L’étendue de la suppression relève du discernement, et l’objectif est de réduire les plaintes futures. Placer l’adresse en suppression pour tout un ESP est probablement trop large. La placer en suppression sur toutes les listes segmentées d’un même client est probablement le bon niveau.
• L’exception transactionnelle : la bonne décision est parfois d’ignorer le rapport. Par exemple, un client qui signale ses propres billets d’avion comme spam a toujours besoin des billets restants. Placez en suppression le courrier marketing, pas le flux transactionnel (c’est une raison de garder le courrier transactionnel séparé ; voir Segmentation et allocation avancées des adresses IP).

Mesurer correctement le taux de plaintes

La RFC 6449 signale plusieurs pièges de calcul :

• Le jour de lecture, pas le jour d’envoi : les plaintes sont comptées le jour où l’utilisateur a lu le message. Un expéditeur qui envoie du lundi au vendredi voit un « taux » gonflé le samedi, car les plaintes sont divisées par un nombre d’envois minuscule, voire nul.
• La boîte de réception comme dénominateur : les fournisseurs divisent généralement les plaintes par le nombre de messages livrés en boîte de réception, et non par le nombre de messages envoyés. Pour un expéditeur dont 500 messages sur 10 000 arrivent en boîte de réception (9 500 dans le dossier spam), les plaintes sont divisées par 500. Une mauvaise réputation dégrade donc encore davantage le taux mesuré.
• La RFC donne un ordre de grandeur : 10 rapports par jour peuvent signaler de graves problèmes chez un petit expéditeur, mais être un bruit de fond normal chez un expéditeur qui envoie 300 000 messages par mois. Elle cite un taux de plaintes de 2 % comme pouvant justifier un blocage immédiat. Les seuils actuels des fournisseurs sont bien plus stricts : Gmail demande moins de 0,1 %.
• Suivez les tendances, pas seulement les nombres. Les FAI devraient suivre chaque jour les plaintes par client ou par adresse IP, car un pic soudain suggère l’inscription d’un spammeur ou un système compromis. Les ESP devraient ventiler les plaintes par client, par liste et par campagne, et utiliser le taux (les plaintes divisées par les messages envoyés) plutôt que des nombres absolus.

Automatisation

• Les petits consommateurs (listes de quelques milliers d’adresses) n’ont besoin que de peu ou pas d’automatisation, car les rapports ARF se lisent dans un client de messagerie. Un filtre simple qui ajoute l’adresse IP signalée à la ligne d’objet rend les tendances visibles quand vous triez.
• Les grands consommateurs doivent extraire de chaque rapport le destinataire qui s’est plaint, le fournisseur de messagerie qui a envoyé le rapport, le client responsable (pour les ESP), les identifiants de campagne et de liste, et éventuellement l’adresse IP source et le DKIM d=.
• Comme l’adresse du destinataire est souvent caviardée, placez les identifiants du destinataire et de la campagne dans le message lui-même, à un endroit que le traitement des FBL ne supprimera pas. Les options sont des clés primaires de base de données (opaques, mais il faut un accès à la base), des valeurs chiffrées (il faut un déchiffrement automatisé), ou un encodage dans le Message-ID. Par exemple, esp-423-27-42460@example.com est opaque pour les tiers, mais l’expéditeur peut l’analyser.
• Réutilisez la chaîne de traitement des rebonds. Si l’identifiant se convertit au même format que la chaîne VERP utilisée pour le traitement des rebonds, le processeur de FBL peut créer un « faux » rebond définitif et le transmettre au processeur de rebonds existant, qui place l’adresse en suppression (voir Delivery Status Notifications).
• Les FAI qui consomment des rapports ont surtout besoin de l’adresse IP source et du client responsable. L’adresse IP figure généralement dans les métadonnées ARF, et sinon dans les en-têtes Received.

Sécurité

Le fournisseur doit s’assurer que les rapports ne sont envoyés qu’aux consommateurs autorisés, et doit établir l’identité de l’expéditeur à partir de l’adresse IP qui se connecte ou du domaine de signature DKIM, « deux éléments difficiles à falsifier ». Cela empêche les spammeurs de s’inscrire pour des réseaux qui ne leur appartiennent pas afin de récolter des adresses et des données privées dans les rapports.

Voir aussi

• List-Unsubscribe et désabonnement en un clic, qui permet aux utilisateurs de quitter une liste plutôt que de se plaindre
• Fondamentaux de la délivrabilité des emails