Vidéo : DMARC - Aperçu technique
Nous avons préparé un bref aperçu technique de DMARC :
Cette vidéo fait partie d'une série de vidéos sur tout ce qui concerne DMARC.
La transcription suit :
Cette courte vidéo est un aperçu technique de DMARC - Domain-based Message Authentication, Reporting, and Conformance.
DMARC tente de créer un lien entre le contenu d'un courriel et un domaine en utilisant soit SPF soit DKIM. Pour les curieux, SPF et DKIM sont traités dans des vidéos séparées.
Le contenu du courrier électronique qui intéresse DMARC est le domaine figurant dans l'en-tête From :. L'en-tête From : est à peu près le seul élément d'information qui indique l'identité ou la provenance d'un courriel et qui doit figurer dans ce qui est considéré comme un "courriel bien formé". Pour cette raison, DMARC se base sur le domaine trouvé dans l'en-tête From :.
DMARC ne se base sur aucun autre en-tête, y compris l'en-tête Sender :. Il s'avère que le fait d'autoriser plusieurs clés de politique entraîne une grande confusion et peut même nuire à l'utilité de DMARC lui-même. C'est pourquoi DMARC se base uniquement sur le domaine figurant dans l'en-tête From :.
SPF et DKIM sont deux technologies qui produisent des identifiants stables au niveau du domaine. SPF et DKIM sont des spécifications techniques librement disponibles qui ont été largement mises en œuvre par de nombreux fournisseurs de messagerie électronique. Même si elles fonctionnent de manière différente, DMARC ne s'intéresse qu'aux résultats qu'elles produisent, et si ces résultats ont un rapport avec le domaine trouvé dans l'en-tête From :. Les résultats produits par SPF et DKIM sont appelés "Identifiants authentifiés" dans le monde de DMARC.
Un concept clé de DMARC est "l'alignement des identifiants". Il s'agit d'une façon élégante de dire que les résultats de SPF et DKIM doivent être liés au domaine DMARC pour être utiles. La raison principale en est que les récepteurs ont besoin d'un moyen simple de comprendre si les résultats de SPF et DKIM sont pertinents pour le domaine sur lequel DMARC se base.
Dans les prochaines diapositives de cette vidéo, nous allons examiner différentes combinaisons d'identifiants authentifiés afin d'illustrer pourquoi l'alignement des identifiants est important du point de vue du destinataire d'un courriel.
Dans ce premier exemple, un destinataire a reçu un message dont le domaine DMARC (qui est le domaine figurant dans l'en-tête From :) est "bank.com". De plus, la vérification SPF a donné un domaine de "bank.com". Il n'y avait pas de signature DKIM sur l'e-mail, notre ligne est donc marquée "none". Le destinataire de l'e-mail recherche un signal positif indiquant que l'e-mail peut être relié au domaine "bank.com", et peu lui importe que ce signal provienne de SPF ou de DKIM, du moment qu'il est présent. Dans cet exemple, l'identifiant authentifié provenant de SPF était "bank.com", ce qui correspond exactement au domaine DMARC, et l'e-mail est donc conforme à DMARC.
Dans l'exemple suivant, tout est à peu près identique, sauf que l'identifiant authentifié que SPF a donné est un sous-domaine de bank.com - mail.bank.com. Pour un être humain de chair et d'os, les deux domaines sont évidemment liés. Cependant, il n'existe pas de méthode standard sur Internet pour déterminer si bank.com est un domaine de premier niveau comme .com ou .org ou s'il s'agit d'un domaine de second niveau. Il n'existe pas de méthode standard pour le déterminer. Un autre exemple est bank.co.uk. Il n'existe pas de méthode standard pour indiquer aux machines que "co.uk" est le domaine de premier niveau. Dans le monde de DMARC, le domaine de deuxième niveau s'appelle le domaine organisationnel. En puisant dans certaines ressources de l'Internet, en particulier la liste publique de suffixes maintenue par la Fondation Mozilla, le destinataire d'un courriel peut comprendre que bank.com est le domaine organisationnel et que mail.bank.com est un sous-domaine qui partage le même domaine organisationnel que bank.com. Dans ce cas, le courriel est conforme à la norme DMARC.
Ce troisième exemple montre quelque chose d'intéressant. Au lieu que le SPF donne un identifiant authentifié de bank.com ou un sous-domaine de bank.com, l'identifiant authentifié est banknewsletter.com. Pour autant que nous le sachions, banknewsletter.com est un domaine réel détenu et exploité par la même entité qui possède bank.com. OR.... banknewsletter.com est détenu et exploité par des criminels qui veulent faire croire aux gens qu'ils sont légitimes. Il n'existe tout simplement pas de moyen de maintenir et de communiquer de manière fiable de telles associations entre domaines - que ce soit par les expéditeurs eux-mêmes qui créent des bases de données d'associations ou par les destinataires qui maintiennent les leurs - ces deux tâches seraient entachées d'inexactitudes et annuleraient fondamentalement l'utilité de DMARC. Ainsi, cet e-mail n'est PAS conforme à DMARC et serait affecté par une politique DMARC publiée.
Pour continuer avec le 4ème exemple, l'email est le même sauf que maintenant nous voyons une signature DKIM pour la première fois. Dans cet exemple, DKIM a produit un identifiant authentifié de bank.com, ce qui rend l'exemple conforme à DMARC. En d'autres termes, le destinataire du courrier électronique regarde l'identifiant authentifié provenant du SPF, voit que banknewsletter.com n'a rien à voir avec bank.com et l'ignore tout simplement. Étant donné que le destinataire recherche un signal positif indiquant que le message provient bien de bank.com et que DKIM fournit un tel signal, l'e-mail passe la vérification DMARC.
Ce 5ème exemple montre un email qui est DMARC jusqu'au bout. SPF et DKIM ont tous deux donné des identifiants authentifiés de bank.com. Le récepteur ne se soucie que de trouver un signal positif, donc avoir 2 signaux positifs est doublement bon mais ne signifie rien de plus que "signal positif". La raison pour laquelle il faut envoyer des courriels où SPF et DKIM donnent tous deux de bons résultats est que le fait de disposer des deux technologies permet aux courriels de continuer à être conformes à DMARC même si l'une ou l'autre - pour quelque raison que ce soit - n'est pas disponible ou échoue.
Ce 6e exemple montre la même chose, à la différence que "news.bank.com" est l'identifiant authentifié pour SPF et DKIM. Il est assez courant pour les grandes organisations de déléguer un sous-domaine à un fournisseur de services de messagerie électronique afin que ce dernier puisse envoyer des e-mails au nom de l'organisation. Dans cet exemple, les propriétaires de bank.com ont pu déléguer le sous-domaine "news" à leur fournisseur de services de marketing afin que ce dernier puisse envoyer des messages conformes à la norme DMARC en utilisant bank.com.
Cet exemple artificiel montre que n'importe qui peut enregistrer des domaines et mettre en place SPF et DKIM. Ne serait-ce pas bien si les méchants utilisaient des domaines aussi évidents ? Pourtant, ce n'est pas parce que SPF et DKIM passent et donnent un identifiant authentifié que le courriel est bon ou recherché.
Le dernier exemple montre que le SPF a donné un identifiant authentifié de "bark.com"... comme le bruit que fait un chien. Il s'agit d'une attaque bien connue que certains fraudeurs utilisent pour tromper les humains qui inspectent manuellement les pièces du courrier électronique pour en déterminer la légitimité. Un coup d'œil rapide peut tromper l'œil et faire croire à quelqu'un que "bark" est vraiment une banque. Pire encore, il est possible d'utiliser certaines astuces de codage des caractères pour que les glyphes rendus ressemblent exactement au domaine visé. Les machines ne sont pas dupes de ce genre de supercherie. C'est pourquoi ce sont les machines qui devraient effectuer les contrôles d'alignement des identificateurs, et non les personnes.
Avant de voir à quoi ressemblent les enregistrements DMARC et ce qu'ils peuvent faire, nous allons aborder brièvement la manière dont les enregistrements DMARC sont découverts.
Lorsqu'un récepteur de courrier électronique traite un message dans le contexte de DMARC, il extrait le domaine figurant dans l'en-tête From :. Ce domaine constitue la base de l'endroit où le récepteur recherche tout enregistrement DMARC correspondant. Le récepteur ajoutera un préfixe underbar-dmarc au domaine et demandera au DNS un enregistrement TXT.
Dans l'exemple présenté ici, le domaine extrait est EUROPE.ENG.EXAMPLE.ORG. Le récepteur ajouterait underbar-dmarc à ce domaine et interrogerait le DNS pour essayer de trouver un enregistrement TXT. Mais que se passe-t-il si l'interrogation ne donne rien ou un enregistrement TXT dont le contenu n'a rien à voir avec DMARC. Le récepteur doit alors extraire le domaine organisationnel du domaine... dans ce cas EXAMPLE.ORG, et essayer à nouveau de trouver un enregistrement DMARC en plaçant under-dmarc devant le domaine et en demandant un enregistrement TXT.
De cette façon, la découverte d'un enregistrement DMARC est limitée à deux consultations du DNS. Il y a également quelques ramifications intéressantes dues à cela. Vous pouvez publier un seul enregistrement DMARC au niveau du domaine organisationnel et le faire couvrir tous les sous-domaines. Peu importe si un spammeur crée ses propres sous-domaines, vous pouvez toujours publier un enregistrement DMARC qui les couvre sans avoir à publier des enregistrements DMARC explicites pour tous les sous-domaines imaginables. L'autre avantage est que vous pouvez publier des enregistrements DMARC pour tous vos sous-domaines réels et ces enregistrements DMARC remplaceront ceux publiés au niveau du domaine organisationnel.
Très bien, passons maintenant à ce à quoi ressemblent les enregistrements DMARC et à ce qu'ils peuvent faire.
Les enregistrements DMARC sont de simples listes de paires balise/valeur. Dans cet exemple, le domaine qui a publié cet enregistrement DMARC... nous pouvons dire qu'il s'agit d'un enregistrement DMARC parce qu'il commence par "v=DMARC1 ;"... publie une politique "none" et demande que tous les rapports agrégés basés sur XML soient envoyés à reports@example.org pour traitement. DMARC a été conçu pour permettre aux domaines de collecter des informations sans affecter le courrier électronique... et c'est ainsi que cela se fait - en publiant une politique p=none .
En ce qui concerne les possibilités offertes par les enregistrements DMARC, les options sont assez simples. Tous les enregistrements DMARC doivent commencer par une balise de version de protocole. Ensuite, la politique peut être configurée, vous pouvez configurer une politique qui sera appliquée à tous les sous-domaines.... par exemple si vous savez que votre domaine n'utilise jamais de sous-domaines, vous pouvez publier une politique sp=reject immédiatement tout en collectant uniquement des données sur votre domaine organisationnel à l'aide de p=none. La balise pct est comme un curseur qui va de 0 à 100, de sorte que toute politique publiée peut être déployée lentement... si vous dites pct=1, alors seulement 1 email sur 100 qui aurait autrement été affecté par une politique DMARC sera impacté.
Vous pouvez également indiquer si les identifiants authentifiés fournis par SPF et DKIM doivent ou non correspondre exactement au domaine DMARC. La valeur par défaut de "relaxed" est préférable dans presque tous les cas, mais en "strict mode", vous pouvez interdire l'alignement des identifiants basé sur les sous-domaines, par exemple si vous êtes dans un environnement où vous n'avez pas le contrôle du courrier électronique envoyé en utilisant des sous-domaines délégués.
Les deux balises suivantes, rua et ruf, sont utilisées pour indiquer au monde où envoyer les rapports concernant le domaine. Comme les rapports sont différents, les gens les envoient à différentes adresses électroniques pour les collecter et les analyser.
Les dernières balises concernent la configuration des formats de rapport, des intervalles et du moment où il faut envoyer des copies expurgées des courriels individuels qui échouent à DMARC. Les deux premières balises n'ont qu'une seule valeur et sont donc un peu inutiles, et la dernière option semble désactiver la génération de rapports par certains fournisseurs de rapports en raison de bogues logiciels, donc laissez-les peut-être si vous souhaitez les collecter.
Nous terminerons cette présentation par les différentes politiques que DMARC autorise et par un bref aperçu des deux rapports de retour d'information que DMARC fournit.
Les options de politique de DMARC sont très simples. Vous pouvez publier une politique "aucune" qui signifie simplement "veuillez m'envoyer des rapports sans agir sur les e-mails qui échouent à la vérification DMARC". Vous pouvez publier une politique de "quarantaine" qui demande aux destinataires de classer dans un dossier de courrier indésirable tout courriel qui échoue à la vérification DMARC. Si un dossier spam n'existe pas, le destinataire peut faire tout ce qui est en son pouvoir pour traiter le message avec un degré de suspicion plus élevé, par exemple en augmentant l'agressivité de l'analyse anti-spam.
La dernière politique qui peut être appliquée est la politique de "rejet", qui demande aux destinataires de bloquer - ou de refuser d'accepter - les e-mails qui échouent à la vérification DMARC. Sur l'écran, vous verrez un peu plus sur la balise pct, et comment si vous l'utilisez avec une politique de rejet en place, alors le pourcentage d'e-mails qui n'est pas rejeté en raison de la balise pourcentage sera mis en quarantaine.
Dernière chose, les deux formes de rapports de retour d'information que DMARC peut fournir sont très différentes. Les rapports agrégés basés sur XML sont générés sur un cycle de 24 heures et comprennent des statistiques complètes sur la façon dont un destinataire de courriel voit votre domaine utilisé - y compris tous les courriels qui ont entièrement passé DMARC. Le deuxième type de retour d'information consiste en des copies expurgées des courriels individuels qui ont échoué au test SPF, DKIM ou les deux. Ces rapports ne sont pas toujours disponibles pour des raisons de confidentialité, de volume ou parce qu'ils ne sont pas nécessaires au bon déploiement de DMARC.
dmarcian traite les deux types de retour d'information afin de rendre DMARC facile à déployer. Nous répondrons volontiers aux questions concernant DMARC ou le service dmarcian.
Pour commencer avec DMARC, visitez dmarcian.com.
Des questions ? Contactez support@dmarcian.com. Merci d'avoir regardé !
