Résumé

  • RFC 9990 normalise le rapport agrégé par lequel un récepteur expose les résultats SPF et DKIM, les alignements DMARC, la disposition évaluée, les exceptions locales et les volumes observés.
  • Cet objet est une synthèse, non un registre message par message : une période peut mêler deux politiques, des rapports peuvent se chevaucher et le texte avertit que les données peuvent être falsifiées.
  • Daniel Kade propose un reçu de recours à l’agrégat, limité aux métadonnées nécessaires : identité du générateur, fenêtre, époque de politique, empreinte du fichier, traitement des doublons et décision finale.

La précision du format ne garantit pas l’exhaustivité du regard

Un propriétaire de domaine reçoit plusieurs fichiers XML. Les lignes sont propres, les compteurs s’additionnent, les sources inattendues ressortent immédiatement. Cette vue peut révéler une clé DKIM mal déployée ou un prestataire qui émet sans avoir été intégré au dispositif d’authentification. Elle accomplit donc une fonction essentielle.

Mais la forme exacte des colonnes ne dit pas si tous les récepteurs importants ont envoyé un rapport. Un récepteur peut ne pas participer, rencontrer un problème de génération, mettre des données en cache ou les abandonner lorsque la livraison échoue. Le nombre affiché est le total déclaré par un ensemble d’observateurs, pas le dénominateur certain de tout le courrier ayant circulé.

Ce n’est pas une faiblesse cachée du protocole. L’agrégation évite de distribuer le contenu des messages et rend possible une observation à grande échelle. La faute commencerait lorsque le consommateur transformerait cette économie de données en prétention à l’exhaustivité.

Ce que contient réellement le rapport

RFC 9990 est un document de normalisation IETF publié en mai 2026. Il décrit le volet agrégé de DMARC et remplace la partie correspondante de RFC 7489 avec les spécifications compagnes. Le propriétaire publie une destination rua; le récepteur évalue les messages, regroupe ses observations et tente d’envoyer le rapport aux destinations admissibles.

Les métadonnées nomment l’organisation déclarante, le Report-ID et une période UTC. La configuration de politique observée accompagne le domaine concerné. Chaque ligne rassemble une adresse IP source, un compte, une disposition évaluée, les alignements et les identifiants d’authentification. Les résultats SPF et DKIM restent descriptibles séparément. Si le récepteur n’applique pas l’action demandée, il peut indiquer une politique locale, une liste de diffusion, un mode de test, un transfert de confiance ou une autre raison.

Ces champs ne décrivent pas la totalité du destin d’un message. Le compte porte sur les messages reçus même si un autre filtre les bloque ensuite. Une disposition DMARC ne devient donc pas une preuve de remise, de placement en boîte de réception ou de lecture. Le rapport observe un plan de contrôle parmi d’autres.

Une ligne agrégée efface des jointures

La ligne devient utile en fusionnant des événements partageant la même combinaison. Elle montre une tendance sans livrer les messages eux-mêmes. En échange, elle ne conserve pas une identité stable pour chacun d’eux. Le consommateur ne peut pas rejouer l’ordre exact, attribuer chaque action d’un filtre ultérieur ni relier mécaniquement chaque compte à un incident individuel.

Cette limite doit rester visible lorsqu’une machine déclenche une mesure. Une hausse brutale peut venir d’un nouvel expéditeur, mais aussi d’un récepteur supplémentaire, d’un retard de livraison, d’un changement de regroupement ou d’un chevauchement. L’agrégat justifie une enquête ; il n’établit pas à lui seul la cause.

Le sujet probant est donc : « ce récepteur déclare avoir regroupé ces observations selon ces règles ». Dire « le flux de courrier était exactement ainsi » ajoute une portée que le fichier ne porte pas.

Une seule politique affichée peut couvrir deux régimes

Lorsqu’un propriétaire modifie son enregistrement DMARC en cours de période, les récepteurs ne voient pas tous le changement au même instant. RFC 9990 autorise plusieurs rapports séparés. Il autorise aussi un rapport unique qui mélange des décisions prises sous l’ancienne et la nouvelle politique, alors même qu’il ne contient qu’un élément policy_published.

Le texte reconnaît le coût qu’aurait une surveillance permanente de chaque transition à l’échelle d’Internet. Il demande donc aux propriétaires et aux consommateurs de s’attendre à des rapports mixtes. Cette souplesse opérationnelle a une contrepartie : la politique affichée n’est pas forcément l’étiquette temporelle de chaque message compté.

Si un domaine passe de l’observation au rejet à midi, un rapport journalier peut présenter la configuration finale tout en contenant des décisions antérieures. Calculer rétrospectivement que tous les échecs auraient subi la nouvelle action serait injustifié. La bonne réponse consiste à qualifier l’époque comme mixte ou indéterminée et à limiter l’usage du total.

L’authentification du transport garde une portée bornée

Le courrier qui transporte un rapport doit lui-même obtenir un résultat DMARC aligné. Un canal sécurisé est recommandé. Lorsqu’une destination se trouve sous une autre autorité de domaine, celle-ci doit publier l’autorisation DNS attendue. Sans confirmation, le récepteur ignore l’URI.

Ces contrôles réduisent l’usurpation du message de rapport et empêchent qu’un domaine dirige massivement des fichiers vers une victime non consentante. Ils ne certifient pas chaque assertion XML. RFC 9990 avertit précisément que des données de rapport peuvent être falsifiées afin d’influencer une politique ou une décision d’architecture.

Une identité de générateur acceptable, l’intégrité du fichier, la vérité des observations et l’autorité de recommander une action restent quatre propositions. Elles peuvent se soutenir mutuellement ; elles ne sont pas interchangeables.

Report-ID aide à reconnaître, pas à démontrer l’absence de recouvrement

Le Report-ID doit être unique parmi les rapports destinés au même domaine. L’identifiant et le nom de fichier facilitent la reconnaissance d’une retransmission ; le même fichier doit être réutilisé lors d’un nouvel envoi. Le consommateur dispose ainsi d’une clé d’idempotence raisonnable.

Le cas des recouvrements partiels demeure ouvert. RFC 9990 laisse au consommateur la possibilité de rejeter, supprimer, examiner ou accepter un doublon. Lorsque deux fenêtres ne se recouvrent qu’en partie, il n’existe pas de méthode claire pour isoler l’effet du recouvrement ; les données peuvent devoir être acceptées ou refusées en bloc.

Additionner tous les Report-ID différents comme s’ils représentaient nécessairement des populations distinctes crée une certitude artificielle. Le choix de déduplication doit accompagner le chiffre obtenu, surtout si ce chiffre déclenche une action difficilement réversible.

Autoriser un destinataire externe ne valide pas son interprétation

Une entreprise peut confier la réception à un spécialiste. L’autorisation DNS du destinataire externe prouve qu’il consent à recevoir des rapports pour le domaine demandeur. Elle peut être retirée, sous réserve des caches DNS. C’est une excellente séparation entre demande et consentement.

Elle ne vaut pas approbation des règles de normalisation du prestataire. Le propriétaire doit encore savoir quels fichiers ont été acceptés, comment les périodes ont été rapprochées, quelles extensions ont été ignorées et qui a converti une anomalie en recommandation.

Le tableau de bord peut rester externalisé. La responsabilité de comprendre la chaîne de preuve, elle, ne disparaît pas avec le contrat.

Une meilleure preuve ne doit pas recréer une surveillance individuelle

Le rapport agrégé ne contient ni corps de message, ni adresse individuelle, ni caractéristique permettant d’identifier un utilisateur. Cette minimisation mérite d’être conservée. Les métadonnées de trafic restent toutefois sensibles, notamment lorsqu’elles passent par un intermédiaire ou remontent vers un opérateur de suffixe public.

Il serait donc contre-productif de compenser l’absence de journal événementiel par la collecte de toute la correspondance. Pour décider avec prudence, il suffit souvent de préserver l’origine du fichier et le chemin de la décision.

Le processeur doit aussi se défendre contre le fichier lui-même. Une archive GZIP ou un parseur XML peut subir une attaque d’épuisement de ressources. La réussite du parsing ne doit pas être confondue avec l’admission probante : un fichier lisible peut rester en quarantaine si son identité, son chevauchement ou son contexte de politique sont douteux.

Le reçu de recours à l’agrégat

Daniel Kade propose de créer, au moment où le rapport soutient une décision, un reçu distinct et peu intrusif. Ce reçu n’est pas exigé par RFC 9990.

Il lie d’abord l’artefact : Report-ID exact, nom d’origine, empreinte cryptographique, taille, heure de réception, résultat d’authentification et identité retenue du générateur. Il enregistre ensuite le périmètre déclaré : domaine de politique, début et fin UTC, version de schéma et caractère complet, retardé ou partiel de la fenêtre.

Le troisième groupe décrit l’époque de politique. La valeur policy_published est conservée avec l’indication « unique », « mixte » ou « inconnue ». Le quatrième documente les doublons : rapports liés, fenêtres qui se croisent, décision de remplacer, fusionner, rejeter, accepter ou mettre en attente, règle appliquée et responsable.

Le cinquième groupe rend la transformation reproductible : version du parseur, empreinte du jeu de lignes normalisé, nombre de lignes écartées, extensions ignorées et contrôles d’anomalie. On peut ainsi relier le tableau de bord au fichier sans stocker les messages.

Enfin, le reçu nomme le recours : enquête, contact d’un expéditeur, rotation de clé, changement de politique, attente, retour arrière ou remplacement. Il conserve le seuil, le décideur et la voie de correction.

Le but n’est pas d’affaiblir le rapport, mais de lui attribuer exactement l’autorité qu’il peut justifier.

Limites de preuve

Les sources vérifiées décrivent les champs, les périodes mixtes, les doublons, l’autorisation externe, les risques de confidentialité et l’avertissement sur les données falsifiées. Elles ne mesurent ni le taux d’adoption de RFC 9990, ni la fréquence des recouvrements, ni le comportement d’un acteur nommé.

Cet Article ne dit pas que les rapports sont de simples opinions, que les processeurs externes sont indignes de confiance ou que DMARC devrait conserver chaque message. Il affirme une limite plus étroite : l’agrégat normalisé est le compte rendu d’un observateur opérationnel. Une décision grave doit conserver la jointure entre ce compte rendu, l’époque de politique, le traitement des recouvrements et l’autorité qui agit.

Sources