3. Terminology and Definitions (Terminologie et définitions)

Cette section définit les termes utilisés dans le reste du document.

Les mots-clés « doit (MUST) », « ne doit pas (MUST NOT) », « requis (REQUIRED) », « doit (SHALL) », « ne doit pas (SHALL NOT) », « devrait (SHOULD) », « ne devrait pas (SHOULD NOT) », « recommandé (RECOMMENDED) », « peut (MAY) » et « optionnel (OPTIONAL) » dans ce document doivent être interprétés comme décrit dans [KEYWORDS].

Les lecteurs sont encouragés à se familiariser avec le contenu de [EMAIL-ARCH]. En particulier, ce document définit divers rôles dans l'infrastructure de messagerie qui peuvent apparaître identiques ou séparés dans différents contextes. Par exemple, un propriétaire de domaine pourrait, via les mécanismes de sécurité de messagerie sur lesquels DMARC est basé, déléguer la capacité d'envoyer du courrier en tant que propriétaire de domaine à un tiers ayant un autre rôle. Ce document ne traite pas des distinctions entre ces rôles ; le lecteur est encouragé à se familiariser avec ce matériel avant de continuer.

Les termes suivants sont également utilisés :

Authenticated Identifiers (Identifiants authentifiés) : Les identifiants au niveau du domaine qui sont validés à l'aide de technologies d'authentification sont appelés « identifiants authentifiés ». Voir la Section 4.1 pour plus de détails sur les mécanismes pris en charge.

Author Domain (Domaine de l'auteur) : Le nom de domaine de l'auteur apparent, tel qu'extrait du champ RFC5322.From.

Domain Owner (Propriétaire de domaine) : Une entité ou organisation qui possède un domaine DNS. Le terme « possède » indique ici que l'entité ou l'organisation référencée détient l'enregistrement de ce domaine DNS. Les propriétaires de domaine vont des organisations complexes et distribuées mondialement, aux fournisseurs de services travaillant pour le compte de clients non techniques, aux particuliers responsables de la maintenance de domaines personnels. Cette spécification utilise ce terme comme analogue à un domaine de gestion administrative tel que défini dans [EMAIL-ARCH]. Il peut également se référer aux délégués, tels que les destinataires de rapports, lorsqu'ils sont en dehors de leur domaine de gestion immédiat.

Identifier Alignment (Alignement des identifiants) : Lorsque le domaine dans l'adresse RFC5322.From correspond à un domaine validé par SPF ou DKIM (ou les deux), il a un alignement des identifiants.

Mail Receiver (Récepteur de courrier) : L'entité ou organisation qui reçoit et traite le courrier électronique. Les récepteurs de courrier exploitent un ou plusieurs agents de transfert de courrier (MTAs) faisant face à Internet.

Organizational Domain (Domaine organisationnel) : Le domaine qui a été enregistré auprès d'un registraire de noms de domaine. En l'absence de méthodes plus précises, des heuristiques sont utilisées pour déterminer cela, car ce n'est pas toujours le cas que le nom de domaine enregistré soit simplement un domaine DNS de premier niveau plus un composant (par exemple, « example.com », où « com » est un domaine de premier niveau). Le domaine organisationnel est déterminé en appliquant l'algorithme trouvé dans la Section 3.2.

Report Receiver (Destinataire de rapport) : Un opérateur qui reçoit des rapports d'un autre opérateur mettant en œuvre le mécanisme de rapport décrit dans ce document. Un tel opérateur pourrait recevoir des rapports sur ses propres messages, ou des rapports sur des messages liés à un autre opérateur. Ce terme s'applique collectivement aux composants système qui reçoivent et traitent ces rapports et aux organisations qui les exploitent.

3.1. Identifier Alignment (Alignement des identifiants)

Les technologies d'authentification de courrier électronique authentifient divers aspects (et disparates) d'un message individuel. Par exemple, [DKIM] authentifie le domaine qui a apposé une signature au message, tandis que [SPF] peut authentifier soit le domaine qui apparaît dans la partie RFC5321.MailFrom (MAIL FROM) de [SMTP], soit le domaine RFC5321.EHLO/HELO, ou les deux. Il peut s'agir de domaines différents, et ils ne sont généralement pas visibles par l'utilisateur final.

DMARC authentifie l'utilisation du domaine RFC5322.From en exigeant qu'il corresponde (soit aligné avec) un identifiant authentifié. Le domaine RFC5322.From a été sélectionné comme identité centrale du mécanisme DMARC car il s'agit d'un champ d'en-tête de message obligatoire et donc garanti d'être présent dans les messages conformes, et la plupart des agents utilisateurs de messagerie (MUAs) représentent le champ RFC5322.From comme l'expéditeur du message et rendent une partie ou la totalité du contenu de ce champ d'en-tête aux utilisateurs finaux.

Ainsi, ce champ est celui utilisé par les utilisateurs finaux pour identifier la source du message et constitue donc une cible privilégiée pour les abus. De nombreuses sources de courrier électronique de haut niveau, telles que les fournisseurs de services de messagerie, exigent que l'agent d'envoi soit authentifié avant que le courrier électronique ne puisse être généré. Ainsi, pour ces boîtes aux lettres, le mécanisme décrit dans ce document fournit aux utilisateurs finaux destinataires des preuves solides que le message a effectivement été créé par l'agent qu'ils associent à cette boîte aux lettres, si l'utilisateur final sait que ces diverses protections ont été fournies.

Les noms de domaine dans ce contexte doivent être comparés de manière insensible à la casse, conformément à [DNS-CASE].

Il est important de noter que l'alignement des identifiants ne peut pas se produire avec un message qui n'est pas valide selon [MAIL], en particulier un message avec un champ RFC5322.From malformé, absent ou répété, car dans ce cas, il n'existe aucun moyen fiable de déterminer une politique DMARC qui s'applique au message. En conséquence, l'opération DMARC est basée sur le fait que l'entrée est un objet message RFC5322 valide, et la gestion de ces cas non conformes est hors de la portée de cette spécification. Une discussion plus approfondie de cela peut être trouvée dans la Section 6.6.1.

Chacune des technologies d'authentification sous-jacentes que DMARC prend en entrée produit des domaines authentifiés comme sorties lorsqu'elles réussissent. Du point de vue de DMARC, chacune peut être exploitée en mode « strict » ou en mode « relaxed » (relâché). Un propriétaire de domaine sélectionnerait normalement le mode strict s'il souhaitait que les récepteurs de courrier appliquent le traitement DMARC uniquement aux messages portant un domaine RFC5322.From correspondant exactement aux domaines que ces mécanismes vérifieront. Le mode relâché peut être utilisé lorsque l'opérateur souhaite également affecter les flux de messages portant des sous-domaines des domaines vérifiés.

3.1.1. DKIM-Authenticated Identifiers (Identifiants authentifiés DKIM)

DMARC permet que l'alignement des identifiants, basé sur le résultat d'une authentification DKIM, soit strict ou relâché. (Notez que ceux-ci ne sont pas liés aux modes de canonicalisation « simple » et « relaxed » de DKIM.)

En mode relâché, les domaines organisationnels du domaine de signature authentifié [DKIM] (tiré de la valeur de la balise « d= » dans la signature) et celui du domaine RFC5322.From doivent être égaux si les identifiants doivent être considérés comme alignés. En mode strict, seule une correspondance exacte entre les deux noms de domaine pleinement qualifiés (FQDNs) est considérée comme produisant un alignement des identifiants.

Pour illustrer, en mode relâché, si une signature DKIM validée se vérifie avec succès avec un domaine « d= » de « example.com », et que l'adresse RFC5322.From est « [email protected] », le domaine DKIM « d= » et le domaine RFC5322.From sont considérés comme « alignés ». En mode strict, ce test échouerait, car le domaine « d= » ne correspond pas exactement au FQDN de l'adresse.

Cependant, une signature DKIM portant une valeur de « d=com » ne permettrait jamais un résultat « aligné », car « com » devrait apparaître sur toutes les listes de suffixes publics (voir Annexe A.6.1) et ne peut donc pas être un domaine organisationnel.

L'alignement des identifiants est requis car un message peut porter une signature valide de n'importe quel domaine, y compris les domaines utilisés par une liste de diffusion ou même un acteur malveillant. Par conséquent, le simple fait de porter une signature valide ne suffit pas pour inférer l'authenticité du domaine de l'auteur.

Notez qu'un seul courrier électronique peut contenir plusieurs signatures DKIM, et il est considéré comme un « pass » DMARC si une signature DKIM est alignée et se vérifie.

3.1.2. SPF-Authenticated Identifiers (Identifiants authentifiés SPF)

DMARC permet que l'alignement des identifiants, basé sur le résultat d'une authentification SPF, soit strict ou relâché.

En mode relâché, le domaine authentifié [SPF] et le domaine RFC5322.From doivent avoir le même domaine organisationnel. En mode strict, seule une correspondance exacte de domaine DNS est considérée comme produisant un alignement des identifiants.

Notez que l'identité RFC5321.HELO n'est généralement pas utilisée dans le contexte de DMARC (sauf lorsqu'elle est requise pour « simuler » un chemin inverse autrement nul), même si une implémentation « SPF pur » selon [SPF] vérifierait cet identifiant.

Par exemple, si un message passe un contrôle SPF avec un domaine RFC5321.MailFrom de « cbg.bounces.example.com », et que la partie adresse du champ RFC5322.From contient « [email protected] », l'identifiant de domaine RFC5321.MailFrom authentifié et le domaine RFC5322.From sont considérés comme « alignés » en mode relâché, mais pas en mode strict.

3.1.3. Alignment and Extension Technologies (Alignement et technologies d'extension)

Si à l'avenir DMARC est étendu pour inclure l'utilisation d'autres mécanismes d'authentification, les extensions devront permettre l'extraction d'identifiant de domaine afin que l'alignement avec le domaine RFC5322.From puisse être vérifié.

3.2. Organizational Domain (Domaine organisationnel)

Le domaine organisationnel est déterminé à l'aide de l'algorithme suivant :

1. Acquérir une liste de « suffixes publics », c'est-à-dire une liste de noms de domaine DNS réservés pour les enregistrements. Certains domaines de premier niveau (TLDs) de pays ont des exigences d'enregistrement spécifiques, par exemple, le Royaume-Uni place les enregistrements d'entreprises sous « .co.uk » ; d'autres TLD tels que « .com » apparaissent dans le registre IANA des domaines DNS de premier niveau. Une liste de suffixes publics est l'union de tous ceux-ci. L'annexe A.6.1 contient quelques discussions sur l'obtention d'une liste de suffixes publics.

2. Décomposer le nom de domaine DNS sujet en un ensemble de « n » étiquettes ordonnées. Numéroter ces étiquettes de droite à gauche ; par exemple, pour « example.com », « com » serait l'étiquette 1 et « example » serait l'étiquette 2.

3. Rechercher dans la liste de suffixes publics le nom qui correspond au plus grand nombre d'étiquettes trouvées dans le domaine DNS sujet. Soit ce nombre « x ».

4. Construire un nouveau nom de domaine DNS en utilisant le nom qui correspondait de la liste de suffixes publics et en lui préfixant l'étiquette « x+1 » du domaine sujet. Ce nouveau nom est le domaine organisationnel.

Ainsi, puisque « com » est un TLD enregistré auprès de l'IANA, un domaine sujet de « a.b.c.d.example.com » aurait un domaine organisationnel de « example.com ».

Le processus de détermination d'un suffixe est actuellement heuristique. Aucune liste n'est garantie d'être précise ou à jour.