Aller au contenu principal

4. Overview (Aperçu)

Cette section fournit un aperçu général de la conception et du fonctionnement de l'environnement DMARC.

4.1. Authentication Mechanisms (Mécanismes d'authentification)​

Les mécanismes suivants pour déterminer les identifiants authentifiés sont pris en charge dans cette version de DMARC :

  • [DKIM] : qui fournit un identifiant au niveau du domaine dans le contenu de la balise « d= » d'un champ d'en-tête DKIM-Signature validé.

  • [SPF] : qui peut authentifier à la fois le domaine trouvé dans une commande [SMTP] HELO/EHLO (l'identité HELO) et le domaine trouvé dans une commande SMTP MAIL (l'identité MAIL FROM). DMARC utilise le résultat de l'authentification SPF de l'identité MAIL FROM. La Section 2.4 de [SPF] décrit le traitement MAIL FROM pour les cas où la commande MAIL a un chemin nul.

4.2. Key Concepts (Concepts clés)​

Les politiques DMARC sont publiées par le propriétaire de domaine et récupérées par le récepteur de courrier pendant la session SMTP, via le DNS.

La fonction de filtrage de DMARC est basée sur le fait que le domaine du champ RFC5322.From soit aligné avec (correspond à) un nom de domaine authentifié provenant de SPF ou DKIM. Lorsqu'une politique DMARC est publiée pour le nom de domaine trouvé dans le champ RFC5322.From, et que ce nom de domaine n'est pas validé par SPF ou DKIM, la disposition de ce message peut être affectée par cette politique DMARC lors de la livraison à un récepteur participant.

Il est important de noter que les mécanismes d'authentification employés par DMARC n'authentifient qu'un domaine DNS et n'authentifient pas la partie locale de tout identifiant d'adresse électronique trouvé dans un message, ni ne valident la légitimité du contenu du message.

Le composant de feedback de DMARC implique la collecte d'informations sur les messages reçus prétendant provenir du domaine organisationnel pour des rapports agrégés périodiques au propriétaire de domaine. Les paramètres et le format de tels rapports sont discutés dans les sections ultérieures de ce document.

Un récepteur de courrier compatible DMARC peut également générer des rapports par message qui contiennent des informations relatives aux messages individuels qui échouent à SPF et/ou DKIM. Les rapports d'échec par message sont une source d'information utile lors du débogage des déploiements (si les messages peuvent être déterminés comme légitimes même en échouant à l'authentification) ou dans l'analyse des attaques. La capacité pour de tels services est activée par DMARC mais définie dans d'autres documents référencés tels que [AFRF].

Un message satisfait les vérifications DMARC si au moins l'un des mécanismes d'authentification pris en charge :

  1. produit un résultat « pass », et

  2. produit ce résultat sur la base d'un identifiant qui est aligné, tel que défini dans la Section 3.

4.3. Flow Diagram (Diagramme de flux)​

    +---------------+
    | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
    +---------------+                        .           .         .
        |                                    .           .         .
        V                                    V           V         .
    +-----------+     +--------+       +----------+ +----------+   .
    |   MSA     |<***>|  DKIM  |       |   DKIM   | |    SPF   |   .
    |  Service  |     | Signer |       | Verifier | | Verifier |   .
    +-----------+     +--------+       +----------+ +----------+   .
        |                                    ^            ^        .
        |                                    **************        .
        V                                                 *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
     | sMTA |------->( other MTAs )----->| rMTA |         *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
                                            |             * ........
                                            |             * .
                                            V             * .
                                     +-----------+        V V
                       +---------+   |    MDA    |     +----------+
                       |  User   |<--| Filtering |<***>|  DMARC   |
                       | Mailbox |   |  Engine   |     | Verifier |
                       +---------+   +-----------+     +----------+

     MSA = Mail Submission Agent (Agent de soumission de courrier)
     MDA = Mail Delivery Agent (Agent de livraison de courrier)

Le diagramme ci-dessus montre un flux simple de messages à travers un système compatible DMARC. Les lignes pleines indiquent le flux réel des messages, les lignes pointillées impliquent des requêtes DNS utilisées pour récupérer la politique de message liée aux schémas d'authentification de message pris en charge, et les lignes astérisque indiquent l'échange de données entre les modules de traitement de messages et les modules d'authentification de messages. « sMTA » est le MTA d'envoi, et « rMTA » est le MTA de réception.

En essence, les étapes sont les suivantes :

  1. Le propriétaire de domaine construit une politique SPF et la publie dans sa base de données DNS conformément à [SPF]. Le propriétaire de domaine configure également son système pour la signature DKIM comme décrit dans [DKIM]. Enfin, le propriétaire de domaine publie via le DNS une politique de traitement des messages DMARC.

  2. L'auteur génère un message et remet le message au service de soumission de courrier désigné du propriétaire de domaine.

  3. Le service de soumission transmet les détails pertinents au module de signature DKIM afin de générer une signature DKIM à appliquer au message.

  4. Le service de soumission relaie le message maintenant signé à son service de transport désigné pour le router vers son ou ses destinataires prévus.

  5. Le message peut passer par d'autres relais mais arrive finalement au service de transport d'un destinataire.

  6. Le service de livraison du destinataire effectue des vérifications d'authentification SPF et DKIM en transmettant les données nécessaires à leurs modules respectifs, chacun nécessitant des requêtes aux données DNS du domaine de l'auteur (lorsque les identifiants sont alignés ; voir ci-dessous).

  7. Les résultats de ceux-ci sont transmis au module DMARC avec le domaine de l'auteur. Le module DMARC tente de récupérer une politique du DNS pour ce domaine. Si aucune n'est trouvée, le module DMARC détermine le domaine organisationnel et répète la tentative de récupération d'une politique du DNS. (Ceci est décrit plus en détail dans la Section 6.6.3.)

  8. Si une politique est trouvée, elle est combinée avec le domaine de l'auteur et les résultats SPF et DKIM pour produire un résultat de politique DMARC (un « pass » ou « fail ») et peut éventuellement provoquer la génération de l'un des deux types de rapports (non illustré).

  9. Le service de transport du destinataire livre soit le message dans la boîte de réception du destinataire, soit prend d'autres mesures de politique locale basées sur le résultat DMARC (non illustré).

  10. Lorsque demandé, le service de transport du destinataire collecte des données de la session de livraison de messages à utiliser pour fournir un feedback (voir Section 7).

Dernière mise à jour le