Résumé

  • RFC 9990 définit un document XML dans lequel un Mail Receiver transmet au Domain Owner son observation agrégée : politique vue, lignes d’adresses source, volumes et résultats d’authentification sur une période donnée.
  • La confirmation DNS d’une destination externe permet de recevoir le flux de rapports ; elle ne transforme ni le contenu du rapport en vérité complète ni le destinataire en autorité de sanction.

Un écran de supervision sait mettre en scène une conclusion. Une ligne affiche une adresse IP, un nombre élevé, un résultat SPF ou DKIM et une disposition DMARC. Le lecteur voit rapidement « rejet » et croit voir une faute établie. RFC 9990 impose une lecture plus précise : la configuration policy_published est celle qu’a observée le système de réception ; chaque record dit que des adresses IP ont été vues livrant des messages pour le domaine auteur à ce système. L’objet probant est donc localisé avant même d’être agrégé.

Cette localisation n’enlève rien à l’utilité du rapport. Une réception peut signaler qu’un prestataire de diffusion manque dans l’inventaire, qu’une clé n’est plus cohérente ou que des messages semblables se présentent depuis une plage inattendue. Elle interdit simplement d’ajouter ce que le document ne contient pas. Le rapport ne dit pas ce qu’ont vu tous les autres récepteurs. Il ne nomme pas l’auteur humain d’un message. Il n’explique pas l’intention d’une source et ne prouve pas qu’une autre infrastructure aurait pris la même décision de distribution.

Le domaine dangereux commence lorsque cette nuance disparaît de la chaîne d’automatisation. Un score dérivé d’une seule réception peut déclencher une suspension de fournisseur, une alerte au comité exécutif ou une modification de la politique de messagerie. Ces actes peuvent être justifiés après recoupement. Ils ne sont pas contenus dans le XML. Le protocole rend un témoignage technique transmissible ; il ne délègue pas le pouvoir de décider à la ligne qui le transporte.

La période décrit une fenêtre de rapport, non toute l’histoire du trafic

La forme du rapport est stricte : métadonnées du générateur, politique publiée et au moins un enregistrement. Les métadonnées portent notamment le générateur, un identifiant et une plage de dates UTC. RFC 9990 précise que les bornes indiquent la période de rapport, non le premier et le dernier message effectivement observés. Les périodes ne devraient normalement pas se chevaucher et couvrent souvent une journée UTC.

Cette phrase interdit une extrapolation commode. Un rapport journalier ne garantit pas que tout le trafic relatif au domaine a été vu, qu’aucune tentative n’a été rejouée hors fenêtre ou que l’absence d’une ligne signifie l’absence d’un expéditeur. Les résultats DKIM et SPF figurent dans auth_results, mais le RFC les dit non interprétés au regard de DMARC. Une raison de dérogation de politique décrit une décision du récepteur ; elle n’établit pas une vérité sur l’identité, la loyauté ou la responsabilité d’un tiers.

Avant toute mesure forte, il faut donc rapprocher le rapport de faits que l’organisation contrôle : inventaire des sources autorisées, historique DNS et des clés, journaux d’envoi, changements de fournisseur, résultats répétés de récepteurs indépendants et examen humain du contexte. Le fichier brut, son empreinte et le champ affiché dans un tableau de bord doivent rester distingués. « Risque élevé » est une interprétation de l’opérateur du tableau, jamais une donnée native du RFC.

Une destination confirmée n’emporte pas la décision qui suivra

Un Domain Owner peut déclarer, par rua, où il souhaite recevoir les rapports. Cette adresse peut relever d’un prestataire externe. RFC 9990 impose alors une vérification DNS : le Mail Receiver recherche l’enregistrement qui confirme que le Report Consumer accepte cette relation. Sans confirmation positive, l’URI doit être ignorée. Ce mécanisme évite qu’un acteur pointe arbitrairement vers une victime et transforme de nombreux récepteurs en expéditeurs de rapports non désirés.

La réponse est volontairement étroite : cette destination accepte de recevoir ce type de rapport pour cette relation de domaine. Elle n’autorise pas chaque collaborateur à consulter les données, ne fixe ni conservation ni transfert ultérieur, ne rend pas licite une corrélation avec d’autres bases et ne prescrit aucune action envers un expéditeur. RFC 9990 rappelle d’ailleurs que le transfert vers un intermédiaire peut être limité par les politiques de confidentialité ou les conditions d’utilisation du récepteur.

Les rapports agrégés ne contiennent ni contenu des messages, ni adresses de messagerie individuelles, ni adresses IP d’individus ; ils peuvent néanmoins permettre une analyse du trafic au niveau du domaine.

Une entreprise doit donc compléter le DNS par un registre de gouvernance. Pour chaque destinataire externe : domaines admis, finalité, responsable, droits d’accès, transformations autorisées, sous-traitants, durée de conservation, transfert ultérieur, procédure d’incident et preuve de suppression. La relation DNS doit correspondre à ce registre, mais ne le remplace jamais.

Le transport, la syntaxe et la vérité ne sont pas le même contrôle

Les rapports sont envoyés par courriel avec une pièce jointe XML, normalement compressée avec GZIP. Le RFC demande que les flux de feedback eux-mêmes satisfassent DMARC avec un passage aligné, afin de réduire le risque de traiter des rapports frauduleux. Il prévoit aussi des identifiants et des noms de fichier utiles pour repérer les doublons.

Ces contrôles facilitent l’acheminement et le traitement. Ils ne certifient pas les affirmations présentes dans le rapport. Le texte avertit qu’un attaquant peut forger des données en volume afin d’influencer une décision de politique ou d’architecture. Il cite aussi le risque de zip bomb et d’XML bomb contre le décompresseur ou l’analyseur. Un document peut donc arriver au bon endroit, respecter une forme connue et rester mensonger ou dangereux.

La bonne séquence est : budget, contrôle, parse, rapprochement, puis décision. Fixer des limites de taille comprimée et décompressée, de profondeur XML et de temps de traitement avant toute extraction. Conserver l’original sous accès restreint. Lorsque le format est douteux, RFC 9990 permet de le rejeter ou de l’isoler pour échange avec le générateur. Une analyse XML réussie n’équivaut ni à une observation fiable ni à une mesure légitime.

RFC 9989 complète la leçon : selon le rythme des courriels, le Domain Owner peut consommer les rapports agrégés pendant des mois avant d’être certain que tout son trafic est correctement authentifié ; le choix de p dépend de ses besoins. Le rapport nourrit une décision locale. Il ne fabrique pas cette décision.

Interprétation éditoriale : garder une couche commune limitée

Il s’agit ici d’une interprétation éditoriale, non d’une exigence IETF. Une syntaxe commune, un chemin de rapport et une protection contre la réflexion sont des fonctions minimales ; elles n’ont pas à créer une autorité générale sur la politique de messagerie. La chaîne doit rester visible : quel récepteur a observé, quel validateur a accepté, quel responsable a tranché et quel effet a été mesuré.