# ARC (Authenticated Received Chain)

> Référence RFC 8617 : les trois champs d'en-tête ARC, les balises d'instance et de validation de la chaîne, les règles de scellement et de validation, et la façon dont les serveurs de réception s'appuient sur une chaîne intacte pour passer outre les échecs DMARC causés par le transfert.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/arc

Quand un message passe par un service de transfert ou une liste de diffusion, il peut échouer à [DMARC](https://emailmarketing.net/fr/apprendre/authentification/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](https://emailmarketing.net/fr/apprendre/authentification/spf), parce que l'adresse IP d'envoi change, et cassent souvent [DKIM](https://emailmarketing.net/fr/apprendre/authentification/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=` :

| En-tête | Abrév. | Contenu | Signe |
|---|---|---|---|
| `ARC-Authentication-Results` | AAR | Les résultats SPF, DKIM et DMARC (et ARC) que ce saut a constatés à la réception du message, dans le même format que l'[en-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results). | (pas une signature) |
| `ARC-Message-Signature` | AMS | Une signature semblable à celle de DKIM (avec la même syntaxe de balises : `a=`, `b=`, `bh=`, `d=`, `s=`, `h=`, …) sur les **en-têtes et le corps** du message tels que ce saut les a transmis. Par elle, le saut prend la responsabilité des modifications qu'il a apportées. Elle utilise la canonicalisation relaxed, et ne doit pas signer les champs ARC-Seal ou Authentication-Results existants. | En-têtes et corps |
| `ARC-Seal` | AS | Scelle la chaîne elle-même. Il signe **uniquement des champs d'en-tête** (pas le corps) : tous les ARC Sets précédents plus l'AAR et l'AMS de ce saut, dans l'ordre AAR, AMS, AS pour chaque instance. Il porte le verdict de validation de la chaîne `cv=`. | En-têtes ARC uniquement |

### Balises principales

| Balise | Sur | Valeurs et règles |
|---|---|---|
| `i=` | les trois | Le numéro d'instance qui relie un ensemble : **1–50**, augmenté de 1 à chaque saut. Les numéros d'instance doivent former une suite continue 1..N, avec exactement un champ de chaque type pour chaque instance. Plus de 50 ensembles, ou une suite rompue, font échouer la chaîne. |
| `cv=` | ARC-Seal | L'état de validation de la chaîne tel que ce scelleur l'a vu : `none` (aucune chaîne n'existait, il s'agit donc du premier saut), `pass` (la chaîne précédente a été validée) ou `fail` (la chaîne précédente a échoué à la validation). |
| `d=`, `s=`, `a=`, `b=`, `t=` | AMS, AS | Comme dans DKIM : le domaine de scellement, le sélecteur (la clé est publiée à `<selector>._domainkey.<domain>`), l'algorithme, la signature et l'horodatage. |

## 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](https://emailmarketing.net/fr/apprendre/authentification/rapports-agreges-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](https://emailmarketing.net/fr/apprendre/authentification/dmarc), la couche de politique qu'ARC aide à préserver d'un saut à l'autre
- [En-tête Authentication-Results](https://emailmarketing.net/fr/apprendre/authentification/en-tete-authentication-results), le format que reprend l'AAR
- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), le mécanisme de signature sur lequel reposent l'AMS et l'AS