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

Que vous envoyiez, transfériez ou receviez des emails, le secteur attend de vous un ensemble précis de mesures d’authentification. Le Messaging, Malware and Mobile Anti-Abuse Working Group (M³AAWG) les expose dans ses Email Authentication Recommended Best Practices, 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.

La liste de contrôle 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). DMARC explique les notions de base.

SMTP AUTH (les identifiants présentés lors de la soumission d’un message, du MUA ou du MSA vers le MTA) est explicitement hors du périmètre, car 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 future obligation de ce type. L’objectif est partout de protéger le domaine organisationnel de l’en-tête RFC5322.From (le domaine que voit le destinataire). Cela implique de s’appuyer sur DMARC, qui 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

Un expéditeur est le point d’émission des messages : les propriétaires de marques, les fournisseurs de messagerie et les ESP, mais 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 ou 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). La section sur les serveurs de réception ci-dessous explique pourquoi -all interagit mal avec le transfert avant l’évaluation DMARC.
• N’autorisez que les adresses IP strictement nécessaires. Utilisez les plus petits blocs réseau possibles pour les adresses IP qui envoient au nom du domaine.
• Les domaines qui n’envoient pas d’emails devraient publier v=spf1 -all (comme le recommande 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.
• Pour plus de détails, voir 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, et DKIM est la meilleure méthode disponible aujourd’hui.

• Signez tous les messages sortants avec une clé DKIM dont le domaine d= est aligné avec le domaine RFC5322.From.
• Les ESP devraient sérieusement envisager de signer aussi avec leur propre domaine, afin que les serveurs de réception puissent établir une réputation distincte pour chaque domaine.
• Les ESP devraient utiliser une clé DKIM différente 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.
• Pour la gestion des clés, le M³AAWG renvoie à :
  • DKIM Key Rotation Best Common Practices (révisé en 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évisé en 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, et l’objectif est de les quitter le plus vite possible. (Comparez avec le conseil plus progressif de « commencer par p=none » dans 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 d’identité et au phishing, actifs ou potentiels, et la perte possible de messages légitimes due à une signature absente ou cassée.
• Chaque enregistrement DMARC publié, même avec p=none, doit comporter au minimum une balise rua qui pointe vers une boîte aux lettres pour les rapports agrégés. Sans la possibilité de recevoir et de traiter les rapports, les propriétaires de domaines ne peuvent pas savoir s’ils peuvent passer sans risque à une politique plus stricte, car ils ne peuvent pas vérifier que tous leurs messages légitimes s’authentifient correctement.
• ruf (rapports d’échec) est facultatif. En raison des préoccupations de vie privée et du caviardage des données personnelles, la plupart des serveurs de réception n’envoient pas de rapports d’échec, et ceux-ci 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

Les intermédiaires sont les Mediators, Relays et Gateways de la RFC 5598 : les services de transfert, les listes de diffusion, les serveurs de groupes de discussion, et toute boîte aux lettres configurée pour transférer tous ses messages vers un autre domaine. SPF, DKIM et DMARC sont conçus d’une façon qui fait que les vérifications d’authentification finales peuvent échouer pour des messages passés par un intermédiaire, alors que les mêmes messages auraient réussi s’ils avaient été envoyés directement. Le M³AAWG demande aux intermédiaires de réduire ce risque :

• Modifier le message le moins possible en transit. L’authentification dépend du contenu des en-têtes et/ou du corps, donc toute modification (parfois inévitable pour les listes de diffusion) doit rester minimale.
• Réduire le risque d’échec d’authentification. L’exemple type est une liste de diffusion qui ajoute un en-tête ou un pied de page à chaque message. Elle 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 plus loin sur le parcours causés par le passage par l’intermédiaire. Cela suppose que l’intermédiaire effectue lui-même les vérifications SPF, DKIM et DMARC dont les résultats vont 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

Les serveurs de réception sont les domaines qui acceptent et stockent les messages de leurs destinataires. Le terme est plus large que « fournisseur de messagerie », car beaucoup d’emails aboutissent à des domaines qui ne sont pas des fournisseurs de messagerie. Ces mécanismes deviendront vraisemblablement de plus en plus nécessaires. 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 les messages entrants, 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. DMARC n’exige qu’un pass aligné de DKIM ou de SPF, et les domaines Return-Path ne sont souvent pas alignés avec le domaine From. Un échec SPF (l’enregistrement se termine par -all et la vérification échoue) ne devrait donc pas entraîner de rejet tant que DMARC n’a pas été évalué et n’a pas réussi.
  • La seule exception est v=spf1 -all, un enregistrement qui n’autorise aucun usage. Dans ce cas, le serveur de réception (ou l’intermédiaire) peut agir immédiatement 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 rapports, ils ne peuvent ni identifier les flux légitimes qui échouent à l’authentification, 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 des messages 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 du M³AAWG associés (voir aussi l’index des documents) :

Voir aussi

• DMARC, sur l’alignement, la syntaxe de l’enregistrement et le passage d’une politique à l’autre
• Meilleures pratiques M3AAWG pour les expéditeurs, sur les exigences de DNS direct, de DNS inverse et de HELO dont dépend SPF, et sur DKIM par client dans les pools d’adresses IP partagées
• Index des documents M3AAWG