Meilleures pratiques M3AAWG pour l’authentification des emails (2020)

Ce document du M³AAWG (Email Authentication Recommended Best Practices) est une liste de contrôle d’exigences techniques binaires (« elles sont mises en œuvre ou elles ne le sont pas ») pour authentifier les emails avec SPF, DKIM, DMARC et ARC. Il couvre trois catégories d’acteurs, les expéditeurs (émetteurs), les intermédiaires (services de transfert, listes de diffusion) et les serveurs de réception (fournisseurs de messagerie), et il complète les notions présentées dans DMARC.

SMTP AUTH (identifiants présentés lors de la soumission du message, MUA/MSA → MTA) est explicitement hors du périmètre : il sert un autre objectif.

Pourquoi c’est important : les fournisseurs de messagerie évoquent régulièrement un avenir possible du type « No auth, no entry » (pas d’authentification, pas d’entrée), dans lequel un message devrait réussir une ou plusieurs vérifications d’authentification pour être seulement envisagé pour la livraison. Ces recommandations visent à établir la confiance dès aujourd’hui et à satisfaire toute obligation future de ce type. L’objectif de conception est partout de protéger le domaine organisationnel de l’en-tête RFC5322.From (le domaine que voit le destinataire), ce qui implique de s’appuyer sur DMARC, puisque DMARC protège ce domaine d’une façon que SPF et DKIM seuls ne permettent pas.

Protocoles couverts

Liste de contrôle pour les décideurs

Recommandations pour les expéditeurs

« Expéditeur » = le point d’émission (propriétaires de marques, fournisseurs de messagerie, ESP ; pas les utilisateurs finaux qui s’écrivent de personne à personne).

SPF

Publiez des enregistrements SPF pour tout domaine utilisé dans la commande RFC5321.MailFrom (MAIL FROM) et pour tout domaine utilisé comme identité SMTP HELO/EHLO de n’importe quel serveur d’envoi.

• Assurez-vous que l’enregistrement est valide et respecte les limites de requêtes DNS de la RFC 7208 (la limite de 10 requêtes DNS).
• Les enregistrements devraient se terminer par ~all (softfail) : voir la section sur les serveurs de réception pour comprendre pourquoi -all interagit mal avec le transfert avant l’évaluation DMARC.
• N’autorisez que les IP strictement nécessaires : utilisez le ou les plus petits blocs réseau possibles pour les IP qui envoient au nom du domaine.
• Les domaines qui n’envoient pas d’email devraient publier v=spf1 -all (selon le BCP du M³AAWG Protecting Parked Domains).
• Les domaines MAIL FROM devraient être alignés avec le domaine RFC5322.From lorsque c’est possible.
• Référence approfondie : M³AAWG Best Practices for Managing SPF Records (https://www.m3aawg.org/sites/default/files/m3aawg_managing_spf_records-2017-08.pdf).

DKIM

Tout système de réputation fondé sur les domaines a besoin d’une méthode fiable pour confirmer l’identité du domaine qui prend la responsabilité d’un message ; DKIM est la meilleure méthode disponible actuellement.

• Signez tout le courrier sortant avec une clé DKIM dont le domaine d= est aligné avec le domaine RFC5322.From.
• Les ESP devraient sérieusement envisager une double signature avec leur propre domaine, pour permettre aux serveurs de réception d’établir des évaluations de réputation distinctes pour chaque domaine.
• Les ESP devraient utiliser des clés DKIM distinctes pour chaque client.
• Signez un ensemble raisonnable de champs d’en-tête, en prenant pour guide la section 5.4.1 de la RFC 6376.
• Gestion des clés, selon le M³AAWG :
  • DKIM Key Rotation Best Common Practices (rév. mars 2019 : 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 (rév. juillet 2017 : https://www.m3aawg.org/sites/default/files/m3aawg-key-implementation-bp-revised-2017-07.pdf)

DMARC

• Le M³AAWG recommande p=reject pour les domaines qui publient un enregistrement DMARC ; lorsque cela pose des difficultés opérationnelles, utilisez p=quarantine.
• p=none, sp=none et pct<100 ne sont que des états transitoires : l’objectif est de les supprimer le plus vite possible. (À comparer avec l’approche plus progressive « commencer par p=none » de notre article DMARC ; les deux s’accordent sur la destination, une politique contraignante, guidée par les données des rapports.)
• Fixez la politique en mettant en balance le profil de risque du domaine face à l’usurpation ou au phishing, actifs ou potentiels, et la perte possible de courrier légitime due à une signature absente ou cassée.
• Chaque enregistrement DMARC publié, même en p=none, doit comporter au minimum une balise rua pointant vers une boîte aux lettres qui reçoit les rapports agrégés. Sans la possibilité de recevoir et de traiter les rapports, le propriétaire du domaine ne peut pas savoir s’il peut passer sans risque à des politiques plus strictes, puisqu’il ne peut pas vérifier que tout le courrier légitime s’authentifie correctement.
• ruf (rapports d’échec) est facultatif : en raison des préoccupations de vie privée et de caviardage des données personnelles, la plupart des serveurs de réception n’envoient pas de rapports d’échec, et ils sont peu utiles à la plupart des propriétaires de domaines.
• Ni la boîte rua ni la boîte ruf ne devraient envoyer de réponses (réponses automatiques) lorsqu’elles reçoivent un rapport.

Recommandations pour les intermédiaires

« Intermédiaires » = les Mediators, Relays ou Gateways au sens de la RFC 5598 : services de transfert, listes de diffusion, serveurs de groupes de discussion, et toute boîte aux lettres configurée pour transférer tout son courrier vers un autre domaine. SPF, DKIM et DMARC sont conçus de telle sorte que les vérifications d’authentification finales peuvent échouer pour un courrier passé par un intermédiaire alors qu’elles auraient réussi s’il avait été envoyé directement. Le M³AAWG demande aux intermédiaires de réduire ce risque :

• Réduire au minimum les modifications du message en transit. L’authentification dépend du contenu des en-têtes et/ou du corps ; les modifications (parfois inévitables pour les listes de diffusion) doivent rester minimales.
• Atténuer le risque d’échec d’authentification. Exemple type : une liste de diffusion qui ajoute un en-tête ou un pied de page à chaque message devrait réécrire l’en-tête From lorsque le domaine de l’auteur publie DMARC :
  1. un membre publie depuis john.jones@dmarc.domain.tld ;
  2. le logiciel de liste constate que dmarc.domain.tld publie une politique DMARC ;
  3. la liste réécrit le From en, par exemple, john.jones=40dmarc.domain.tld@list.domain, ce qui élimine le risque d’échec DMARC.
• Mettre en œuvre ARC. ARC enregistre les résultats d’authentification à chaque saut sans modifier le contenu du message, ce qui protège contre les échecs en aval causés par le passage par l’intermédiaire. Cela suppose que l’intermédiaire effectue lui-même les vérifications SPF/DKIM/DMARC dont les résultats sont consignés dans l’en-tête ARC-Authentication-Results.
• Générer et envoyer des rapports agrégés DMARC.

Recommandations pour les serveurs de réception

« Serveurs de réception » = les domaines qui acceptent et stockent le courrier de leurs destinataires (terme plus large que « fournisseur de messagerie », car beaucoup d’emails aboutissent à des domaines qui ne sont pas des fournisseurs de messagerie). Ces mécanismes seront vraisemblablement de plus en plus exigés ; lorsqu’ils dépassent les compétences informatiques d’un petit domaine, le M³AAWG demande aux services d’hébergement cloud vers lesquels ces domaines migrent de les mettre en œuvre.

• Effectuer les vérifications d’authentification (SPF, DKIM, DMARC) sur le courrier entrant et utiliser les résultats pour décider de l’acceptation et du filtrage : c’est une meilleure pratique pour protéger les titulaires de boîtes aux lettres contre les emails frauduleux, que le serveur de réception adopte ou non le principe « no auth, no entry ».
• Respecter les politiques DMARC. Lorsqu’un domaine publie DMARC (surtout p=reject), les destinataires s’attendent à ce que les messages qui réussissent proviennent réellement du domaine de la ligne From. Les dérogations par politique locale devraient être (a) relativement rares et (b) clairement justifiées et documentées dans les champs de dérogation à la politique et de commentaire du rapport agrégé.
• Un pass DMARC l’emporte sur un verdict SPF fail. Comme DMARC n’exige qu’un pass aligné de DKIM ou de SPF, et que les domaines Return-Path ne sont souvent pas alignés avec le domaine From, un échec SPF (enregistrement terminé par -all et vérification en échec) ne devrait pas entraîner de rejet tant que DMARC n’a pas été évalué et n’a pas réussi.
  • Seule exception : v=spf1 -all, un enregistrement qui déclare qu’aucun usage n’est autorisé. Dans ce cas, le serveur de réception (ou l’intermédiaire) peut agir de façon préventive sur l’échec SPF.
• Envoyer des rapports agrégés DMARC. Les rapports permettent aux propriétaires de domaines de renforcer leur authentification, qu’ils passent ou non à p=reject : sans eux, ils ne peuvent ni identifier les flux légitimes non authentifiés, ni voir les tentatives d’usurpation et les prestataires mal configurés. Plusieurs grands fournisseurs de messagerie ont conclu que l’envoi de rapports agrégés n’entre pas en conflit avec les lois sur la vie privée ; le M³AAWG recommande aux émetteurs de rapports de tenir compte des avis juridiques actuels (par exemple, le rapport de certified-senders.org sur DMARC et le RGPD).
• Exploiter les en-têtes ARC : prendre en compte les ensembles d’en-têtes ARC reçus dans le verdict d’authentification final et dans le traitement du message.

Références citées par le document

RFC : 5598 (architecture de la messagerie Internet), 6376 (DKIM), 7208 (SPF), 7489 (DMARC), 8617 (ARC).

Documents d’accompagnement du M³AAWG (voir aussi l’index des documents) :

Voir aussi

• DMARC : présentation des notions (alignement, syntaxe de l’enregistrement, évolution de la politique)
• Meilleures pratiques M3AAWG pour les expéditeurs : les exigences sur le DNS direct et inverse et sur HELO qui alimentent SPF, et DKIM par client dans les pools d’adresses IP partagées
• Index des documents M3AAWG