Résumé

  • RFC 9991 décrit des rapports DMARC détaillés portant sur un message en échec ou sur des incidents semblables ; ils peuvent parvenir rapidement et contenir bien davantage qu'un agrégat.
  • Les balises ruf et fo expriment une demande du propriétaire de domaine. Le récepteur décide encore quels rapports, s'il y en a, il transmet selon sa propre politique, le type d'échec et ses obligations de confidentialité.
  • Daniel Kade propose un reçu de divulgation finalisée : il garde le motif, les catégories de données, la réduction, le quota, le transport, l'accès et l'effacement, mais jamais le corps, les adresses ni la charge malveillante.

Le ticket qui contenait trop de vérité

Un analyste reçoit un signal : plusieurs signatures DKIM ne correspondent plus. Il demande un exemple et obtient un rapport complet. La cause saute aux yeux dans une ligne transformée par un relais. Pourtant, le même fichier révèle aussi une adresse personnelle, le nom d'un projet confidentiel et l'existence d'un transfert vers une boîte que le domaine expéditeur ignorait.

Le diagnostic a réussi. La gouvernance a peut-être échoué.

Cette tension ne vient pas d'une imperfection marginale du format. Le rapport d'échec tire précisément sa valeur de détails qui ont été supprimés d'un rapport agrégé. Plus il éclaire une transaction, plus il peut déplacer vers un nouveau détenteur des faits concernant un expéditeur, un destinataire et un chemin de distribution.

RFC 9991 ne dit pas que la publication d'une adresse ruf rend ces faits exigibles. Elle crée une interface de demande et une grammaire de réponse. Le récepteur reste celui qui détient les octets et doit répondre de leur sortie.

Trois volontés ne forment pas un consentement unique

Le propriétaire de domaine choisit de demander des rapports et publie des options fo. Il indique aussi une ou plusieurs destinations. Le récepteur observe l'échec et décide du type de retour qu'il souhaite éventuellement produire. Le consommateur reçoit ensuite un objet qu'il doit isoler, interpréter, conserver ou supprimer.

Ces trois volontés ne sont ni simultanées ni interchangeables. Une demande DNS ne prouve pas que l'utilisateur dont le message est copié a consenti. L'accord d'une destination externe à recevoir des rapports ne prouve pas que tout contenu disponible lui est nécessaire. La capacité du consommateur à analyser un corps ne prouve pas que le récepteur devait le transmettre.

Le texte normatif est clair sur le point central : le récepteur détermine les catégories de rapports, le cas échéant, à partir de sa politique, de l'échec et des options demandées. Cette formule protège une faculté essentielle d'Internet : un protocole commun peut coordonner des acteurs sans retirer à chacun sa décision locale.

Le détail n'est pas un verdict

RFC 9991 complète le format ARF avec des champs liés à DMARC. Identity-Alignment indique quels mécanismes n'ont pas authentifié un identifiant aligné, ou none lorsque les méthodes tentées ont réussi. Des éléments DKIM ou SPF peuvent préciser le constat du récepteur.

Ils ne transforment pas ce constat en cause certaine. Une rupture peut provenir d'une modification intermédiaire, d'une configuration, d'une erreur temporaire ou d'un usage non autorisé. Le champ ne démontre ni l'intention humaine, ni le caractère dangereux du contenu, ni la justesse de la disposition finale. Il ne distribue pas non plus un droit de consultation.

Le format ARF sépare une partie lisible, une partie structurée et une copie d'en-têtes ou de message. Cette séparation aide les outils. Elle ne rend pas les trois parties équivalentes. Le texte explicatif peut être erroné ; les données dérivées ont une portée définie ; la copie originale apporte des éléments supplémentaires et un risque supplémentaire.

Le consommateur doit donc savoir quelle proposition chaque partie soutient. « La signature n'est pas alignée », « le message est malveillant » et « cet opérateur peut voir le destinataire » sont trois décisions différentes.

L'autorisation externe ferme une porte, pas toutes les portes

Quand une destination se trouve hors du domaine organisationnel, RFC 9991 réutilise le contrôle DNS de RFC 9990. La destination confirme qu'elle accepte de recevoir des rapports pour le domaine demandeur. Ce mécanisme empêche qu'un propriétaire désigne arbitrairement un tiers et l'inonde de données ou de contenus hostiles.

La preuve est importante, mais limitée. Elle ne valide ni la proportionnalité, ni la durée de conservation, ni les personnes habilitées, ni une éventuelle sous-traitance ultérieure. Le document avertit même qu'une adresse apparemment interne peut transférer les rapports ailleurs. L'itinéraire final ne se déduit donc pas du premier destinataire.

Il faut préserver deux questions : « cette destination accepte-t-elle ce flux ? » et « ce rapport précis, avec ces catégories de données, doit-il franchir la frontière ? ». Une seule réponse DNS ne peut pas porter les deux.

Réduire sans fabriquer un identifiant permanent

Le standard recommande une utilisation ciblée et limitée dans le temps, des URI maîtrisées, un transport sûr et la réduction des en-têtes ou des corps. Le document consacré à la caviardisation propose une transformation stable et résistante aux collisions : deux valeurs identiques donnent le même jeton, ce qui permet de regrouper des incidents sans dévoiler la chaîne initiale.

Ce bénéfice crée une nouvelle surface. Un jeton stable reste corrélable. Utilisé avec la même clé sur plusieurs clients, périodes ou objectifs, il peut devenir une identité parallèle. Le système doit donc enregistrer la version de la transformation, sa portée, sa durée et la séparation des clés. Là où aucune corrélation n'est nécessaire, un jeton à usage unique ou une simple catégorie peut être préférable.

La réduction doit aussi rester utile. Trop de données transmettent une conversation ; trop peu de données donnent un fichier inexploitable qui conserve malgré tout un coût de garde. Le bon minimum dépend de la question diagnostique, pas d'un modèle unique appliqué à tous les messages.

Un quota produit une observation échantillonnée

Un adversaire peut envoyer une masse de messages usurpant le domaine d'une victime et pousser des récepteurs participants à générer des rapports vers cette victime. RFC 9991 exige donc une limitation du débit sortant. Il autorise aussi le regroupement d'incidents semblables ou l'abandon du surplus : le but est d'identifier des conditions différentes, non de compter chaque échec.

L'absence d'un rapport devient ambiguë. Elle peut signifier qu'aucun échec n'a eu lieu, que le récepteur ne participe pas, que sa politique protège le contenu, que la condition a été regroupée, que le quota a été atteint ou que le transport a échoué. Une hausse peut révéler un nouveau problème ou seulement un changement de politique de génération.

Le consommateur ne doit donc pas convertir ce flux en dénominateur. Il lui faut un contexte de fenêtre, de regroupement et de quota. Le récepteur peut conserver des compteurs bornés par motif sans reconstituer une archive de chaque message.

La preuve transporte aussi la menace

Le rapport peut reproduire des liens d'hameçonnage, des pièces jointes malveillantes ou du contenu conçu pour tromper un lecteur et un analyseur. RFC 9991 recommande l'isolation, les bacs à sable, la segmentation et un accès réservé à des personnes formées. Une prévisualisation automatique dans une boîte ordinaire peut étendre l'incident.

L'alignement DMARC du flux de rapports réduit certains risques d'usurpation du transport. Il ne nettoie pas le contenu embarqué et ne certifie pas chaque assertion. Authentifier l'émetteur du rapport, neutraliser la charge, autoriser l'analyste et justifier la rétention sont des contrôles séparés.

Ici, la réussite peut être un refus : pièce jointe supprimée, MIME inconnu mis en quarantaine, décompression plafonnée, indexation générale interdite. Un parseur qui termine n'a pas encore rendu l'objet gouvernable.

Le reçu de divulgation finalisée

Je propose un reçu compact par politique et par exception. Il ne s'agit pas d'une obligation ajoutée à RFC 9991, mais d'une méthode pour rendre la décision révisable.

Le reçu associe domaine de politique, heure et résultat DNS, destinations ruf, condition fo, autorisation externe, version de la politique du récepteur, finalité et échéance. Il précise le type d'échec, le regroupement, le quota et les catégories retenues : champs dérivés, sous-ensemble d'en-têtes, jeton caviardé ou extrait borné.

Il conserve la méthode de réduction et sa portée, le résultat du transport sûr, l'identité fonctionnelle du consommateur, l'isolation, le délai de conservation, l'effacement et le remplacement d'une décision. Il ne conserve ni corps, ni partie locale d'adresse, ni destinataire, ni secret, ni URL active, ni pièce jointe.

Ainsi, la question ultérieure reçoit une réponse précise : ces données ont franchi la frontière pour cette finalité, sous cette politique, pendant cette durée. « Le domaine les avait demandées » ne suffit pas.

Sources

  1. Lu Heng — Souveraineté des données : réalités techniques et pratiques
  2. Lu Heng — Pourquoi BTW Media existe
  3. Lu Heng — The Policy Mirror
  4. IANA — Paramètres du Messaging Abuse Reporting Format
  5. Fiche de RFC 9991
  6. RFC 5322 — Format des messages Internet
  7. RFC 5965 — Format extensible des rapports de messagerie
  8. RFC 6590 — Caviardisation des données sensibles
  9. RFC 6591 — Rapports d'échec d'authentification
  10. RFC 6650 — Création et utilisation des rapports ARF
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — Rapports agrégés DMARC
  14. RFC 9991 — Rapports d'échec DMARC