Meilleures pratiques M3AAWG pour les expéditeurs (version 3.0)

Le comité Senders du Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) publie ce document de meilleures pratiques (Sender Best Common Practices, BCP) comme base consensuelle du secteur pour l’envoi de messages électroniques commerciaux. La version 3.0 (février 2015) est une refonte majeure de la version 2.0 (octobre 2011), davantage centrée sur la collecte des adresses et la transparence des données ; elle remplace à la fois les précédentes Sender Best Communications Practices et leur résumé (Executive Summary).

Le public visé va des professionnels de la délivrabilité et de la conformité chez les ESP et les gros expéditeurs jusqu’aux équipes marketing et aux dirigeants qui valident les pratiques d’envoi. L’objectif affiché : promouvoir la transparence, pour que les destinataires et les fournisseurs de messagerie puissent distinguer les messages légitimes des abus.

Deux déclarations de principe tirées du document :

Le M³AAWG affirme catégoriquement qu’un consentement opt-in de l’abonné clair, visible, éclairé et vérifiable est la meilleure pratique en matière d’autorisation d’envoi.

L’utilisateur final et ses attentes doivent être la priorité absolue. Peu importe ce qu’un expéditeur a légalement le droit de faire, ou le droit qui lui est accordé par une politique de confidentialité ; ce qui compte, c’est que le destinataire, ses préférences et ses attentes soient respectés.

Au minimum, les expéditeurs doivent respecter les politiques d’utilisation acceptable des fournisseurs de messagerie et le droit national ou régional applicable (CAN-SPAM, LCAP, législation européenne : voir l’annexe B du document).

Consentement : les trois niveaux d’opt-in

La règle principale : l’expéditeur doit disposer du consentement explicite du destinataire avant l’envoi et avant d’ajouter le destinataire à toute communication régulière. Chaque niveau ci-dessous s’appuie sur le précédent.

Niveau 1 : exigences du simple opt-in

À utiliser avec une extrême prudence : des adresses non confirmées (fautes de frappe, falsifications pures et simples) peuvent être ajoutées sans contrôle, ce qui entraîne plaintes, rebonds et dégradation de la réputation. En cas d’utilisation :

1. Le destinataire doit donner son consentement en connaissance de cause au moment où l’adresse est collectée.
2. Le consentement doit être clair et évident : ni caché en petits caractères, ni noyé dans du jargon juridique, ni placé sur une page séparée.
3. L’inscription doit indiquer clairement le type précis de liste(s) rejointe(s) ; si possible, laissez les destinataires choisir les listes dans lesquelles ils sont inclus ou dont ils sont exclus. Plus le destinataire a de contrôle, moins il y a de signalements d’abus.
4. Informez les destinataires de la fréquence et du type de communications prévus, avec un choix pour chacun. Une hausse inattendue de la fréquence entraîne souvent davantage de plaintes pour abus.
5. N’utilisez les adresses que pour les finalités annoncées lors de l’inscription. Une finalité secondaire créée plus tard (par exemple une nouvelle newsletter au contenu différent) exige un opt-in distinct ; elle ne doit pas être activée par défaut. Jugez de la « finalité secondaire » du point de vue du destinataire ; certaines juridictions exigent légalement cette autorisation distincte.
6. Envisagez de montrer un exemple visuel de l’email que l’abonné recevra, pour qu’il le reconnaisse à son arrivée.
7. Conservez les preuves du consentement au moment de la collecte : adresse IP, date de collecte, site web ou événement où la collecte a eu lieu et (dans les grandes entreprises) quel service a collecté l’adresse et comment. Ces données doivent être facilement accessibles s’il faut prouver le consentement à une personne, à un FAI, à un opérateur de RBL ou à une autorité de contrôle, dans le respect du droit applicable au stockage des données personnelles.

Niveau 2 : ajout du message de notification

8. Envoyez le message de notification ou de bienvenue immédiatement, ou dans les 24 heures suivant l’inscription. Il devrait :
   • inclure l’adresse fournie et toute autre information donnée par l’utilisateur ;
   • indiquer la fréquence et le type de contenu ;
   • utiliser la même adresse From que les futurs messages, pour que les destinataires puissent l’ajouter à leur carnet d’adresses ;
   • si possible, être envoyé depuis des IP séparées des IP d’envoi en masse habituelles.

Niveau 3 : opt-in confirmé

9. Le niveau le plus exigeant ; il empêche les fautes de frappe et les adresses soumises par malveillance d’entrer dans les envois réguliers. En outre :
   • indiquez aux utilisateurs, au moment de l’inscription, de consulter leur messagerie et de donner suite au message de confirmation ;
   • gardez l’email de confirmation simple et sans publicité, pour qu’il ne soit pas filtré comme un abus.

Consentement implicite

Le consentement implicite est déduit d’une interaction (cas typique : une adresse email collectée en caisse sans préciser qu’elle servira à l’ajout à des listes marketing). Il n’est pas considéré comme une meilleure pratique : il ne convient pas à tous les expéditeurs et risque de provoquer des plaintes pour abus. En cas d’utilisation, surveillez de près les plaintes, ouvertures et clics de ce segment ; mieux, ajoutez une case distincte de consentement explicite lors de la collecte, ou menez une campagne de confirmation de l’autorisation (permission pass) avant tout nouvel envoi marketing. Quelle que soit la méthode, conservez pour chaque adresse la trace de la façon dont elle est entrée dans la liste : IP d’inscription, horodatage, capture d’écran du texte d’information présenté, et politiques de confidentialité en vigueur au moment de l’abonnement.

Enrichissement de fichiers (email append)

Associer à une fiche client une adresse email que le client n’a jamais fournie à cette fin 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. Voir la prise de position du M³AAWG sur l’enrichissement de fichiers (Position on Email Appending, mise à jour en 2019 : https://www.m3aawg.org/sites/default/files/legacy/m3aawg_apending_position_update-2019-01.pdf).

Exigences de désabonnement

1. Rendez la procédure de désabonnement aussi claire et simple que raisonnablement possible.
2. Traitez toutes les demandes de désabonnement sans délai (conformité légale et respect du destinataire).
3. Fixez les attentes : indiquez le délai de traitement et les listes ou types de communications concernés. Plus le délai de retrait est long, plus la poursuite des envois risque d’être jugée abusive et signalée.
4. Soyez en mesure de traiter les demandes de désabonnement par email envoyées aux adresses From et Reply-To du courrier sortant.
5. Le lien de désabonnement doit contenir tout ce qu’il faut pour mener le désabonnement à bien : identifiant de l’abonné ; liste concernée (s’il y en a plusieurs) ; jetons d’authentification propres à l’utilisateur si nécessaire pour empêcher des désabonnements malveillants par des tiers.
6. Adoptez l’en-tête List-Unsubscribe (RFC 2369) dans chaque message :
   • variante mailto : une adresse encodée propre à chaque destinataire ; tout message reçu à cette adresse peut être traité comme un désabonnement de ce destinataire, même s’il n’a pas été envoyé depuis l’adresse abonnée.
   • variante URL : un lien vers la fonction de désabonnement de la plateforme (qui peut être le même lien que dans le corps) ; encodez toute information personnelle dans le lien pour éviter les abus et simplifier au maximum la démarche.
7. Définissez une politique pour les désabonnements lorsqu’aucun centre de préférences ne peut être affiché : valables pour tout le courrier ou pour une seule liste ? Choix par défaut recommandé : retirer le destinataire de tous les envois.
8. Utilisez des descriptions textuelles lisibles (et non des images) à côté des liens de désabonnement en un clic.
9. Envisagez des moyens de désabonnement hors ligne (adresse postale, téléphone), locaux ou gratuits, pour que le coût pour la personne soit faible ou nul.
10. Dans un centre de préférences proposant plusieurs options, l’option de désabonnement devrait être cochée par défaut pour les listes auxquelles l’utilisateur est actuellement abonné.
11. Les nouvelles offres d’abonnement présentées aux abonnés existants doivent être décochées par défaut.
12. Les abonnés doivent pouvoir se désabonner sans se connecter ni affronter de contrôle de sécurité. Un centre de préférences protégé par identifiant est acceptable en complément, mais le désabonnement d’une liste précise doit fonctionner hors de toute zone sécurisée.
13. Fortement recommandé : indiquez dans le corps du message l’adresse email abonnée du destinataire, ce qui est particulièrement utile lorsque plusieurs adresses sont transférées vers une même boîte aux lettres.

Sécurité des données

Les ESP et les expéditeurs qui stockent des données personnelles d’abonnés devraient maintenir un programme de sécurité complet fondé sur les pratiques standard du secteur. Points de départ cités : OWASP, SANS, le guide « Data Protection and Breach Readiness Guide » de l’Online Trust Alliance, ISO/IEC 27002:2013 (contrôle d’accès ; gestion des communications et de l’exploitation ; gestion des incidents de sécurité de l’information) et le rapport de la FTC américaine sur la vie privée des consommateurs. Le M³AAWG recommande très fortement de faire de la sécurité une priorité : les données d’adresses email stockées ont de la valeur pour les criminels, même lorsqu’il ne s’agit « que » d’adresses email.

Transparence des données (identité technique)

La transparence s’applique aux IP et aux domaines des serveurs d’envoi ainsi qu’aux liens du corps du message. Quand l’information est accessible, les expéditeurs peuvent être tenus pour responsables et les serveurs de réception peuvent les identifier et les contacter au sujet de clients problématiques.

WHOIS

• Tenez à jour des enregistrements WHOIS (ou rWHOIS) exacts pour les domaines qui revendiquent la responsabilité de grands volumes de courrier.
• Les sous-allocations d’IP de /29 ou plus (IPv4) et de /56 ou plus (IPv6) doivent être documentées de façon exacte et complète selon la politique du RIR (par exemple l’ARIN).
• L’enregistrement de domaine anonyme ou par proxy contourne la transparence : aucune raison commerciale sérieuse ne justifie un WHOIS volontairement vague pour des entités qui n’ont pas l’intention d’abuser des réseaux de messagerie.

Authentification des emails

Quatre formes citées : SPF (valide l’IP d’envoi par rapport aux domaines Return-Path et HELO), Sender ID (fondé sur la PRA ; n’est plus beaucoup utilisé), DKIM (signature cryptographique validée par rapport à un domaine) et DMARC (politique déclarée par l’expéditeur et visibilité sur le courrier du domaine From qui échoue à SPF/DKIM). Voir Meilleures pratiques M3AAWG pour l’authentification des emails et DMARC pour les recommandations de déploiement actuelles.

Détails techniques des IP (DNS direct, DNS inverse, HELO)

Rédigé pour IPv4 ; l’intention est de rendre transparente la propriété et claire la responsabilité aux yeux des systèmes de réputation et de filtrage.

DNS direct

• Il DOIT être choisi un nom qui identifie clairement le domaine de la partie responsable : l’ESP ou le fournisseur lorsque l’IP est partagée, normalement le client ou l’annonceur lorsqu’elle est dédiée (c’est alors l’administrateur du domaine du client qui configure le DNS direct).
• Le nom doit clairement désigner un serveur, et non un espace générique de pool : server03.espname.com, et non pool-dhcp-456.espname.com.
• Si plusieurs noms pointent vers la même IP partagée, le nom retenu est le « nom principal ».
• Sauf pour les IP dédiées, tous les serveurs de messagerie de l’ESP ou de l’annonceur doivent utiliser le même nom ou un petit ensemble de noms au « niveau du registre de domaine », en se différenciant par des sous-domaines : utilisez server1.espname.com, server2.espname.com, et non espname01.com, espname02.com.

DNS inverse

• Chaque IP d’envoi doit avoir un DNS inverse (PTR/IN-ADDR) configuré.
• Un seul nom de DNS inverse par IP.
• Il doit correspondre exactement au nom principal du DNS direct.

HELO/EHLO (entre en compte dans l’authentification SPF)

• Doit être un nom d’hôte résolvable : un littéral d’IP entre [] n’est pas acceptable.
• IP dédiée : le HELO DOIT correspondre exactement au nom principal du DNS direct.
• IP partagée ou NAT vers plusieurs serveurs : le HELO doit correspondre au nom principal au moins au niveau du registre de domaine ; une correspondance exacte convient aussi. Recommandé : donner à chaque système de messagerie ou client derrière un NAT son propre sous-domaine HELO (par exemple server01.brand1.espname.com) pour faciliter le diagnostic.

Environnements à adresses IP partagées ou dédiées

Définitions :

• Environnement dédié : une seule entité distincte a l’usage exclusif et la responsabilité du courrier sortant qui y transite (une ou plusieurs IP, exactement une entité responsable).
• Environnement partagé : plusieurs entités sont affectées à une IP ou à un pool d’IP.
• Une « entité » est la partie responsable de l’envoi du message : une entreprise, une marque en son sein, ou un client d’ESP.

Raisons de choisir un environnement dédié :

• Qualité du courrier ou de la liste inconnue ou inférieure à la moyenne : l’isoler pour protéger les autres (ou pour établir et suivre sa qualité).
• Qualité du courrier connue et supérieure à la moyenne : l’isoler des effets néfastes des autres.
• Maîtrise des schémas de volume : mélanger transactionnel et marketing, ou plusieurs entités, crée un trafic irrégulier ; la régularité du volume joue un rôle essentiel dans la réputation d’une IP, en particulier chez les fournisseurs de messagerie gratuite, les grands domaines et les petites entreprises hébergées par de grands fournisseurs. (La régularité du volume n’est généralement pas un indicateur utile pour les petites entreprises auto-hébergées qui prennent des décisions automatisées.)
• L’entité veut assumer toute la responsabilité, sans attribution à l’ESP, ou a besoin de réglages MTA sortants particuliers.
• Certification, inscription sur liste blanche ou autres services de délivrabilité avancés exigeant un environnement dédié.

Raisons de choisir un environnement partagé :

• La combinaison des volumes maintient un volume d’envoi moyen régulier, qui établit et entretient la réputation de l’IP.
• La réputation est partagée : les erreurs d’un expéditeur isolé sont diluées.
• Moins cher : l’envoi devient économiquement accessible aux très petits expéditeurs.

Recommandations de provisionnement :

• Les entités d’un environnement partagé devraient avoir un contenu et des indicateurs similaires (taux de plaintes et taux de rebonds) ; un contrôle renforcé est nécessaire, car les mauvaises pratiques d’une entité peuvent « empoisonner » le pool.
• Signez DKIM le courrier de chaque entité avec un domaine ou un sous-domaine unique dans les environnements partagés : cela permet aux serveurs de réception de distinguer les flux, rend possible la participation de chaque entité à DMARC, et permet à une entité de conserver la réputation acquise si elle est provisionnée ailleurs.
• Meilleure pratique (reconnue comme difficile) : authentifier simultanément le domaine de l’ESP et celui de l’entité.
• Les ESP qui proposent les deux modèles devraient définir à l’avance les critères de passage d’une entité du partagé au dédié, et surveiller qu’ils sont remplis.
• Meilleures pratiques des ESP pour les adresses IP dédiées : DNS inverse propre à l’entité (par exemple entity.cust.esp.com, une attribution lisible) ; une procédure de chauffe d’IP bien définie et appliquée de façon cohérente ; aider les entités à être inscrites sur des listes blanches lorsqu’elles existent ; aider les entités à garder un volume d’envoi moyen régulier pour accumuler de la réputation.

Voir aussi Allocation de base des adresses IP et Segmentation et allocation avancées des adresses IP.

Contrôle des clients (ESP)

Les ESP qui envoient de grands volumes d’emails pour le compte de leurs clients sont à la merci des pires pratiques de leurs pires clients.

• Tous les ESP doivent disposer d’une procédure de contrôle avant envoi, pour repérer de façon proactive les expéditeurs malveillants avant qu’ils n’envoient.
• Tous les ESP doivent disposer d’une procédure de contrôle après envoi (surveillance) une fois que les clients ont commencé à envoyer.
• Un bon contrôle distingue les vrais spammeurs des clients qui ont simplement besoin de conseils en hygiène de base de données. Le contrôle fait partie intégrante de la réputation et de la réduction des abus.
• Guide approfondi : M³AAWG Vetting Best Common Practices (https://www.m3aawg.org/sites/default/files/doc_files/MAAWG_Vetting_BCP_2011-11.pdf).

Traitement des plaintes et des feedback loops (FBL)

• Les ESP reçoivent les plaintes principalement par les feedback loops des fournisseurs de messagerie et directement dans leur boîte abuse. Ils doivent disposer d’un système pour traiter les deux, ainsi que d’une procédure pour décider de la suite à leur donner.
• Les plaintes sont un facteur clé pour déterminer si des clients enfreignent les conditions générales de l’expéditeur ou se comportent simplement mal.
• Référence : M³AAWG Feedback Reporting Recommendation ; voir l’index des documents M3AAWG pour l’écosystème des FBL (formats, liste des fournisseurs).

Services de transfert

Si un ESP fournit à de petits clients des adresses sur le propre domaine d’envoi de l’ESP (utilisées dans les en-têtes des messages), il peut devoir leur transférer les réponses ; il devrait alors exploiter un véritable service de transfert de courrier. Détails : M³AAWG Email Forwarding Best Practices.

Traitement des rebonds et des NDR

La livraison n’est jamais garantie. Un système d’envoi doit pouvoir recevoir et traiter le courrier renvoyé au même volume et au même rythme qu’il envoie : prévoyez des ressources pour les deux sens du trafic SMTP.

• Les retours sont généralement synchrones (rejetés pendant la conversation SMTP) ; plus rarement asynchrones (un message de rebond envoyé à l’adresse Return-Path, parfois des heures ou des jours plus tard). En pratique, environ 95 % de tous les retours sont synchrones. Les expéditeurs doivent pouvoir identifier quelle adresse a rebondi pour traiter correctement les retours asynchrones.
• Les retours comportent un code d’état numérique et un message descriptif. La RFC 5321 définit les réponses SMTP de base ; la RFC 3463 définit les codes d’état étendus. Les codes d’état suivent généralement les RFC, mais le texte descriptif est personnalisé par chaque serveur de réception et peut ne les suivre que de loin : les expéditeurs doivent pouvoir traiter, classer et suivre les deux.

Échecs temporaires (4xx) : les causes incluent un serveur de réception surchargé ou un serveur de réception qui a détecté des caractéristiques d’envoi inhabituelles et suspendu l’acceptation depuis l’IP pour une durée donnée. Fermez la connexion et réessayez plus tard. Les serveurs de réception de très gros volumes attendent des expéditeurs qu’ils adaptent leur comportement de nouvelle tentative en temps réel, globalement pour tout le courrier issu de la même IP. Point essentiel : certains serveurs de réception renvoient délibérément un échec temporaire sur un premier message pour tester la conformité aux RFC ; les spammeurs ne réessaient généralement pas, les expéditeurs légitimes si. Ne traitez jamais un 4xx comme définitif.

Échecs définitifs (5xx) : le plus courant est « user unknown » (utilisateur inconnu) ; de nombreux codes 5xx signalent une violation de politique selon le texte descriptif. Quel que soit le texte, ne réessayez jamais le message.

Traitement des NDR et hygiène de base de données :

• Les codes 4xx/5xx indiquent au serveur de messagerie quoi faire du message, mais n’ont pas été conçus pour les gestionnaires de listes : ils ne disent pas s’il faut retirer l’adresse de la liste. Lisez le texte descriptif pour décider du traitement de chaque adresse ; il peut aussi révéler des problèmes d’infrastructure ou de contenu, ou que l’IP d’envoi figure sur une liste de blocage et qu’un retrait de liste est nécessaire avant que le courrier ne passe à nouveau.
• Si le serveur de réception indique que l’utilisateur n’existe pas, ne réessayez pas et supprimez l’adresse des envois futurs. Les serveurs de réception utilisent le volume d’échecs définitifs comme facteur de réputation ; de gros volumes de rebonds définitifs indiquent généralement un processus d’inscription mal géré ou une liste ancienne ou mal utilisée, et font baisser le score de réputation d’une IP.
• Règle de retrait recommandée : retirer une adresse qui rebondit systématiquement (quel que soit le code ou le texte) sur plusieurs campagnes consécutives, en général au moins deux rebonds consécutifs sur une période de deux semaines ou plus, ce qui laisse passer les problèmes de serveur passagers côté réception.

Termes clés du glossaire (annexe C, d’après la RFC 5598)

Voir aussi

• Meilleures pratiques M3AAWG pour l’authentification des emails
• Index des documents M3AAWG : les autres documents du M³AAWG pour les expéditeurs et les ESP, et les ressources sur les FBL
• Fondamentaux de la délivrabilité des emails
• Les deux mondes de la délivrabilité email
• Recommandations pour la chauffe d’IP
• Segmentation et allocation avancées des adresses IP