emailmarketing.net

Documents M3AAWG pour les expéditeurs et les ESP : index commenté

Ce que le M3AAWG publie d’autre pour les expéditeurs et les ESP, ainsi que l’écosystème des feedback loops : types de formats FBL et liste des points d’inscription aux FBL par fournisseur.

Référence5 min de lecture

À qui cela s’adresse Opérateurs ESP, Expéditeurs

S’applique aux expéditeurs, quelle que soit leur plateforme

Le Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) tient une page « Documents for Senders and ESPs » et une page de ressources sur les feedback loops. Deux de ces documents sont résumés intégralement dans cette base de connaissances :

Cet index recense les autres, pour que la base de connaissances sache ce qui existe et où le trouver.

Documents listés sur la page destinée aux expéditeurs et aux ESP

Document Date Contenu URL
Trust in Email Begins with Authentication févr. 2015 Livre blanc expliquant pourquoi et comment l’authentification des emails (SPF, DKIM, DMARC) établit la confiance ; lecture de fond sur laquelle s’appuie le BCP Authentication de 2020. https://www.m3aawg.org/sites/default/files/doc_files/M3AAWG_Email_Authentication_Update-2015.pdf
M3AAWG Sender Best Common Practices v3.0 févr. 2015 Le BCP destiné aux expéditeurs, résumé dans m3aawg-senders-bcp.md. https://www.m3aawg.org/sites/default/files/doc_files/M3AAWG_Senders_BCP_Ver3-2015-02.pdf
M3AAWG Position on Email Appending sept. 2019 Prise de position : l’enrichissement de fichiers (rapprocher des fiches clients d’adresses email que le titulaire n’a jamais fournies ni consenties) est une violation directe des valeurs fondamentales du M³AAWG : abusif, générateur de plaintes, et source de risque juridique au regard de la vie privée et des lois anti-spam. https://www.m3aawg.org/sites/default/files/legacy/m3aawg_apending_position_update-2019-01.pdf
M3AAWG Vetting Best Common Practices nov. 2011 Guide approfondi du contrôle des clients pour les ESP : contrôle avant envoi pour repérer les expéditeurs malveillants avant qu’ils n’envoient, et surveillance après envoi (le BCP destiné aux expéditeurs rend les deux obligatoires). https://www.m3aawg.org/sites/default/files/doc_files/MAAWG_Vetting_BCP_2011-11.pdf
M3AAWG Complaint Feedback Loop BCP août 2010, remplacé en nov. 2011 Remplacé par la RFC 6449, Complaint Feedback Loop Operational Recommendations, la norme opérationnelle pour exploiter et consommer des FBL. https://tools.ietf.org/html/rfc6449
Best Current Practices for Building and Operating a Spam Trap août 2016 Comment les réseaux d’adresses pièges sont construits et exploités ; utile aux expéditeurs pour comprendre comment les opérateurs se procurent les adresses (pièges recyclés ou pièges vierges) et pourquoi toucher des pièges nuit à la réputation. https://www.m3aawg.org/sites/default/files/legacy/m3aawg-spamtrap-operations-bcp-2016-08.pdf

Autres documents du M³AAWG cités dans les deux BCP résumés (même catalogue, absents de la page d’accueil) :

Document Contenu URL
Best Practices for Managing SPF Records (2017-08) Gestion complète des enregistrements SPF, y compris le respect des limites de requêtes DNS de la RFC 7208. https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf
DKIM Key Rotation BCP (2019-03) Comment et à quelle fréquence faire tourner les clés DKIM. https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf
Best Practices for Implementing DKIM To Avoid Key Length Vulnerability (2017-07) Longueurs de clé minimales et conseils de mise en œuvre. https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf
Protecting Parked Domains BCP (2015-12) Publier v=spf1 -all (et les enregistrements associés) sur les domaines qui n’envoient jamais de courrier. https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf
Email Forwarding Best Practices Exploiter un service de transfert de courrier (par exemple un ESP qui transfère les réponses à ses clients utilisant des adresses sur le domaine de l’ESP). http://www.maawg.org/system/files/news/MAAWG_Email_Forwarding_BP.pdf
Feedback Reporting Recommendation (2014-02) Recommandations sur les retours et le signalement des plaintes entre serveurs de réception et expéditeurs. https://www.m3aawg.org/sites/default/files/legacy/document/M3AAWG_Feedback_Reporting_Recommendation_BP-2014-02.pdf
DMARC Training Series (vidéos) Formation approfondie sur DMARC présentée par des experts de DMARC.org. http://www.maawg.org/activities/training/dmarc-training-series

Ressources sur les feedback loops (FBL)

Une feedback loop de plaintes (Complaint Feedback Loop) est un mécanisme par lequel un fournisseur de messagerie renvoie les plaintes pour spam de ses utilisateurs à l’expéditeur vérifié du message, pour que celui-ci puisse nettoyer sa base de données et corriger les causes des plaintes. Normes : la RFC 6449 (recommandations opérationnelles) et l’Abuse Reporting Format (ARF) (RFC 5965 ; la RFC 6650 en est la déclaration d’applicabilité) comme format de rapport.

Trois types de formats FBL

Type Fonctionnement Remarques
Traditionnel (par IP) Conforme à la RFC 6449 ; rapports ARF contenant le message complet et l’identification de l’utilisateur plaignant, rattachés à l’IP d’envoi. Le modèle classique ; l’expéditeur doit contrôler ou déclarer les IP d’envoi.
Agrégé Consolide des nombres de plaintes sans données personnelles ni messages complets. Motivé par la vie privée ; fournit tout de même des données de performance par flux. Exemples : Gmail (données de taux de spam de Postmaster Tools), Microsoft SNDS, Signal Spam.
Par domaine Exige des signatures DKIM ; rapports ARF rattachés au domaine signataire. Permet aux expéditeurs sur adresses IP partagées d’obtenir un retour sur leur propre programme ; va de pair avec le conseil du BCP destiné aux expéditeurs de signer DKIM chaque entité d’un pool partagé avec son propre domaine ou sous-domaine.

Points d’inscription aux FBL par fournisseur de messagerie (selon la liste du M3AAWG)

La plupart des FBL traditionnelles sont exploitées par l’intermédiaire de la Universal Feedback Loop de Validity (https://fbl.validity.com) : Bluetie/Excite, Comcast, Cox, Fastmail, Gandi, Italiaonline (Libero/Virgilio), La Poste, Locaweb, Mail.Ru, OpenSRS/Tucows, Rackspace, Seznam, SFR, SilverSky (USA.NET), Swisscom, Synacor, Telecom Italia, Telenet, Telenor, Terra, UOL, Virgin Media, Ziggo.

Exceptions et programmes hors Validity :

Fournisseur Type Inscription
Earthlink Traditionnel fblrequest@abuse.earthlink.net
Microsoft JMRP (Junk Mail Reporting Program) Traditionnel https://postmaster.live.com/snds/JMRP.aspx
QQ.com Traditionnel http://open.mail.qq.com (en chinois)
United Online/Juno/NetZero Traditionnel http://www.unitedonline.net/postmaster/whitelisted.html
Gmail Agrégé https://support.google.com/mail/answer/6254652 (Postmaster Tools)
Microsoft SNDS Agrégé https://sendersupport.olc.protection.outlook.com/snds/index.aspx
Signal Spam (France) Agrégé https://www.signal-spam.fr (adhésion payante)
Yahoo! Par domaine (DKIM) https://senders.yahooinc.com/contact#complaint-feedback-loop
Comcast, Gandi, La Poste, SFR Par domaine (proposent aussi le traditionnel) https://fbl.validity.com

À noter : Gmail ne propose aucune FBL traditionnelle par message ; son programme agrégé (taux de spam par identifiant via Postmaster Tools) est le seul signal de plaintes disponible, ce qui explique qu’il soit impossible de supprimer les plaignants un par un chez Gmail et que la prévention des plaintes y compte davantage. La FBL de Yahoo fonctionne par domaine, rattachée au domaine DKIM d=.

Le M³AAWG fournit cette liste à titre de service au secteur et ne cautionne aucun fournisseur en particulier ; il s’agit d’informations de tiers, proposées « en l’état ».

La place des FBL dans le travail d’un expéditeur

Selon le BCP destiné aux expéditeurs : les ESP doivent disposer d’un système pour recevoir à la fois les rapports de FBL et les plaintes arrivant directement dans la boîte abuse, ainsi que d’une procédure pour y donner suite : suppression immédiate du destinataire plaignant (lorsque la FBL l’identifie) et suivi du taux de plaintes par client ou par flux pour détecter les violations des conditions d’utilisation ou les problèmes d’hygiène de base de données.

Voir aussi