6. Policy (Politique)
Les politiques DMARC sont publiées par les propriétaires de domaine (Domain Owner) et appliquées par les destinataires de courrier (Mail Receiver).
Un propriétaire de domaine annonce la participation DMARC d'un ou plusieurs de ses domaines en ajoutant un enregistrement TXT DNS (décrit dans la section 6.1) à ces domaines. Ce faisant, les propriétaires de domaine font des demandes spécifiques aux destinataires de courrier concernant la disposition des messages prétendant provenir de l'un des domaines du propriétaire de domaine et la fourniture de retours sur ces messages.
Un propriétaire de domaine peut choisir de ne pas participer à l'évaluation DMARC par les destinataires de courrier. Dans ce cas, le propriétaire de domaine refuse simplement d'annoncer sa participation à ces schémas. Par exemple, si les résultats des vérifications d'autorisation de chemin ne doivent pas être considérés comme faisant partie du résultat DMARC global pour un domaine d'auteur donné, alors le propriétaire de domaine ne publie pas d'enregistrement de politique SPF pouvant produire un résultat de réussite SPF.
Un destinataire de courrier implémentant le mécanisme DMARC devrait (SHOULD) faire un effort de bonne foi pour adhérer à la politique DMARC publiée par le propriétaire de domaine lorsqu'un message échoue au test DMARC. Étant donné que les flux de courrier peuvent être compliqués (en raison du transfert, des services d'usurpation de domaine RFC5322.From existants, etc.), les destinataires de courrier peuvent (MAY) dévier de la politique publiée par un propriétaire de domaine pendant le traitement des messages et devraient (SHOULD) rendre disponible le fait et la raison de la déviation au propriétaire de domaine via les rapports de retour, en utilisant spécifiquement la fonctionnalité « PolicyOverride » du rapport agrégé (voir section 7.2).
6.1. DMARC Policy Record (Enregistrement de politique DMARC)
Les préférences DMARC du propriétaire de domaine sont stockées sous forme d'enregistrements TXT DNS dans des sous-domaines nommés « _dmarc ». Par exemple, le propriétaire de domaine de « example.com » publierait les préférences DMARC dans un enregistrement TXT à « _dmarc.example.com ». De même, un destinataire de courrier souhaitant interroger les préférences DMARC concernant le courrier avec un domaine RFC5322.From de « example.com » émettrait une requête TXT au DNS pour le sous-domaine de « _dmarc.example.com ». Les données de préférence DMARC situées dans le DNS seront ci-après appelées « enregistrement DMARC ».
L'utilisation par DMARC du service de noms de domaine (Domain Name Service) est motivée par l'utilisation par DMARC des noms de domaine et la nature de la requête qu'il effectue. L'exigence de requête correspond au DNS, pour obtenir des informations paramétriques simples. Il utilise une méthode établie de stockage des informations, associée au nom de domaine cible, à savoir un enregistrement TXT isolé qui est limité au contexte DMARC. L'utilisation du DNS comme service de requête présente l'avantage de réutiliser une infrastructure d'exploitation, d'administration et de gestion extrêmement bien établie, plutôt que d'en créer une nouvelle.
Selon [DNS], un enregistrement TXT peut comprendre plusieurs objets « character-string ». Dans ce cas, le module effectuant l'évaluation DMARC doit (MUST) concaténer ces chaînes en joignant les objets dans l'ordre et en analysant le résultat comme une seule chaîne.
6.2. DMARC URIs (URI DMARC)
[URI] définit une syntaxe générique pour identifier une ressource. Le mécanisme DMARC utilise ceci comme format par lequel un propriétaire de domaine spécifie la destination pour les deux types de rapports pris en charge.
L'endroit où de tels URI sont spécifiés (voir section 6.3) permet de fournir une liste de ceux-ci. Un rapport est normalement envoyé à chaque URI listé dans l'ordre fourni par le propriétaire de domaine. Les destinataires peuvent (MAY) imposer une limite au nombre d'URI auxquels ils enverront des rapports mais doivent (MUST) prendre en charge la capacité d'envoyer à au moins deux. La liste des URI est séparée par des virgules (ASCII 0x2C).
Chaque URI peut avoir associé une taille de rapport maximale qui peut lui être envoyée. Ceci est accompli en ajoutant un point d'exclamation (ASCII 0x21), suivi d'une indication de taille maximale, avant une virgule de séparation ou un point-virgule de terminaison.
Ainsi, un URI DMARC est un URI dans lequel toutes les virgules ou points d'exclamation sont encodés en pourcentage selon [URI], suivi d'un point d'exclamation OPTIONNEL et d'une spécification de taille maximale, et, s'il y a des URI de rapport supplémentaires dans la liste, d'une virgule et de l'URI suivant.
Par exemple, l'URI mailto:[email protected]!50m demanderait qu'un rapport soit envoyé par courrier électronique à « [email protected] » tant que la charge utile du rapport ne dépasse pas 50 mégaoctets.
Une définition formelle est fournie dans la section 6.4.
6.3. General Record Format (Format d'enregistrement général)
Les enregistrements DMARC suivent la syntaxe extensible « tag-value » pour les enregistrements de clés basés sur DNS définis dans DKIM [DKIM].
La section 11 crée un registre pour les balises DMARC connues et enregistre l'ensemble initial défini dans ce document. Seules les balises définies dans ce document ou dans des extensions ultérieures, et donc ajoutées à ce registre, doivent être traitées ; les balises inconnues doivent (MUST) être ignorées.
6.4. Formal Definition (Définition formelle)
(Voir RFC 7489 pour la syntaxe ABNF complète)
6.5. Domain Owner Actions (Actions du propriétaire de domaine)
Les propriétaires de domaine publient des politiques DMARC pour indiquer leurs préférences en matière de gestion des échecs d'authentification.
6.6. Mail Receiver Actions (Actions du destinataire de courrier)
Les destinataires de courrier interrogent les politiques DMARC et les appliquent selon la politique locale.
6.7. Policy Enforcement Considerations (Considérations sur l'application de la politique)
Les destinataires de courrier devraient considérer divers facteurs lors de l'application des politiques DMARC, y compris les scénarios de transfert légitimes et les opérations de liste de diffusion.