ARC (Authenticated Received Chain)

ARC (RFC 8617, statut expérimental) répond au problème du flux de messagerie indirect : les services de transfert et les listes de diffusion cassent couramment SPF (nouvelle IP d’envoi) et cassent souvent DKIM (balises d’objet, pieds de page, réécriture du corps), si bien que du courrier transféré légitime échoue à DMARC chez le serveur de réception final. ARC permet à chaque intermédiaire d’enregistrer les résultats d’authentification qu’il a constatés à l’arrivée et de les sceller 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 transmet ce que les intermédiaires ont vu : c’est un signal supplémentaire, pas un remplacement de SPF/DKIM/DMARC, et il ne rend pas à lui seul un message digne de confiance (un spammeur peut sceller son propre spam ; la réputation de l’entité qui scelle compte).

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

Chaque intermédiaire participant (un « scelleur ARC », ARC sealer) 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. Rassembler tous les ARC Sets ; échec 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. Valider la signature de l’AMS la plus récente (l’instantané du message pris par le dernier responsable). Les signatures AMS plus anciennes peuvent, en option, être vérifiées pour établir un point « oldest-pass » (la plus ancienne instance valide).
4. Valider chaque ARC-Seal, par ordre d’instance décroissant : chaque sceau doit être vérifié sur l’ensemble des sets qu’il couvre.
5. Toutes les vérifications réussissent → état de la chaîne pass ; sinon fail.

Une chaîne en échec ou absente signifie simplement qu’ARC n’apporte aucune information exploitable : traitez le message selon ses seuls résultats SPF/DKIM/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 scelle avec un AS dont la valeur cv= reflète l’état de la chaîne qu’il a trouvé.
• 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 sets précédents rompus).
• Les scelleurs ne devraient sceller que 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 évaluations 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/DKIM aligné au premier saut et que chaque scelleur de la chaîne est de confiance, le serveur de réception peut livrer malgré p=reject/p=quarantine.
• C’est exactement la dérogation local_policy / mailing_list que l’on voit dans les rapports agrégés DMARC ; la RFC 8617 suggère d’indiquer dans le commentaire de dérogation à la politique du rapport l’état de validation de la chaîne, les valeurs d=/s= de chaque sceau et l’IP d’origine tirée du premier ARC Set.
• La confiance accordée aux scelleurs repose sur la réputation et dépend de chaque serveur de réception : 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 de faible réputation 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é : ARC est mis en œuvre par les intermédiaires (services de transfert, listes de diffusion, passerelles de sécurité) et honoré par les serveurs de réception. Ce que les expéditeurs devraient faire, c’est publier des enregistrements SPF/DKIM/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 en aval ne détruise pas leur trafic.
• Gmail exige des en-têtes ARC sur le trafic transféré par les services de transfert de gros volumes, dans le cadre de ses consignes pour les expéditeurs ; 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 de contenu que reprend l’AAR
• DKIM : le mécanisme de signature sur lequel reposent l’AMS et l’AS