← RFC Reference

ARC — Chaîne de réception authentifiée

Pourquoi cette RFC existe

Le réacheminement d'e-mails est le talon d'Achille de SPF et DKIM. Quand un message est réaché par une liste de diffusion, un alias ou une règle .forward :

• SPF échoue car l'IP du serveur de réacheminement n'est pas autorisée par l'enregistrement SPF de l'expéditeur original.
• DKIM échoue si l'intermédiaire modifie le message (ajout de pieds de page, réécriture d'en-têtes, changement d'encodage).

Quand SPF et DKIM échouent tous les deux à la destination finale, DMARC échoue aussi, et le message peut être rejeté ou mis en quarantaine — même s'il a été légitimement envoyé et réaché par une infrastructure de confiance.

ARC (Authenticated Received Chain), défini dans RFC 8617, résout cela en permettant à chaque intermédiaire d'enregistrer un instantané des résultats d'authentification qu'il a observés, puis de signer cet instantané. Le destinataire final peut examiner la chaîne pour déterminer que le message a été authentifié au point d'origine, même si les contrôles SPF et DKIM directs échouent maintenant.

Comment cela fonctionne

Les trois ensembles d'en-têtes ARC

Chaque intermédiaire qui traite un message ajoute un ensemble de trois en-têtes, numérotés avec un compteur d'instance (i=) qui s'incrémente à chaque saut :

Exemple de chaîne de responsabilité

Détails techniques clés

La validation de la chaîne (cv) - Balise

L'en-tête ARC-Seal inclut une balise cv= (chain validation) avec l'une de trois valeurs :

• cv=none — Ceci est le premier ensemble ARC de la chaîne (i=1). Il n'y a pas de chaîne antérieure à valider.
• cv=pass — Tous les ensembles ARC précédents de la chaîne ont été validés et leurs scellés sont intacts.
• cv=fail — La chaîne est rompue. Un ensemble ARC antérieur a échoué la validation. Une fois que la chaîne est marquée fail, elle ne peut pas être réparée.

ARC et annulation DMARC

ARC ne remplace pas DMARC. Au lieu de cela, il fournit des informations supplémentaires qu'un destinataire peut utiliser pour prendre une décision d'annulation DMARC. La logique du destinataire pourrait être :

1. Vérifier DMARC directement. S'il passe, livrer normalement.
2. Si DMARC échoue, vérifier la chaîne ARC. Si la chaîne est valide (cv=pass) et le destinataire fait confiance aux intermédiaires de la chaîne, annuler l'échec DMARC.
3. Si la chaîne ARC est invalide ou les intermédiaires ne sont pas de confiance, appliquer la politique DMARC comme d'habitude.

La décision de faire confiance à un intermédiaire est une politique locale. Gmail, par exemple, entretient une liste de signataires ARC de confiance (principaux fournisseurs de listes de diffusion, systèmes de messagerie universitaires, etc.).

Exigences de signature

Les signatures ARC utilisent le même format cryptographique que DKIM (RSA-SHA256 ou Ed25519). Le domaine de signature publie sa clé publique ARC en DNS à un sélecteur sous _domainkey, identique à la publication de clé DKIM :

Numérotation des instances

Les ensembles ARC sont numérotés séquentiellement à partir de i=1. Chaque intermédiaire ajoute un ensemble avec le numéro suivant. Le destinataire final valide la chaîne en vérifiant tous les scellés dans l'ordre. Si un scellé échoue ou qu'une instance est manquante, la chaîne entière est invalide.

Ce qu'ARC ne fait pas

• ARC n'authentifie pas directement l'expéditeur original — il enregistre et transmet les résultats d'authentification des sauts antérieurs.
• ARC ne crée pas la confiance dans les intermédiaires — le destinataire doit indépendamment décider quels signataires ARC faire confiance.
• ARC n'empêche pas la modification du message — il enregistre quel était l'état d'authentification avant modification.

Erreurs courantes

• Supposer qu'ARC est universellement respecté : ARC est toujours Expérimental (pas Standards Track). Bien que Gmail, Microsoft et autres principaux fournisseurs le supportent, tous les destinataires ne le font pas. Vous ne devriez pas vous fier à ARC seul pour la délivrabilité.
• Casser la chaîne : Si un intermédiaire qui ne supporte pas ARC se situe entre deux qui le font, la chaîne a une lacune. Le prochain saut conscient d'ARC verra des numéros d'instance manquants et marquera la chaîne comme échouée.
• Ne pas publier les clés DNS ARC : Si vous exploitez une liste de diffusion ou un service de réacheminement et ajoutez des en-têtes ARC mais ne publiez pas la clé publique correspondante en DNS, les vérificateurs ne peuvent pas valider votre ARC-Seal, cassant la chaîne.
• Confondre ARC avec DKIM : Bien qu'ARC réutilise le format de signature DKIM, ils servent des objectifs différents. DKIM authentifie le domaine de signature comme responsable du message. ARC enregistre une chaîne de responsabilité documentant l'état d'authentification à chaque saut.
• Ignorer ARC en tant que propriétaire de domaine : Bien que les propriétaires de domaine ne génèrent pas d'en-têtes ARC, la compréhension d'ARC aide à diagnostiquer les problèmes de délivrabilité quand les messages passent par des listes de diffusion ou services de réacheminement.

Impact sur la délivrabilité

• Sauve le courrier réaché : La valeur principale d'ARC est d'empêcher le courrier légitime d'être rejeté après réacheminement. Les listes de diffusion, les alias universitaires et les règles de réacheminement d'entreprise bénéficient tous d'ARC.
• Confiance ARC de Gmail : Gmail utilise ARC pour prendre les décisions d'annulation DMARC. Si un message échoue DMARC mais a une chaîne ARC valide d'un intermédiaire de confiance, Gmail peut livrer le message à la boîte de réception au lieu de le rejeter.
• Support Microsoft : Microsoft 365 évalue aussi les chaînes ARC et les utilise dans sa logique d'annulation DMARC, particulièrement pour les messages de listes de diffusion de confiance.
• Active des politiques DMARC plus strictes : Sans ARC, passer de p=none à p=reject risque de bloquer le courrier réaché légitime. ARC atténue ce risque, rendant plus sûr pour les propriétaires de domaine l'adoption de politiques DMARC fortes.
• Préparation future : À mesure que plus d'intermédiaires adoptent ARC, l'écosystème du courrier électronique devient plus résiliant. Supporter ARC positionne votre infrastructure pour bénéficier d'une chaîne de réacheminement de confiance croissante.

Related RFCs