← RFC Reference

RFC 6377 : DKIM et listes de diffusion

Pourquoi cela existe

DKIM (RFC 6376) signe les en-têtes et le contenu du corps des e-mails avec un hachage cryptographique. Toute modification après la signature invalide la signature. Les listes de diffusion, par conception, modifient les messages en transit. Cela crée une tension fondamentale :

• DKIM veut que les messages arrivent exactement comme signés.
• Les listes de diffusion ajoutent des pieds de page, préfixent « [nom-liste] » aux sujets, ajoutent des en-têtes List-*, réécrivent les adresses From et enveloppent les messages dans des résumés.

Quand DMARC est entré en scène (exigeant l'alignement de DKIM ou SPF), cette tension est devenue une crise de délivrabilité. Les messages envoyés aux listes de diffusion par des domaines avec des politiques DMARC p=reject ont commencé à être rejetés pour tous les abonnés de la liste. La RFC 6377 a été publiée pour documenter le problème et recommander des stratégies d'atténuation.

Comment cela fonctionne

Ce que les listes de diffusion font aux messages

Un gestionnaire de liste de diffusion typique (Mailman, Sympa, LISTSERV, Google Groups) peut effectuer n'importe quelle combinaison de :

Le flux de vérification de signature

; Étape 1 : L'auteur envoie un message signé DKIM à la liste
From: alice@example.com
To: dev-list@lists.example.org
Subject: Proposed API change
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Étape 2 : Le logiciel de liste modifie le message
From: alice@example.com            ← inchangé (ou réécrit)
To: dev-list@lists.example.org
Subject: [dev] Proposed API change  ← modifié : préfixe ajouté
List-Id: <dev-list.lists.example.org>  ← ajouté
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Corps original + pied de page ajouté
The body text here...

--
To unsubscribe, visit https://lists.example.org/unsub  ← ajouté

; Étape 3 : Le serveur du destinataire vérifie DKIM
; Résultat : ÉCHEC (Objet et corps ont été modifiés après la signature)

Pratiques recommandées pour les opérateurs de listes

La RFC 6377 recommande que les listes de diffusion minimisent les modifications pour préserver les signatures DKIM :

1. Ne pas modifier l'en-tête Objet. Éviter de préfixer [nom-liste]. Utiliser plutôt l'en-tête List-Id — les clients de messagerie peuvent filtrer dessus.
2. Ne pas ajouter de pieds de page au corps. Utiliser l'encapsulation MIME si le contenu du pied de page est requis, ou ajouter le pied de page comme une partie MIME séparée plutôt que de l'ajouter au corps existant.
3. Ajouter une nouvelle signature DKIM. La liste doit signer le message modifié avec sa propre clé DKIM (d=lists.example.org). Cela ne répare pas la signature originale, mais cela fournit une signature valide du domaine de la liste.
4. Considérer la réécriture From pour DMARC. Quand le domaine de l'expéditeur original publie p=reject, réécrire l'en-tête From au domaine de la liste et mettre l'expéditeur original dans Reply-To. C'est largement implémenté comme « From munging ».

Pratiques recommandées pour les expéditeurs

1. Utiliser la canonicalisation relaxed. Signer avec c=relaxed/relaxed plutôt que c=simple/simple. La canonicalisation relaxed tolère les petits changements d'espaces blancs que certains logiciels de liste introduisent.
2. Signer uniquement les en-têtes essentiels. La balise h= doit couvrir les en-têtes qui vous intéressent (From, Subject, Date, To, Message-ID) mais pas les en-têtes que les listes ajoutent généralement (List-Id, List-Unsubscribe).
3. Utiliser la balise l= de longueur de corps avec prudence. La balise l= limite la partie du corps qui est signée, de sorte que les pieds de page ajoutés ne cassent pas la signature. Cependant, cela a des implications de sécurité — un attaquant pourrait ajouter du contenu malveillant sous la portion signée.

Détails techniques clés

La complication DMARC

La RFC 6377 précède DMARC (RFC 7489), mais les problèmes qu'elle décrit sont devenus bien plus graves une fois DMARC déployé. Avec DMARC p=reject :

; Le domaine de l'auteur publie une DMARC stricte
_dmarc.example.com TXT "v=DMARC1; p=reject; ..."

; Le message passe par la liste de diffusion, DKIM se casse
; Le serveur du destinataire vérifie DMARC :
;   - SPF : ÉCHEC (expéditeur d'enveloppe est la liste, pas example.com)
;   - DKIM : ÉCHEC (signature cassée par les modifications de la liste)
;   - DMARC : ÉCHEC → REJETER
; Résultat : le message est rejeté pour tous les abonnés de la liste

C'est pourquoi ARC (RFC 8617) a été développé — pour préserver les résultats d'authentification à travers les intermédiaires comme les listes de diffusion.

ARC comme solution moderne

Le protocole de chaîne d'authentification reçue (ARC, Authenticated Received Chain) permet aux intermédiaires comme les listes de diffusion d'enregistrer les résultats d'authentification originaux avant de modifier le message. Le serveur du destinataire peut alors utiliser la chaîne ARC pour récupérer le passe DKIM/SPF original, même après que la liste ait cassé la signature originale.

Stratégies de réécriture From

L'atténuation DMARC la plus courante pour les listes de diffusion est la réécriture From :

; Message original
From: Alice Smith <alice@strict-dmarc.com>

; Après réécriture From de la liste
From: Alice Smith via Dev List <dev-list@lists.example.org>
Reply-To: Alice Smith <alice@strict-dmarc.com>

Cela préserve l'identité de l'expéditeur original dans le texte affiché et Reply-To tout en faisant correspondre le domaine From à la signature DKIM de la liste.

Erreurs courantes

• Utiliser la canonicalisation c=simple/simple. La canonicalisation simple échoue même sur les changements d'espaces blancs triviaux. Toujours utiliser c=relaxed/relaxed si vos messages peuvent passer par des listes de diffusion ou d'autres intermédiaires.
• Signer trop d'en-têtes. Inclure des en-têtes comme List-Id ou List-Unsubscribe dans la balise DKIM h= garantit l'échec quand une liste ajoute ces en-têtes. Signer uniquement les en-têtes que vous générez.
• Publier p=reject DMARC sans considérer les listes. Si vos utilisateurs envoient à des listes de diffusion, une politique DMARC reject stricte causera le rejet de leurs messages de liste pour tous les abonnés. Envisager p=quarantine ou assurez-vous que vos utilisateurs comprennent les implications.
• Les opérateurs de liste n'ajoutent pas leur propre signature DKIM. Après avoir modifié un message, la liste doit le signer avec sa propre clé. Sans cela, le message arrive sans aucune signature DKIM valide.
• S'appuyer uniquement sur la longueur de corps l=. Bien qu'elle puisse préserver les signatures au-delà des pieds de page ajoutés, l= a été déprécié par de nombreux guides de bonnes pratiques car il permet l'injection de contenu sous la limite signée.
• Ne pas implémenter ARC. Le logiciel moderne de listes devrait implémenter ARC pour préserver la chaîne d'authentification originale. Sans ARC, les destinataires n'ont aucun moyen de savoir que le message a été authentifié à l'origine.

Impact sur la délivrabilité

• Le DKIM cassé sur le courrier de liste cause des rebonds. Avec DMARC p=reject, un DKIM cassé signifie des messages rejetés. Les abonnés de la liste cessent de recevoir du courrier, et l'opérateur de la liste est inondé de rebonds.
• La réécriture From préserve la délivrabilité mais change l'identité de l'expéditeur. Les destinataires voient l'adresse de la liste en From, pas l'expéditeur original. Cela peut confondre les utilisateurs mais c'est le moyen le plus fiable d'assurer la livraison.
• ARC améliore la livraison pour le courrier de liste. Les principaux fournisseurs (Gmail, Microsoft, Yahoo) honorent les chaînes ARC. Un sceau ARC valide d'une liste réputée peut remplacer une signature DKIM originale cassée.
• La réputation de la liste compte. Les serveurs récepteurs évaluent la réputation du domaine de la liste. Une liste bien entretenue avec de bonnes pratiques d'envoi, une signature DKIM appropriée et une implémentation ARC verra de meilleurs taux de livraison qu'une liste mal gérée.
• Surveiller vos taux de rebond du trafic de liste. Si vous voyez des pics de rebonds pour les messages envoyés à des listes de diffusion, vérifiez si la liste modifie les messages d'une manière qui casse votre signature DKIM, et si elle implémente ARC.

Related RFCs