APR : des rapports agrégés sur la performance de livraison

APR (Aggregate Performance Reporting) est une proposition déposée à l'IETF sous la forme d'un draft individuel, draft-brotman-aggregate-performance-reporting, rédigé par Alex Brotman (Comcast). L'idée est de transposer à la performance de livraison ce que DMARC a fait pour l'authentification : un domaine expéditeur publie dans le DNS une adresse de réception, et les routeurs qui le souhaitent lui envoient périodiquement un rapport agrégé décrivant ce qu'il est advenu de ses messages. Le document est un draft individuel, non adopté par un groupe de travail : il peut être modifié, abandonné ou repris sous une autre forme, et aucun routeur ne s'est engagé publiquement à produire ces rapports. Cette page présente la proposition telle qu'elle est formulée, sans préjuger de sa suite.

Le problème visé#

Un expéditeur sait aujourd'hui, grâce aux rapports DMARC, si ses messages sont authentifiés. Il ne sait pas, de façon structurée, s'ils ont été acceptés, différés, rejetés ou classés en indésirable. Ces informations existent chez les routeurs mais ne sont accessibles que de manière fragmentée :

• par les codes de réponse SMTP, que l'expéditeur doit collecter et interpréter lui-même sur ses propres serveurs ;
• par les boucles de rétroaction (feedback loops), limitées aux plaintes ;
• par les outils postmaster (postmaster tools) de certains gros routeurs, chacun avec son interface, ses métriques et ses conditions d'accès.

APR propose un canal unique, normalisé et automatisable, à l'initiative du domaine expéditeur, sur le modèle du rua de DMARC.

Le principe#

Trois éléments, tels que décrits dans le draft :

1. Un enregistrement DNS publié par le domaine expéditeur, indiquant l'adresse à laquelle les rapports doivent être envoyés. Le domaine concerné est celui que le routeur a authentifié, typiquement via DKIM ou SPF aligné, ce qui évite qu'un tiers réclame les rapports d'un domaine qu'il ne contrôle pas.
2. Un rapport agrégé produit par le routeur à intervalle régulier, regroupant par domaine, par adresse IP émettrice ou par période des compteurs : messages acceptés, différés temporairement, rejetés, et le cas échéant répartition entre boîte de réception et dossier indésirable, avec des catégories de motifs.
3. Un transport par courrier électronique vers l'adresse publiée, comme pour DMARC, le format et le découpage précis des rapports étant définis par le draft.

À quoi ressemblerait l'enregistrement#

Le format exact appartient au draft et peut changer d'une version à l'autre. À titre d'illustration, la proposition suit la convention des enregistrements TXT sous un label préfixé par un tiret bas, avec une étiquette de version et une adresse de réception :

_apr.example.com.  IN TXT  "v=APR1; rua=mailto:apr-reports@example.com"

Comme pour DMARC, l'envoi de rapports vers un domaine tiers nécessiterait une forme d'autorisation côté destinataire, afin qu'un domaine ne puisse pas inonder de rapports une adresse qui ne les a pas demandés.

Ce que cela changerait pour les expéditeurs#

Si la proposition aboutissait et que des routeurs l'adoptaient, un expéditeur pourrait :

• mesurer son taux d'acceptation par routeur sans dépendre de ses propres journaux ;
• détecter rapidement un placement en indésirable ou une vague de rejets liés à la réputation ;
• comparer la performance de plusieurs flux ou sous-domaines avec une métrique commune ;
• intégrer ces données dans les mêmes outils que les rapports DMARC.

Les limites annoncées sont les mêmes que pour DMARC : les rapports sont agrégés, donc sans détail par message ; ils dépendent de la bonne volonté de chaque routeur ; et la granularité des motifs reste à la discrétion de l'émetteur du rapport.

Ce qu'il faut faire aujourd'hui#

Rien n'est à publier. Un enregistrement _apr posé maintenant ne déclencherait aucun rapport, puisque personne n'en envoie, et devrait être revu si le format change. Les sources d'information actuelles restent les codes SMTP de vos serveurs, les boucles de rétroaction et les outils postmaster. Suivre l'évolution du draft sur le Datatracker et, le cas échéant, son éventuelle adoption par un groupe de travail, suffit.

Ce que SenderRadar en montre#

SenderRadar n'affiche pas d'indicateur APR, le mécanisme n'étant ni adopté ni déployé. La page du domaine présente les mécanismes de rapport effectivement en place, en particulier les destinations déclarées dans la politique DMARC et dans TLS-RPT. SenderRadar s'appuie sur sa propre base d'analyse pour suivre l'apparition de nouveaux types d'enregistrements lorsque des propositions comme APR progressent.

Références#

• draft-brotman-aggregate-performance-reporting (IETF Datatracker)
• RFC 7489 – DMARC, modèle de rapport agrégé dont s'inspire la proposition
• RFC 5965 – An Extensible Format for Email Feedback Reports (ARF)