Un message signé peut quand même être du spam. Son domaine de signature peut aussi différer de l'adresse affichée au destinataire.
Que couvre une signature DKIM ?
Une signature DKIM protège des champs d'en-tête sélectionnés et un hash du corps.
Le tag h= liste les champs d'en-tête signés. Le tag bh= contient le hash du corps. Le serveur d'envoi produit la signature avec sa clé privée. Les destinataires la vérifient avec la clé publique correspondante.
Le destinataire recalcule le hash du corps. Il vérifie aussi la signature sur les en-têtes sélectionnés et l'en-tête de signature, qui contient ce hash.
RFC 6376 exige la signature de l'en-tête From. D'autres champs d'en-tête peuvent rester non signés. Ajouter un Reply-To non signé peut donc laisser DKIM valide.
Les en-têtes répétés nécessitent un traitement séparé. Le signataire peut lister un nom d'en-tête plus de fois qu'il n'apparaît pour empêcher l'ajout non détecté d'une autre occurrence.
Où le destinataire trouve-t-il la clé publique ?
Le destinataire localise la clé publique à l'aide du domaine de signature et du sélecteur, le nom identifiant cette clé. Le tag d= donne le domaine. Le tag s= donne le sélecteur.
Pour d=example.com et s=foo.bar, le nom de recherche est foo.bar._domainkey.example.com. Le sélecteur permet d'utiliser différentes clés sous le même domaine de signature.
Lors d'une rotation, publiez la clé de remplacement avant de signer avec. Gardez l'ancienne clé de vérification disponible tant que des messages signés avec elle sont encore en transit. La supprimer prématurément empêche les destinataires de vérifier ces messages.
Pourquoi des changements de formatage peuvent-ils invalider une signature ?
La canonicalisation, la normalisation appliquée avant la signature et la vérification, détermine quels changements de formatage DKIM tolère.
Le tag c= choisit des algorithmes séparés pour l'en-tête et le corps. Dans relaxed/relaxed, les deux utilisent la normalisation relaxed.
| Algorithme | Comportement pour l'en-tête | Comportement pour le corps |
|---|---|---|
simple | Préserve le formatage de l'en-tête | Ignore les lignes vides à la fin |
relaxed | Normalise la casse, le pliage et les espaces des noms d'en-tête | Normalise les espaces et les lignes vides finales |
Un en-tête plié continue sur une autre ligne. Le traitement relaxed des en-têtes tolère ce pliage. Le traitement simple peut échouer après qu'un serveur a replié le même en-tête.
Comparez le contenu signé avant et après le relais défaillant, car un changement de formatage invisible peut expliquer le résultat.
Quels algorithmes de signature DKIM prend-il en charge ?
DKIM prend en charge les algorithmes de signature RSA et Ed25519, tous deux combinés avec SHA-256.
RSA a une taille de clé minimale de 1024 bits selon RFC 8301. Des clés plus courtes offrent une résistance insuffisante à la compromission de clé.
La taille RSA recommandée est d'au moins 2048 bits, offrant une meilleure résistance à la compromission de clé. Choisissez cette taille lorsque votre système de signature la prend en charge. La spécification interdit rsa-sha1 pour la signature et la vérification.
RFC 8463 ajoute ed25519-sha256. Un message peut porter à la fois des signatures RSA et Ed25519 pour la compatibilité avec les destinataires prenant en charge différents algorithmes.
Les recommandations de Yahoo exigent aussi une clé DKIM d'au moins 1024 bits.
Que se passe-t-il quand une liste de diffusion modifie le message ?
Une modification peut invalider DKIM lorsqu'elle change du contenu couvert par la signature.
Le transfert ne modifie pas en soi le contenu signé. Une signature intacte peut y survivre. Un pied de page ajouté peut modifier le hash du corps. Un Subject signé réécrit peut invalider la signature de l'en-tête.
Le tag optionnel l= limite la couverture du corps à un nombre d'octets spécifié. Avec l=100, le contenu après les 100 premiers octets normalisés n'est pas protégé. Ajouter du texte trompeur peut donc laisser la signature valide.
Évitez cette limite quand vous avez besoin de protéger l'intégralité du corps. ARC permet aux intermédiaires de conserver des preuves signées d'authentification avant leurs modifications.
Comment configurez-vous DKIM avec Bird ?
Vous publiez l'enregistrement DKIM renvoyé lorsque vous enregistrez votre domaine d'envoi.
Le champ dkim.mode de API a pour valeur par défaut txt. Avec ce mode, publiez la clé publique dans un enregistrement TXT. Le schéma liste aussi delegated. Cette valeur renvoie HTTP 422 lorsque vous enregistrez un domaine d'envoi, utilisez donc txt.
Bird crée une clé et un sélecteur distincts pour chaque organisation utilisant un domaine d'envoi. Les organisations utilisant le même domaine n'ont pas besoin de partager une clé de signature.
Le guide d'authentification explique l'enregistrement renvoyé.
Une signature réussie prouve-t-elle que le message est sûr ?
Une signature réussie établit la responsabilité du contenu signé. Elle n'établit pas si le message est souhaité ou fiable.
Elle n'exige pas non plus que le domaine de signature corresponde au domaine From visible. DMARC fournit cette règle de correspondance via l'alignement. La réputation de l'expéditeur, l'évaluation du trafic d'un expéditeur par le destinataire, reste une considération distincte.
En bref
Seul le contenu sélectionné est protégé.
DKIM couvre les champs d'en-tête listés et un hash du corps. Le contenu non protégé peut changer sans invalider la signature.
Les sélecteurs localisent les clés de vérification.
Le sélecteur et le domaine de signature identifient l'enregistrement DNS contenant la clé publique.
La normalisation affecte la vérification.
Les algorithmes simple et relaxed traitent les changements de formatage différemment.
Le transfert ne garantit pas un succès.
Une signature intacte peut survivre au transfert, mais des modifications du contenu signé peuvent l'invalider.