ARC pour les e-mails expliqué (version courte et utile) — quand il aide le courrier transféré

ARC en un paragraphe (ce qu’il fait, ce qu’il ne fait pas)

ARC est un mécanisme permettant à un intermédiaire de messagerie (un relais de transfert, une liste de diffusion, une passerelle) d’enregistrer les résultats d’authentification qu’il a observés lors de la réception d’un message, puis de sceller cryptographiquement cet enregistrement afin que les récepteurs en aval puissent décider s’ils lui font confiance. Concrètement : il aide un récepteur à accepter un message qui échoue SPF ou DKIM après transfert, en permettant au récepteur de voir une déclaration vérifiable « au niveau du forwarder, ce message était authentifié ».

ARC n’est pas un remplacement de SPF, DKIM ou DMARC. C’est une chaîne de preuves. Il ne rend pas un message falsifié authentique ; il fournit simplement une piste de preuves digne de confiance quand l’authentification a été cassée par des comportements normaux de transit (comme les forwarders qui changent l’enveloppe sender, ou les listes qui modifient le corps).

Pourquoi le transfert casse SPF/DKIM/DMARC (et pourquoi c’est normal)

SPF échoue parce que le forwarder est celui qui se connecte

SPF vérifie si l’IP qui se connecte est autorisée à envoyer du courrier pour le domaine de l’enveloppe-from (MAIL FROM / Return-Path). Quand le fournisseur d’Alice envoie à un forwarder, SPF peut réussir. Quand le forwarder envoie ensuite à votre fournisseur de boîte aux lettres, SPF évalue alors l’IP du forwarder par rapport au domaine d’Alice. À moins que l’SPF d’Alice n’autorise explicitement ce forwarder (ce qu’il ne fera pas), SPF échoue.

Ce n’est pas un bug. SPF fait exactement ce pour quoi il a été conçu : lier l’IP de connexion à une identité. Le transfert change l’IP de connexion. Fin de l’histoire.

DKIM échoue quand des intermédiaires modifient le contenu signé

DKIM signe certains en-têtes et (souvent) le corps. Un forwarder qui ne modifie pas le message peut préserver DKIM. Une liste de diffusion qui ajoute un pied de page, reformatte les lignes, modifie les balises Subject ou normalise les limites MIME peut invalider la signature. Certains systèmes ré-encodent aussi le contenu (quoted-printable vs base64) ou réordonner des en-têtes d’une manière qui casse des choix de signature fragiles.

DMARC échoue parce qu’il dépend de SPF/DKIM et de l’alignement

DMARC dit : soit SPF soit DKIM doit passer, et celui qui passe doit s’aligner avec le domaine visible From: (alignement strict ou relâché selon la politique). Quand le transfert provoque la défaillance de SPF et que les listes cassent DKIM, DMARC échoue. Si l’expéditeur a une politique « reject », votre récepteur est invité à ignorer le message.

Blague n°1 : L’authentification des e-mails, c’est comme un système de badges de musée — parfaitement logique jusqu’à ce que quelqu’un vous tienne la porte, et soudain vous êtes « non autorisé » dans la boutique de souvenirs.

Qu’est-ce que change ARC ?

ARC ne ressuscite pas SPF au dernier saut. Il n’oblige pas DKIM à passer après qu’une liste a réécrit le message. Il donne au récepteur une déclaration scellée émise par un intermédiaire : « Quand je l’ai reçu, il a passé SPF/DKIM/DMARC (ou pas). J’ai aussi vu ces identifiants. » Les récepteurs peuvent choisir d’accepter en se basant sur cette chaîne quand c’est raisonnable et que l’intermédiaire est digne de confiance.

Les parties d’ARC : AAR, AMS, AS (et ce que chacune apporte)

AAR : Authentication-Results (tel qu’observé par l’intermédiaire)

ARC transporte un en-tête ARC-Authentication-Results (AAR). Il ressemble à l’en-tête standard Authentication-Results que vous voyez chez les récepteurs, mais il est inséré par l’intermédiaire ARC. Il contient l’évaluation de l’intermédiaire des résultats SPF/DKIM/DMARC au moment où il a traité le message.

Pourquoi c’est important : c’est la donnée « qu’est-ce que le forwarder a observé ? ». Sans scellement, il serait trivial à falsifier. Les autres parties d’ARC remédient à cela.

AMS : Message Signature (lie le message à cet ensemble ARC)

ARC ajoute un en-tête ARC-Message-Signature (AMS). Il signe le contenu du message (en-têtes et éventuellement le corps) tel qu’il a été vu à ce saut. Cela aide les parties en aval à savoir que l’AAR correspond à l’état spécifique du message, et non à une revendication recopiée.

L’AMS n’est pas « la signature DKIM ». C’est la signature de l’intermédiaire sur le message tel qu’il l’a traité, avec des sémantiques spécifiques à ARC.

AS : Seal (protège la chaîne)

L’en-tête ARC-Seal (AS) scelle l’ensemble, incluant des références aux ensembles ARC précédents, formant ainsi une chaîne. Chaque saut participant incrémente un compteur d’instance i=. Une chaîne complète est une série d’ensembles ARC : i=1, i=2, i=3… chacun avec AAR/AMS/AS.

Le récepteur vérifie la chaîne et décide s’il lui fait confiance. La vérification peut réussir alors que la confiance échoue encore. C’est le but : la cryptographie prouve l’intégrité, pas la qualité.

La confiance est une politique, pas des mathématiques

ARC peut vous dire « cette chaîne n’a pas été modifiée ». Il ne peut pas vous dire « ce forwarder est compétent » ou « cette passerelle n’est pas compromise ». Les récepteurs combinent généralement la validation ARC avec la réputation et des heuristiques sur les intermédiaires.

Une citation qui devrait trôner près de chaque pipeline de réception : « L’espérance n’est pas une stratégie. » — idée paraphrasée souvent attribuée à Gordon Sullivan (maxime de leadership largement utilisée en opérations).

Quand ARC aide le courrier transféré (et quand c’est de la poudre aux yeux)

ARC aide quand un intermédiaire de confiance casse l’authentification en aval

ARC brille quand le message est légitime à l’entrée d’une organisation, mais est transféré ou traité d’une façon qui casse SPF/DKIM au moment où il atteint le récepteur final. Cas typiques :

• Transfert simple (un utilisateur transfère vers un autre fournisseur de boîte).
• Passerelles de messagerie sécurisées qui analysent et parfois réécrivent les messages (protection d’URL, sandboxing des pièces jointes).
• Listes de diffusion qui ajoutent des pieds de page ou changent les balises Subject, cassant DKIM.
• Systèmes de ticketing qui réinjectent le courrier dans le flux de travail.
• Relais entrants multi-locataires où le « premier récepteur » est un appliance, pas le fournisseur de boîtes.

ARC n’aide pas quand le message n’a jamais été authentifié

Si le message échoue SPF/DKIM/DMARC dès la première évaluation compétente, ARC ne fait que préserver la mauvaise nouvelle. C’est utile pour les enquêtes, mais cela ne sauve pas la délivrabilité.

ARC peut nuire si vous le traitez comme un passe-partout

Si vous commencez à faire confiance à ARC provenant de sources aléatoires, vous avez réinventé « laissez-moi usurper n’importe qui ». ARC doit avoir du sens principalement pour les intermédiaires que vous exploitez, contractez ou pour lesquels vous avez des raisons de croire qu’ils sont de haute qualité. Pour les autres, traitez ARC comme un signal, pas comme une clé universelle.

ARC complète, ne remplace pas, SRS et la bonne hygiène des listes

SRS (Sender Rewriting Scheme) peut réparer SPF pour les forwarders en réécrivant l’enveloppe-from afin que SPF s’aligne sur le domaine du forwarder. C’est très utile, mais pas universellement déployé. Les listes de diffusion peuvent préserver DKIM en évitant les modifications du corps ou en utilisant la réécriture From compatible DMARC (« list rewriting ») ou le « reply-to munging ». Ce sont autant des décisions politiques et produit que techniques. ARC est un pont pragmatique quand vous ne pouvez pas empêcher le monde de transférer.

Faits intéressants & historique (court et concret)

1. ARC est né parce que DMARC fonctionnait — une fois que les grands expéditeurs ont commencé à publier « p=reject », les forwarders et les listes ont ressenti le rayon d’action.
2. Les listes de diffusion ont été des victimes précoces de DMARC strict : les pieds de page et balises sujet cassent souvent DKIM, et SPF ne survit pas au transfert.
3. ARC est normalisé dans RFC 8617 (2019), ce qui est relativement récent pour l’infrastructure e-mail.
4. Le compteur « instance » (i=) dans les en-têtes ARC n’est pas optionnel ; c’est ainsi que les récepteurs savent l’ordre voulu de la chaîne.
5. ARC réutilise la cryptographie de type DKIM (clés publiques dans DNS, signatures sur des en-têtes canoniques), ce qui le rend implémentable dans les piles mail existantes.
6. ARC ne prétend pas que l’expéditeur est bon ; il affirme qu’un intermédiaire a observé des résultats d’authentification à un moment donné et les a scellés.
7. Les récepteurs peuvent accepter un message avec DMARC fail si la chaîne ARC se vérifie et que l’intermédiaire est digne de confiance — c’est un choix de politique, pas un mandat du protocole.
8. ARC est l’une des rares normes sur le « problème du transfert » qui reconnaît le milieu parfois confus des middleboxes plutôt que de prétendre qu’elles n’existent pas.

Playbook de diagnostic rapide

La manière la plus rapide de déboguer les problèmes ARC est de cesser de penser en termes d’« ARC bon/mauvais » et de répondre à trois questions : (1) Le message s’est-il authentifié quelque part ? (2) Quelque chose l’a-t-il cassé ensuite ? (3) La chaîne est-elle vérifiable et provient-elle d’un intermédiaire que vous connaissez ?

Première étape : identifier la décision du récepteur final

• Recherchez l’en-tête Authentication-Results du dernier saut.
• Notez les résultats SPF/DKIM/DMARC et tout résultat d’évaluation ARC (certains récepteurs ajoutent arc=pass/fail).
• Décision : si le récepteur indique déjà que DMARC a passé, ARC est probablement sans impact pour la délivrabilité ; il peut rester utile pour l’audit.

Deuxième étape : inspecter la structure de la chaîne ARC

• Comptez les ensembles ARC par i=.
• Vérifiez que vous avez AAR + AMS + AS pour chaque instance.
• Décision : des instances manquantes ou hors ordre signifient généralement une implémentation défaillante ou un message modifié au milieu de la chaîne.

Troisième étape : valider la cryptographie et les clés DNS

• Confirmez que le scellement ARC et la signature AMS se valident contre les clés DNS pour le(s) domaine(s) signataires.
• Décision : si la validation échoue, on ne peut pas se fier à ARC. Corrigez le signataire, le DNS, ou le traitement qui a altéré les en-têtes.

Quatrième étape : déterminer où l’authentification a été cassée

• Comparez les signatures DKIM : laquelle a échoué, quel domaine a signé, et si le corps a été modifié.
• Vérifiez SPF : quel saut a causé le décalage d’IP de connexion.
• Décision : si l’intermédiaire est le fautif, décidez de préserver DKIM, d’utiliser SRS, ou de vous reposer sur ARC plus la confiance du récepteur.

Tâches pratiques : commandes, sorties et décisions (12+)

Les commandes ci-dessous supposent que vous avez accès à une passerelle mail ou à un hôte de débogage capable de lire des messages stockés (par exemple depuis une quarantaine, la source brute d’un système de ticketing, ou une copie du spool MTA). Les exemples utilisent des outils Linux courants plus les utilitaires OpenDKIM quand pertinent. Adaptez les chemins et noms de service à votre environnement.

Task 1: Pull the raw message and isolate ARC headers

cr0x@server:~$ sed -n '1,/^$/p' message.eml | egrep '^(ARC-|Authentication-Results:|Received:|From:|Return-Path:|DKIM-Signature:|Message-ID:)'
Return-Path: <billing@example.com>
Received: from mx.sender.example (203.0.113.10) by forwarder.corp.example ...
ARC-Authentication-Results: i=1; forwarder.corp.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=corp.example; s=arc1; ...
ARC-Seal: i=1; a=rsa-sha256; d=corp.example; s=arc1; cv=none; ...
Authentication-Results: mx.receiver.example; dkim=fail header.d=example.com; spf=fail smtp.mailfrom=billing@example.com; dmarc=fail header.from=example.com
From: "Billing" <billing@example.com>
Message-ID: <...>

Ce que cela signifie : Vous avez un ensemble ARC en i=1 créé par corp.example, prétendant que le message avait passé chez le forwarder. Le récepteur voit maintenant des échecs.

Décision : Passez à la validation ARC ; si la chaîne se valide et que vous faites confiance à corp.example, vous pouvez considérer le message comme un échec d’authentification dû au transfert et le traiter comme légitime.

Task 2: Count ARC instances and check for completeness

cr0x@server:~$ grep -E '^ARC-(Authentication-Results|Message-Signature|Seal):' -n message.eml | sed -E 's/.* i=([0-9]+).*/i=\1/' | sort | uniq -c
      3 i=1

Ce que cela signifie : Trois en-têtes ARC pour i=1 implique un ensemble ARC complet (AAR+AMS+AS) pour cette instance.

Décision : Si vous voyez moins de 3 par instance, attendez-vous à ce que les récepteurs méprisent la chaîne ou la considèrent comme malformée.

Task 3: Verify ARC seal and AMS with OpenDKIM (when available)

cr0x@server:~$ opendkim-testmsg -A -d corp.example -s arc1 < message.eml
opendkim-testmsg: ARC-Seal pass (i=1)
opendkim-testmsg: ARC-Message-Signature pass (i=1)

Ce que cela signifie : Le message correspond à ce que le signataire ARC a scellé, et les clés DNS pour arc1 sous corp.example valident.

Décision : Si cela échoue, ARC ne peut pas être utilisé pour justifier l’acceptation du courrier. Vous corrigerez la configuration du signataire, le DNS, la canonicalisation ou le traitement des en-têtes qui altère le message.

Task 4: Fetch the ARC public key from DNS and sanity-check it

cr0x@server:~$ dig +short TXT arc1._domainkey.corp.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."

Ce que cela signifie : ARC utilise la publication DNS à la manière de DKIM. Si cet enregistrement manque, est incorrect ou tronqué, la validation échoue.

Décision : Si le TXT est mal splitté ou absent, corrigez le DNS. Si vous avez fait une rotation de clés, confirmez les caches et la propagation.

Task 5: Check DMARC policy of the original sender domain

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=r"

Ce que cela signifie : Un alignement DKIM strict (adkim=s) plus reject signifie que de petites déviations d’authentification seront sanctionnées.

Décision : Si vous opérez un forwarder pour vos utilisateurs, vous devez planifier ARC et/ou SRS ; sinon vous continuerez à perdre des messages.

Task 6: Inspect SPF policy and understand why forwarding fails

cr0x@server:~$ dig +short TXT example.com | head -n 2
"v=spf1 ip4:203.0.113.0/24 include:_spf.provider.example -all"

Ce que cela signifie : L’IP du forwarder n’est pas listée, donc SPF échoue chez le récepteur final lorsque le forwarder renvoie le message.

Décision : Ne « corrigez » pas cela en ajoutant l’IP de votre forwarder au SPF d’un autre domaine (vous ne le pouvez pas). Utilisez SRS ou ARC, ou préservez DKIM.

Task 7: Check if DKIM broke due to message modification (body hash mismatch)

cr0x@server:~$ opendkim-testmsg -v < message.eml | sed -n '1,20p'
opendkim-testmsg: dkim=fail (body hash did not verify)
opendkim-testmsg: key retrieved from DNS

Ce que cela signifie : La clé de signature existe, mais le corps a été modifié après signature.

Décision : Identifiez le modificateur (pied de page de liste, réécriture d’URL par la passerelle, filtre de contenu). Soit cessez de modifier, signez de nouveau (avec votre propre DKIM/ARC), soit comptez sur ARC quand les récepteurs vous font confiance.

Task 8: Confirm whether your gateway is rewriting content (common culprit)

cr0x@server:~$ grep -iE 'X-(IronPort|Proofpoint|Mimecast|Barracuda|Symantec|MS-Exchange|Spam|Virus|Scanned)' -n message.eml | head
142:X-Proofpoint-Virus-Version: vendor=baseguard engine=...
143:X-Proofpoint-ORIG-GUID: ...

Ce que cela signifie : Un middleware de sécurité est impliqué, réécrivant souvent les URLs ou ajoutant des bannières — deux actions qui peuvent casser DKIM.

Décision : Si vous devez réécrire, implémentez la signature ARC au dernier point de modification et assurez-vous de préserver correctement les en-têtes Received et ARC.

Task 9: Validate that your MTA is not stripping ARC headers

cr0x@server:~$ postconf -n | egrep '^(header_checks|smtp_header_checks|cleanup_service_name|receive_override_options)'
header_checks =
smtp_header_checks =
cleanup_service_name = cleanup
receive_override_options =

Ce que cela signifie : Aucun contrôle d’en-tête explicite affiché. Si vous avez des filtres d’en-têtes, ils peuvent supprimer les en-têtes ARC-* « par sécurité ».

Décision : Si des contrôles d’en-têtes existent, auditez-les. La suppression des en-têtes ARC casse la chaîne et supprime des preuves sur lesquelles votre fournisseur en aval pourrait s’appuyer.

Task 10: Grep for header checks that remove ARC

cr0x@server:~$ sudo egrep -Rin 'ARC-|Authentication-Results|REMOVE|IGNORE' /etc/postfix | head -n 20
/etc/postfix/header_checks:12:/^ARC-/ IGNORE

Ce que cela signifie : Quelqu’un a décidé que les en-têtes ARC sont « non fiables » et a configuré Postfix pour les supprimer.

Décision : Arrêtez cela sauf si vous avez un modèle de menace très spécifique et que vous remplacez ARC par votre propre signature à une frontière contrôlée.

Task 11: Check OpenDKIM/OpenARC milter connectivity (classic production failure)

cr0x@server:~$ sudo journalctl -u postfix -u opendkim -u openarc --since "1 hour ago" | egrep -i 'milter|openarc|opendkim|connect|timeout|error' | tail -n 20
postfix/cleanup[22102]: warning: connect to Milter service unix:/run/openarc/milter.sock: No such file or directory
postfix/cleanup[22102]: warning: milter unix:/run/openarc/milter.sock: can't read

Ce que cela signifie : Postfix ne peut pas parler au service milter ARC/verify. Votre messagerie transitera sans traitement ARC, ou pire, avec des en-têtes partiels.

Décision : Réparez le service milter et redémarrez. Puis retestez avec un scénario de transfert connu et vérifiez l’apparition des ensembles ARC.

Task 12: Confirm the ARC signer is actually enabled and signing outbound/forwarded mail

cr0x@server:~$ sudo grep -RinE 'OpenARC|milter_default_action|milter_protocol' /etc/postfix/main.cf
/etc/postfix/main.cf:27:smtpd_milters=unix:/run/opendkim/milter.sock, unix:/run/openarc/milter.sock
/etc/postfix/main.cf:28:non_smtpd_milters=unix:/run/opendkim/milter.sock, unix:/run/openarc/milter.sock
/etc/postfix/main.cf:29:milter_default_action=accept
/etc/postfix/main.cf:30:milter_protocol=6

Ce que cela signifie : Les milters sont branchés à la fois pour les flux SMTP entrants et pour le mail généré localement, et le mode d’échec est accept (le courrier circule même si le milter est en panne).

Décision : Pour une assurance élevée, envisagez le tempfail pendant les incidents (avec précaution). Pour la plupart des entreprises, accept maintient le flux de mail pendant que vous alertez les bonnes personnes.

Task 13: Check OpenARC configuration for signing domain/selector alignment

cr0x@server:~$ sudo egrep -n '^(Domain|Selector|KeyFile|Socket|AuthservID)' /etc/openarc.conf
AuthservID mailgw1.corp.example
Domain corp.example
Selector arc1
KeyFile /etc/openarc/keys/corp.example/arc1.private
Socket local:/run/openarc/milter.sock

Ce que cela signifie : Votre signataire ARC revendique l’identité corp.example avec le sélecteur arc1.

Décision : Assurez-vous que le DNS contient la clé publique correspondante. Veillez aussi à ce que l’identité de signature représente une frontière que vous contrôlez (domaine de passerelle, pas un sous-domaine aléatoire oublié).

Task 14: Confirm that forwarded mail is leaving through the expected host (so ARC is applied)

cr0x@server:~$ grep -n '^Received:' -m 6 message.eml
12:Received: from mx.sender.example (203.0.113.10) by forwarder.corp.example ...
18:Received: from forwarder.corp.example (198.51.100.25) by mx.receiver.example ...

Ce que cela signifie : Le forwarder est le ré-expéditeur. C’est exactement le schéma de transfert qui casse SPF et déclenche la douleur DMARC.

Décision : Si le ré-expéditeur n’est pas votre passerelle signant ARC, faites transiter le courrier transféré par la passerelle qui signe ARC, sinon vous n’aurez jamais de preuves cohérentes.

Task 15: Check for multiple Authentication-Results headers and interpret them

cr0x@server:~$ grep -n '^Authentication-Results:' message.eml
25:Authentication-Results: forwarder.corp.example; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=billing@example.com; dmarc=pass header.from=example.com
61:Authentication-Results: mx.receiver.example; dkim=fail header.d=example.com; spf=fail smtp.mailfrom=billing@example.com; dmarc=fail header.from=example.com

Ce que cela signifie : Le forwarder a vu un succès ; le récepteur final a vu un échec. C’est le cas d’usage canonique d’ARC.

Décision : Si votre forwarder supporte ARC, préférez ajouter ARC plutôt que d’inventer des allowlists locales. Les allowlists se dégradent ; ARC fournit des preuves traçables.

Task 16: Prove whether a mailing list footer is breaking DKIM

cr0x@server:~$ awk 'BEGIN{p=0} /^$/{p=1} {if(p) print}' message.eml | tail -n 20
--
You received this message because you are subscribed to Corp List.
To unsubscribe, visit: ...

Ce que cela signifie : Un pied de page a été ajouté, ce qui casse souvent le hash du corps DKIM.

Décision : Pour les listes, soit évitez de modifier le corps, soit signez avec ARC après modification afin que les récepteurs puissent faire confiance au fait que la liste a traité un message précédemment authentifié.

Trois mini-récits d’entreprise du terrain

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise globale a déployé une nouvelle fonctionnalité « transfert d’e-mails clients » dans leur portail SaaS. Les clients pouvaient transférer reçus, alertes et notifications de conformité vers n’importe quelle adresse. L’équipe produit a supposé que le transfert était « juste du routage SMTP ». Ils ont vérifié que les messages quittaient leur système et arrivaient quelque part. Travail terminé.

Deux semaines plus tard, le support a reçu un motif étrange : certains clients recevaient tout, d’autres presque rien, et quelques-uns ne recevaient les messages que lorsqu’ils supprimaient le transfert. Les tableaux de bord internes étaient propres ; la profondeur des files était normale. Le système « fonctionnait ».

Les en-têtes mail ont raconté la vraie histoire. L’expéditeur original utilisait DMARC avec une politique stricte. Quand le client transférait de Provider A vers Provider B, SPF échouait chez Provider B (parce que l’IP du forwarder n’était pas autorisée), et DKIM échouait parce que le forwarder normalisait les limites MIME. DMARC a échoué et Provider B a honoré le « reject » de l’expéditeur.

L’hypothèse erronée n’était pas technique ; elle était organisationnelle : ils croyaient que la délivrabilité était « best effort ». Le résultat : factures non livrées, notifications de conformité retardées, et des équipes finance bricolant des contournements dans des feuilles de calcul. Finalement, ils ont implémenté la signature ARC à la frontière de transfert et ajusté leur passerelle pour préserver DKIM quand c’était possible. Les tickets n’ont pas disparu du jour au lendemain, mais les échecs sont devenus explicables et réparables. C’est une victoire en production.

Mini-récit n°2 : L’optimisation qui a mal tourné

Une équipe de sécurité d’entreprise a déployé un système de défense d’URL qui réécrivait tous les liens dans les mails entrants. Ils en étaient fiers. Les graphiques de CPU étaient bons, les rapports de tracking cliqués brillaient, et les simulations de phishing s’amélioraient.

Puis l’unité métier en charge de l’intégration des partenaires a commencé à manquer des e-mails contractuels sensibles au temps. Les messages n’étaient pas en quarantaine ; ils étaient rejetés en amont. C’est le pire type d’échec : votre système n’a même pas la preuve parce que quelqu’un d’autre a refusé d’accepter.

La passerelle de sécurité avait été placée devant le fournisseur de mail et réécrivait les messages avant la livraison. Cela cassait DKIM pour de nombreux expéditeurs. Isolé, DKIM cassé est survivable — SPF peut encore passer. Mais les transferts et les sous-routages rendaient SPF instable aussi. Les échecs DMARC sont devenus cumulatifs. Les partenaires utilisant « p=reject » étaient honorés par le côté récepteur.

Ils ont « optimisé » en supprimant les en-têtes inconnus pour réduire le stockage et prévenir l’« injection d’en-têtes ». Malheureusement cela incluait les en-têtes ARC. Ainsi, même quand les forwarders en amont avaient créé une chaîne ARC valide, la passerelle enlevait les preuves et réinsérait un état vierge. Les récepteurs en aval n’avaient aucune raison de faire confiance à ce qu’ils voyaient.

La correction a été ennuyeuse et humble : arrêter de supprimer ARC, ajouter la signature ARC après la réécriture, et aligner l’architecture pour que le dernier modificateur soit aussi le signataire. La sécurité a conservé sa réécriture. Les métiers ont récupéré leurs contrats. Les opérations ont eu moins d’urgences nocturnes et plus de travail de jour.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise B2B exploitait une paire de passerelles entrantes en active/active. Rien de sophistiqué : Postfix, OpenDKIM, OpenARC, une séparation claire entre « acceptation à la frontière » et « livraison interne ». Ils avaient aussi une politique : chaque échantillon entrant depuis la quarantaine est conservé avec les en-têtes complets pendant 30 jours, et tout changement au traitement des en-têtes nécessite une revue par les pairs réalisée par quelqu’un qui a déjà été brûlé par ce problème.

Lors d’une migration fournisseur, ils ont basculé une règle de transfert de sorte que certains boîtes soient livrées via un système de ticketing interne. Des tickets ont commencé à manquer des e-mails externes d’une banque particulière. La banque avait une politique DMARC stricte. Le système de ticketing modifiait le corps du message pour ajouter une bannière de cas. DKIM a cassé. SPF a échoué parce que le système de ticketing ré-envoyait avec l’enveloppe-from originale. DMARC a échoué et le fournisseur de boîte final a rejeté.

Parce qu’ils stockaient les messages bruts, ils ont pu comparer les versions « avant ticketing » et « après ticketing ». Le diff était évident : une bannière avait été ajoutée. Parce qu’ils avaient soumis au contrôle par les pairs le traitement des en-têtes, ARC était encore intact jusqu’à la passerelle, et ils avaient déjà OpenARC prêt à signer. Ils n’ont changé qu’une seule chose : le chemin sortant du système de ticketing a été routé via la passerelle qui signait ARC après modification.

C’est tout. Pas de blâme au fournisseur, pas d’allowlists magiques, pas de règles d’exception permanentes. Juste une frontière stable : si vous modifiez le courrier, signez ce que vous délivrez et conservez assez de télémétrie pour le prouver. Les systèmes ennuyeux font fonctionner les entreprises. Les systèmes excitants maintiennent les répondants aux incidents employés.

Blague n°2 : La seule chose plus éternelle que le courrier électronique est la réunion à propos de pourquoi le courrier électronique est éternel.

Erreurs courantes : symptômes → cause profonde → correction

1) « ARC est présent mais les récepteurs l’ignorent »

Symptômes : Des en-têtes ARC existent ; la délivrabilité échoue toujours ; le récepteur affiche DMARC fail sans mention arc=pass.

Cause profonde : La chaîne ARC ne se valide pas (clé incorrecte, en-têtes modifiés), ou le récepteur ne fait pas confiance au domaine signataire ARC, ou l’ensemble ARC est incomplet/malformé.

Correction : Validez cryptographiquement la chaîne ; assurez-vous que les clés DNS existent ; assurez la stabilité et la réputation du signataire ; ne supprimez pas/ ne modifiez pas les en-têtes ARC en cours de route.

2) « Nous avons activé la signature ARC, mais la validation échoue de manière intermittente »

Symptômes : Parfois ARC-Seal valide, parfois non ; les échecs corrèlent avec certaines tailles de message ou types de contenu.

Cause profonde : Un traitement en aval modifie les en-têtes/corps canoniques après signature (bannières antivirus, reformatage, normalisation des retours à la ligne).

Correction : Signez au dernier point de modification. Si vous devez modifier après signature, vous devez resigner (nouvelle instance ARC) à la nouvelle frontière.

3) « Le courrier transféré échoue SPF et DMARC ; nous avons supposé qu’ARC le corrigerait »

Symptômes : SPF fail, DMARC fail chez le récepteur final ; chaîne ARC absente ou non fiable.

Cause profonde : Pas de signature ARC au niveau du forwarder, ou le forwarder n’est pas participant ; de plus l’échec SPF est attendu sans SRS.

Correction : Implémentez SRS pour la survie SPF et/ou la signature ARC au niveau du forwarder. Si vous ne contrôlez pas le forwarder, préservez DKIM et évitez les modifications ; sinon acceptez que vous ne pouvez pas forcer les récepteurs distants à accepter.

4) « Les messages de liste disparaissent chez certains domaines d’entreprise »

Symptômes : Les posts des domaines avec DMARC reject n’arrivent jamais ; d’autres arrivent.

Cause profonde : La liste modifie le message, cassant DKIM ; SPF échoue lors du renvoi par la liste ; DMARC rejette.

Correction : Soit cessez de modifier (pas de pieds de page), soit utilisez la réécriture From pour DMARC, ou implémentez ARC afin que les récepteurs puissent créditer l’observation d’authentification par la liste.

5) « Nous avons supprimé les en-têtes ARC parce qu’ils sont ‘fournis par l’utilisateur’ »

Symptômes : Les chaînes ARC ne se valident jamais en aval ; des partenaires se plaignent de la délivrabilité des transferts.

Cause profonde : La politique de sanitation des en-têtes supprime ARC-* avec d’autres en-têtes ; cela casse l’intégrité de la chaîne.

Correction : Ne supprimez pas ARC si vous comptez dessus. Au lieu de cela, signez une nouvelle instance ARC à votre frontière. Si vous devez supprimer, faites-le avant de générer votre propre ensemble ARC et acceptez que les preuves en amont soient perdues.

6) « Le domaine signataire ARC ne correspond pas à notre frontière organisationnelle »

Symptômes : ARC se valide mais les récepteurs se méfient quand même ; ou votre filtrage en aval ne peut pas construire des règles de confiance.

Cause profonde : ARC utilise un sous-domaine aléatoire, un domaine fournisseur, ou un nom d’hôte instable qui ne porte pas de réputation cohérente.

Correction : Signez avec un domaine que vous contrôlez et que vous conserverez à long terme (par ex. corp.example). Assurez-vous que la rotation des sélecteurs et des clés est gérée comme toute identité critique.

Listes de contrôle / plan étape par étape

Checklist A: Décidez si vous avez vraiment besoin d’ARC

1. Opérez-vous des transferts (alias utilisateurs, règles de routage, réinjection ticketing, listserv) ? Si non, ARC est surtout observationnel.
2. Modifiez-vous régulièrement les messages en transit (bannières, réécriture d’URL, tampons DLP) ? Si oui, vous êtes en territoire ARC.
3. Voyez-vous des rejets liés à DMARC de la part de gros expéditeurs ? Si oui, ARC peut être le levier le moins pire.
4. Pouvez-vous plutôt préserver DKIM en ne modifiant pas le contenu ? Si oui, faites cela d’abord. ARC est pour les cas où vous ne pouvez pas.
5. Pouvez-vous implémenter SRS pour les forwarders ? Si oui, faites-le ; cela réduit la douleur SPF et complète ARC.

Checklist B: Implémentez ARC à une frontière contrôlée (la manière sensée)

1. Choisissez l’hôte frontière : le dernier endroit où les messages sont modifiés avant de quitter votre contrôle.
2. Publiez des clés DNS stables : créez le sélecteur arc1 (ou similaire), publiez l’enregistrement TXT et vérifiez la récupération depuis plusieurs résolveurs.
3. Activez la signature ARC : branchez OpenARC (ou votre implémentation) comme milter sur le MTA frontière.
4. Ne supprimez pas ARC en amont sauf si vous avez une politique claire ; si vous le supprimez, générez toujours votre propre instance ARC ensuite.
5. Surveillez les échecs de validation : traitez la signature ARC comme DKIM — rotation de clés, échecs DNS et changements de canonicalisation sont des risques opérationnels.
6. Testez des flux réels : transferts entre fournisseurs, posts de listes, réinjection ticketing, et scénarios « réécriture sécurité on/off ».

Checklist C: Préparation opérationnelle (principes SRE appliqués à l’e-mail)

1. Journalisez et conservez les en-têtes bruts pour des échantillons (quarantaine ou journaling) suffisamment longtemps pour déboguer des échecs de livraison sur plusieurs jours.
2. Ajoutez un canari : un message transféré quotidien depuis un domaine DMARC « reject » que vous contrôlez en labo, pour détecter rapidement les ruptures.
3. Alertez sur l’indisponibilité du milter (socket OpenARC manquant, timeouts ou taux d’erreur).
4. Documentez la règle « le dernier modificateur signe ». Faites-en une exigence dans les revues de changement.
5. Gardez un runbook cartographiant : quels systèmes modifient le mail, lesquels signent DKIM, lesquels signent ARC, et où se produisent les changements de routage.

FAQ

1) Est-ce qu’ARC fait passer DMARC ?

Non. DMARC est évalué sur la base des résultats SPF/DKIM et de l’alignement chez le récepteur. ARC fournit une preuve vérifiable que l’authentification a réussi plus tôt, et certains récepteurs peuvent accepter malgré un échec DMARC.

2) Si j’ajoute ARC, puis-je cesser de m’occuper de SRS ?

Ne le faites pas. SRS répare la survie de SPF pour le transfert ; ARC aide à expliquer et parfois atténuer les échecs. Ils résolvent des aspects différents du problème de transfert. Dans de nombreux environnements, utiliser les deux est la solution la plus stable.

3) Tous les MTA doivent-ils signer ARC ?

Non. Signez ARC aux frontières pertinentes : forwarders, listes de diffusion, passerelles de sécurité, points de réinjection ticketing. Des relays internes aléatoires signant ARC ajoutent du bruit à la chaîne et de la charge opérationnelle.

4) Les attaquants peuvent-ils falsifier les en-têtes ARC ?

Ils peuvent falsifier syntactiquement les en-têtes, mais ils ne peuvent pas falsifier une chaîne valide sans la clé privée du signataire. Le véritable risque est que des récepteurs fassent confiance à ARC provenant d’intermédiaires de faible qualité ou compromis. La confiance est la partie difficile.

5) Qu’est-ce qui casse le plus souvent la validation ARC ?

Les modifications d’en-têtes/corps après signature, les problèmes de clé DNS (manquante, mal tournée), et les règles « utiles » de sanitation d’en-têtes qui suppriment ou réordonnent des en-têtes signés.

6) Nous gérons une liste de diffusion. Quelle est la meilleure approche ?

Essayez d’abord d’éviter de modifier le corps et de préserver DKIM. Si vous devez modifier, implémentez la signature ARC afin que les récepteurs puissent voir que vous avez traité un message précédemment authentifié. Envisagez aussi des comportements compatibles DMARC pour les listes (comme la réécriture From), mais c’est une décision politique ayant des implications communautaires.

7) Comment savoir si les récepteurs font confiance à mon ARC ?

Vous n’obtenez pas de garantie universelle. Certains récepteurs afficheront les résultats d’évaluation ARC dans les en-têtes ; d’autres non. La méthode pratique est le test contrôlé : envoyez/transférez des messages via votre système vers les fournisseurs de boîtes courants et analysez les patterns d’acceptation.

8) ARC est-il pertinent si nous avons déjà DKIM sur le mail sortant ?

Oui, si vous transférez ou modifiez du mail entrant. Votre DKIM sortant ne protège pas le DKIM de l’expéditeur original. ARC concerne la préservation du contexte d’authentification à travers les intermédiaires.

9) Quelle est la différence entre Authentication-Results et ARC-Authentication-Results ?

Authentication-Results est la déclaration d’un récepteur sur ce qu’il a évalué. ARC-Authentication-Results est la déclaration d’un intermédiaire, scellée par ARC pour que les récepteurs en aval puissent vérifier qu’elle n’a pas été altérée.

10) ARC peut-il aider les défenses internes contre le phishing ?

Oui, comme télémétrie. ARC peut indiquer si un message s’était authentifié au bord avant d’être transformé en interne. Mais ne traitez pas ARC comme un contournement anti-phishing ; traitez-le comme une preuve qui alimente votre scoring de risque.

Conclusion : prochaines étapes réalisables cette semaine

ARC n’est pas une solution miracle. C’est une chaîne de traçabilité pour les résultats d’authentification. Ça paraît bureaucratique, et c’est précisément pour cela que ça marche : le courrier électronique est une bureaucratie avec des ports SMTP.

1. Choisissez un flux transféré qui échoue (ticketing, liste, transfert utilisateur). Capturez un message brut avec tous les en-têtes.
2. Déterminez ce qui a cassé : SPF à cause du transfert ? DKIM à cause des modifications ? DMARC à cause de l’alignement ?
3. Trouvez le dernier modificateur et faites de cet hôte le signataire ARC. Ne signez pas plus tôt en espérant que rien ne changera.
4. Arrêtez de supprimer les en-têtes ARC sauf si vous les remplacez par votre propre instance ARC à une frontière contrôlée.
5. Mettez en place un canari et des alertes pour la santé des milters et les échecs de validation ARC avant que le métier ne découvre le problème en premier.

Ensuite faites la partie peu glamour : gardez les clés publiées, faites les rotations de clés intentionnellement, et traitez l’authentification des mails comme une infrastructure d’identité en production. Parce que c’en est une.