Feedback loops de plaintes (RFC 6449)

La RFC 6449 (« Complaint Feedback Loop Operational Recommendations ») décrit comment les fournisseurs de messagerie renvoient aux expéditeurs les plaintes pour spam des utilisateurs finaux. Son objectif déclaré : « fournir aux consommateurs de feedback les informations nécessaires pour réduire le spam ou la perception de spam ».

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) ; une FBL est l’accès direct de l’expéditeur à ce signal.

Terminologie

Comment une plainte devient un rapport

1. L’utilisateur clique sur « Signaler comme spam » (Report Spam) dans l’interface webmail ou 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 : traditionnellement par l’adresse IP du dernier saut qui lui a remis le message ; de plus en plus par le domaine DKIM d=.
3. Un rapport ARF est généré et envoyé immédiatement, sans examen : le consommateur le reçoit quasiment en temps réel.

Routage des FBL par DKIM ou par IP

Une même valeur DKIM d= peut couvrir de nombreux serveurs et IP ; on peut ajouter ou retirer des serveurs sans toucher à 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 l’IP doivent être mises à jour à chaque modification de l’infrastructure d’envoi. Privilégiez l’inscription par DKIM lorsque le fournisseur la propose ; elle se combine aussi naturellement avec l’alignement DMARC et des domaines de signature par flux (voir Segmentation et allocation avancées des adresses IP).

Mécanique d’inscription (selon la page de ressources FBL du M3AAWG) : l’inscription par domaine exige que le courrier soit signé 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, à l’inverse, consolident des nombres de plaintes par IP, par domaine ou par un identifiant choisi par l’expéditeur (le modèle que Gmail met en œuvre avec l’en-tête Feedback-ID : voir Google Postmaster Tools). L’annuaire des inscriptions par fournisseur (la plupart des FBL traditionnelles passent par la Universal Feedback Loop de Validity, sur fbl.validity.com) est tenu à jour dans Index des documents M3AAWG et écosystème des FBL.

Structure d’un rapport ARF (RFC 5965)

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

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

Recommandations pour les fournisseurs de feedback (fournisseurs de messagerie)

• Candidature et contrôle : procédure de candidature simplifiée ; vérifier que le candidat est habilité pour les IP et domaines revendiqués. Recouper la propriété des IP par l’ASN d’origine, WHOIS/RWHOIS et le DNS inverse ; vérifier les contacts par un email de confirmation envoyé à abuse@/postmaster@.
• Refus : une candidature peut être refusée lorsque le demandeur semble chercher à contourner les politiques de livraison par une inscription fictive, ou qu’il est déjà bloqué pour mauvaise réputation. Maintenir une procédure de recours documentée et transparente.
• Contenu des rapports : inclure une adresse de contact pour les questions (idéalement reliée à un système de tickets) ; inclure éventuellement des statistiques de livraison résumées (volume, taux de placement en boîte de réception, adresses pièges touchées).
• Maintenance : revalider régulièrement les consommateurs inscrits selon les critères en vigueur, et vérifier que les adresses de réception des rapports fonctionnent toujours.
• Vie privée : les données des rapports ne doivent pas être transmises au-delà du destinataire approuvé ; tout usage abusif justifie une résiliation immédiate. Les FBL franchissent les frontières : 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’IP du destinataire ou de l’auteur du signalement sont les cibles habituelles du caviardage.
• Les conditions d’utilisation devraient préciser : les obligations de confidentialité, l’obligation de tenir les contacts à jour, le fait que l’accès à la FBL n’accorde aucun privilège d’envoi particulier, et que l’inscription est un privilège révocable à tout moment et pour tout motif.
• Les FBL non sollicitées (envoi de rapports à des expéditeurs non inscrits) restent débattues ; si elles sont pratiquées, ce ne devrait être qu’envers des fournisseurs de messagerie ou d’accès, après avoir tenté un contact normal, et uniquement vers les adresses abuse publiées dans le WHOIS : des consommateurs non 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 fonctionnelles : abuse@, postmaster@.
• Une adresse dédiée à la réception des rapports de FBL.
• Une propriété des IP démontrable : DNS inverse et 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, en retirant l’adresse ou en l’ajoutant à la liste de suppression.
• La portée de la suppression relève du discernement, avec pour objectif de réduire les plaintes futures : supprimer l’adresse pour tout un ESP est probablement trop large ; la supprimer de toutes les listes segmentées d’un même client est probablement le bon niveau.
• 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. Supprimez le marketing, pas le flux transactionnel (une raison d’isoler le courrier transactionnel : voir Segmentation et allocation avancées des adresses IP).

Mesurer correctement le taux de plaintes

La RFC 6449 signale plusieurs pièges de calcul :

• Jour de lecture ou jour d’envoi : les plaintes sont comptées le jour où l’utilisateur a lu le message, pas le jour où il a été envoyé. Un expéditeur qui envoie du lundi au vendredi voit un « taux » du samedi gonflé : des plaintes divisées par un nombre d’envois minuscule (voire nul).
• Effet du dénominateur boîte de réception : 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 encore davantage le taux mesuré.
• Ordres de grandeur donnés par la RFC : 10 rapports par jour peuvent signaler de graves problèmes chez un petit expéditeur, mais être un bruit de fond normal pour un expéditeur qui envoie 300 000 messages par mois ; un taux de plaintes de 2 % est cité comme pouvant justifier un blocage immédiat. (Les seuils actuels des fournisseurs sont bien plus stricts : Gmail demande moins de 0,1 %.)
• Suivez la tendance, ne vous contentez pas de compter : les FAI devraient suivre les plaintes par client ou par IP et par jour ; 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 un taux (plaintes ÷ envois) plutôt que des nombres absolus.

Automatisation

• Petits consommateurs (listes de quelques milliers d’adresses) : peu ou pas d’automatisation nécessaire ; les rapports ARF se lisent dans un client de messagerie. Un filtre léger qui ajoute l’IP signalée à l’objet rend les tendances visibles par simple tri.
• Grands consommateurs : doivent extraire de chaque rapport le destinataire plaignant, le fournisseur de messagerie d’origine, le client responsable (pour les ESP), les identifiants de campagne et de liste, et éventuellement l’IP source et le DKIM d=.
• Comme l’adresse du destinataire est souvent caviardée, intégrez les identifiants du destinataire et de la campagne dans le message lui-même, à un endroit que le traitement des FBL ne supprimera pas. Options : clés primaires de base de données (opaques mais nécessitent un accès à la base), blobs chiffrés (nécessitent un déchiffrement automatisé), ou encodage dans le Message-ID : par exemple esp-423-27-42460@example.com est opaque pour les tiers mais analysable par l’expéditeur.
• 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 synthétiser un « faux » rebond définitif et le passer au processeur de rebonds existant pour supprimer l’adresse (voir Delivery Status Notifications).
• Les consommateurs de type FAI ont surtout besoin de l’IP source et du client responsable ; l’IP figure généralement dans les métadonnées ARF, 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, l’identité de l’expéditeur étant établie à partir de l’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 : le mécanisme qui permet aux utilisateurs de quitter une liste au lieu de se plaindre.
• Fondamentaux de la délivrabilité des emails : la place du taux de plaintes parmi les signaux de réputation.