Listes de diffusion et DMARC : pourquoi ça casse, comment ARC rattrape

Les parades côté liste : réécrire le From, ou ne plus rien toucher

Face à ce mur, les opérateurs de listes ont convergé vers deux grandes stratégies, aux philosophies opposées.

La première : la réécriture du From. La liste cesse de se présenter comme simple relais et devient l'auteur officiel du message. L'en-tête devient par exemple From: "Marie Dupont via discussion" <discussion@listes.exemple.fr>, l'adresse réelle de l'auteur étant déplacée dans Reply-To. DMARC évalue désormais le domaine de la liste — qui signe ses propres messages en DKIM et aligne son propre SPF — et tout passe. Le logiciel GNU Mailman, omniprésent sur les listes techniques, propose ce comportement en option, souvent déclenché uniquement lorsque le domaine de l'auteur publie une politique restrictive. Le prix à payer est sémantique : la réponse privée à l'auteur devient hasardeuse, les carnets d'adresses enregistrent l'adresse de la liste à la place de la personne, et l'identité réelle de l'auteur ne survit que dans le nom d'affichage.

La seconde : la non-modification. La liste renonce au préfixe de sujet, au pied de page, à toute retouche du corps MIME. La signature DKIM d'origine reste alors intacte et vérifiable à l'arrivée — et comme DMARC n'exige qu'un seul mécanisme aligné, ce DKIM survivant suffit : le désalignement SPF ne pèse plus rien. C'est la voie la plus propre cryptographiquement, adoptée par un nombre croissant de listes techniques. Son coût est ergonomique : les marqueurs familiers disparaissent du contenu visible, l'information migrant vers les en-têtes normalisés List-Id, List-Post et List-Unsubscribe, invisibles pour l'œil mais exploités par les clients de messagerie modernes. Une troisième voie historique — encapsuler le message d'origine en pièce jointe d'un message émis par la liste — préserve tout mais dégrade tant la lecture qu'elle a pratiquement disparu.

ARC, la chaîne de garde des résultats d'authentification

Les deux parades précédentes réparent le symptôme en sacrifiant quelque chose : l'identité de l'auteur ou les usages de la liste. ARC (Authenticated Received Chain, RFC 8617, publiée en 2019 avec un statut expérimental) attaque le problème autrement : plutôt que d'éviter la casse, il en documente la chaîne de possession, comme un procès-verbal de garde à chaque maillon.

Le principe : chaque intermédiaire qui manipule le message y appose trois en-têtes numérotés (i=1, i=2…). ARC-Authentication-Results consigne les résultats d'authentification observés à l'arrivée chez cet intermédiaire — par exemple spf=pass, dkim=pass, dmarc=pass au moment où la liste a reçu le message de l'auteur. ARC-Message-Signature signe le message tel que retransmis, modifications comprises. ARC-Seal scelle l'ensemble de la chaîne, garantissant qu'aucun maillon n'a été altéré après coup. Le récepteur final, constatant l'échec DMARC, peut alors remonter la chaîne : si elle est intacte et que le sceau provient d'un intermédiaire jugé digne de confiance, il sait que le message était correctement authentifié avant la liste — et peut choisir de le délivrer malgré la politique. Le protocole est décortiqué en détail dans la chaîne de confiance des intermédiaires.

La limite est dans la dernière phrase : jugé digne de confiance. ARC authentifie un témoignage, pas l'honnêteté du témoin. N'importe quel serveur peut sceller une chaîne ARC formellement valide affirmant que tout allait bien à l'origine — y compris un spammeur scellant son propre courrier. La valeur d'une chaîne dépend donc entièrement de la réputation que le récepteur accorde au scelleur, et il n'existe aucun registre public des intermédiaires de confiance : chaque grand récepteur entretient le sien. Gmail et Microsoft 365 scellent et honorent ARC à grande échelle ; une petite liste auto-hébergée sur un serveur anonyme, elle, verra ses sceaux poliment ignorés. ARC rattrape donc une grande partie de la casse légitime chez les grands fournisseurs, mais ne constitue ni une garantie universelle ni une raison de renoncer aux bonnes pratiques côté liste.

Ce que montre un rapport RUA

Pour le propriétaire du domaine de l'auteur, tout cela laisse une empreinte reconnaissable dans les rapports agrégés. La signature typique du trafic de liste : une IP source appartenant au serveur de la liste, un SPF en échec ou en réussite non alignée (le domaine d'enveloppe est celui de la liste), un DKIM en échec — ou en réussite pour le domaine de la liste, donc non aligné lui non plus —, et une disposition qui suit la politique publiée. Lorsqu'un récepteur a honoré une chaîne ARC, la ligne le dit explicitement :

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>local_policy</type>
    <comment>arc=pass</comment>
  </reason>
</policy_evaluated>

Ce bloc se lit ainsi : la politique demandait une sanction, mais le récepteur a dérogé (local_policy) parce que la chaîne ARC attestait une authentification saine en amont. Savoir reconnaître ces lignes change tout dans l'interprétation d'un rapport. Les compter comme des tentatives d'usurpation gonfle artificiellement la menace perçue et peut faire paniquer à tort ; à l'inverse, sous p=reject, les mêmes lignes sans dérogation ARC représentent des messages réels, écrits par de vrais utilisateurs, définitivement perdus. Un outil d'analyse qui identifie les sources — cette IP est un opérateur de listes connu, celle-là un serveur universitaire — raccourcit ce diagnostic de plusieurs heures à quelques minutes.

Recommandations : opérateur de liste et propriétaire de domaine

Les deux rôles ne contrôlent pas les mêmes leviers, et les confondre mène à des remédiations impossibles.

Côté opérateur de liste, l'ordre de priorité est clair. D'abord, cesser de modifier les messages : sans préfixe de sujet ni pied de page, le DKIM d'origine survit et le problème disparaît pour l'essentiel — les en-têtes List-* portent très bien l'information de désabonnement. Si la culture de la liste impose les marqueurs visibles, activer la réécriture du From, idéalement de façon conditionnelle (seulement pour les auteurs dont le domaine publie une politique stricte). Dans tous les cas : signer en DKIM avec le domaine de la liste, aligner le SPF et le DMARC de ce domaine, sceller en ARC si la plateforme le permet, et surveiller le traitement des rejets pour ne plus jamais désabonner des innocents.

Côté propriétaire de domaine, tout dépend de la population derrière les adresses. Un domaine purement applicatif — transactionnel, notifications, marketing — n'a aucun humain qui poste sur des listes : le problème est marginal et ne justifie aucun délai vers la politique stricte. Un domaine portant de vraies boîtes humaines, en revanche, impose d'observer les rapports avant de durcir : identifier le trafic de listes, mesurer son volume, prévenir les équipes concernées. Le choix entre quarantaine et rejet prend ici un sens très concret : p=quarantine laisse aux messages de listes une chance d'atterrir — en spam, mais récupérables — là où p=reject les détruit purement chez les récepteurs qui n'honorent pas ARC. Le mode test t=y de DMARCbis permet en outre d'évaluer l'effet d'une politique sans l'appliquer, le temps de cartographier l'exposition réelle du domaine aux listes.

En résumé

Une liste de diffusion casse DMARC deux fois : sa retouche du contenu invalide la signature DKIM de l'auteur, et sa réexpédition depuis ses propres serveurs rend SPF non aligné — aucun des deux mécanismes ne survit, et le message légitime échoue. L'épisode fondateur de 2014 a imposé deux parades côté listes, la réécriture du From et la non-modification du contenu, chacune avec son sacrifice. ARC ajoute une troisième voie : une chaîne scellée qui témoigne de l'authentification d'origine et permet au récepteur de réhabiliter le message — à condition de faire confiance au scelleur, ce qui réserve aujourd'hui son bénéfice aux grands intermédiaires connus. Dans les rapports RUA, ce trafic se reconnaît à sa signature caractéristique et aux dérogations local_policy ; le lire correctement évite autant la fausse alerte que la perte silencieuse.

Le point de départ pratique ne coûte rien : passer le domaine par une analyse DMARC gratuite révèle l'état des mécanismes d'authentification et la manière dont la politique actuelle traiterait le trafic relayé. Pour aller au bout — identifier les listes dans les rapports, suivre les dérogations ARC, durcir la politique sans perdre un message légitime —, la création d'un compte ouvre la surveillance continue des rapports, avec l'historique nécessaire pour distinguer, semaine après semaine, la casse de liste de la véritable usurpation.