ARC (Authenticated Received Chain)

Quand un message passe par un service de transfert ou une liste de diffusion, il peut échouer à DMARC chez le serveur de réception final alors que l’expéditeur d’origine l’avait correctement authentifié. Les services de transfert et les listes de diffusion cassent couramment SPF, parce que l’adresse IP d’envoi change, et cassent souvent DKIM, parce qu’ils ajoutent des balises d’objet ou des pieds de page, ou réécrivent le corps. C’est le problème du flux de messagerie indirect.

ARC, défini dans la RFC 8617 (statut expérimental), y répond. Chaque intermédiaire enregistre les résultats d’authentification qu’il a constatés à l’arrivée du message, et les scelle cryptographiquement, ce qui construit une chaîne de responsabilité vérifiable. Le serveur de réception final peut alors voir que le message était correctement authentifié avant que le service de transfert ne le modifie, et peut choisir de passer outre un échec DMARC.

ARC rapporte ce que les intermédiaires ont vu. C’est un signal supplémentaire, pas un remplacement de SPF, DKIM et DMARC, et il ne rend pas à lui seul un message digne de confiance. Un spammeur peut sceller son propre spam, donc la réputation de l’entité qui scelle compte.

L’ARC Set : trois champs d’en-tête par saut

Chaque intermédiaire qui participe (un « scelleur ARC ») ajoute un ARC Set de trois en-têtes, qui portent tous le même numéro d’instance i= :

Balises principales

Validation de la chaîne (algorithme du serveur de réception)

1. Rassemblez tous les ARC Sets. La chaîne échoue s’il y en a plus de 50, ou si la suite d’instances 1..N est rompue, dupliquée ou incomplète.
2. Si l’ARC-Seal de l’instance la plus élevée porte cv=fail, la chaîne échoue.
3. Validez la signature de l’AMS la plus récente (l’instantané du message pris par le dernier responsable). Les signatures AMS plus anciennes peuvent aussi être vérifiées, pour trouver le point le plus ancien où le message passait encore.
4. Validez chaque ARC-Seal, de l’instance la plus élevée à la plus basse. Chaque sceau doit être vérifié sur tous les ensembles qu’il couvre.
5. Si toutes les vérifications réussissent, l’état de la chaîne est pass. Sinon, il est fail.

Une chaîne en échec ou absente signifie simplement qu’ARC n’apporte aucune information exploitable. Jugez le message sur ses résultats SPF, DKIM et DMARC habituels.

Règles de scellement

• Un scelleur enregistre les résultats qu’il a constatés dans un nouvel AAR, signe le message avec une AMS, puis le scelle avec un AS dont la valeur cv= reflète l’état de la chaîne qu’il a trouvée.
• Si le scelleur a trouvé une chaîne mal formée ou en échec, il ne doit pas la prolonger comme si elle était valide. Il scelle avec cv=fail, et la portée b= de l’AS DOIT couvrir uniquement l’ARC Set créé par le MTA qui a détecté l’échec (et non les ensembles précédents rompus).
• Les scelleurs devraient sceller uniquement le courrier qu’ils ont réellement traité et évalué. Sceller revient à affirmer une responsabilité, garantie par la réputation du domaine de scellement.

Comment les serveurs de réception et les évaluateurs DMARC utilisent ARC

• Un évaluateur DMARC peut, au titre de sa politique locale, accepter les résultats d’authentification d’une chaîne ARC validée. Si le message échoue maintenant à DMARC, mais que l’AAR le plus ancien montre un pass SPF ou DKIM aligné au premier saut et que le serveur de réception fait confiance à chaque scelleur de la chaîne, le serveur de réception peut livrer le message malgré p=reject ou p=quarantine.
• C’est exactement la dérogation local_policy ou mailing_list que l’on voit dans les rapports agrégés DMARC. La RFC 8617 suggère d’indiquer, dans le commentaire du rapport sur la dérogation à la politique, l’état de validation de la chaîne, les valeurs d= et s= de chaque sceau, et l’adresse IP d’origine tirée du premier ARC Set.
• La confiance accordée aux scelleurs repose sur la réputation et varie d’un serveur de réception à l’autre. Les grands fournisseurs tiennent des listes de services de transfert et d’opérateurs de listes dont ils honorent les sceaux. Un pass ARC venant d’un scelleur inconnu, ou d’un scelleur à la réputation faible, ne change généralement rien.

Ce qu’il faut retenir pour la délivrabilité

• Les expéditeurs ne peuvent pas déployer ARC pour améliorer leur propre délivrabilité. Ce sont les intermédiaires (services de transfert, listes de diffusion, passerelles de sécurité) qui le mettent en œuvre, et les serveurs de réception qui l’honorent. Ce que les expéditeurs devraient faire, c’est publier des enregistrements SPF, DKIM et DMARC solides, pour que l’AAR du premier saut enregistre un pass aligné.
• Les opérateurs de services de transfert, de listes de diffusion ou de passerelles de filtrage devraient sceller avec ARC (et conserver les en-têtes d’origine), pour que l’application de DMARC plus loin sur le trajet ne détruise pas leur trafic.
• Dans le cadre de ses consignes pour les expéditeurs, Gmail exige des en-têtes ARC sur le trafic des services de transfert de gros volumes. Microsoft, Google et d’autres grands fournisseurs scellent et honorent ARC.

Voir aussi

• DMARC, la couche de politique qu’ARC aide à préserver d’un saut à l’autre
• En-tête Authentication-Results, le format que reprend l’AAR
• DKIM, le mécanisme de signature sur lequel reposent l’AMS et l’AS