A DKIM un échec de hachage corporel signifie que le vérificateur n'a pas reproduit le hachage du corps portées dans la signature, après application des règles applicables à la signature. Il n'identifie pas quel système a modifié le message et ce n'est pas le même diagnostic qu'une clé publique manquante.
Commencez par conserver le message original reçu. La copie du texte visible à partir d'un client de messagerie perd la structure MIME , l'encodage et d'autres octets importants pour la vérification.
Confirmez l'échec exact
Inspectez le résultat du destinataire de confiance et la signature en cours d'évaluation. Un message peut en avoir plusieurs Signature DKIM, et chacun peut avoir un domaine de signature ou un résultat différent.
Enregistrez d=, s=, l'algorithme, le c= paramètre de canonisation et toute balise l= body-length. Conservez le motif exact de la vérification. Un délai d'attente de recherche de clé, un algorithme non pris en charge, une inadéquation de signature d'en-tête et une inadéquation de hachage de corps nécessitent des enquêtes différentes.
Dans RFC 6376 §3.5, la valeur bh= est le hachage codé du corps canonisé, soumis au traitement de longueur défini. La valeur b= appartient au calcul de signature. Les traiter comme des obscurs interchangeables dont la vérification a échoué.
Préserver les preuves qui peuvent reproduire le résultat
Enregistrez le message brut via un chemin d'exportation approuvé et restreignez l'accès en fonction de son contenu. Conservez l'original reçu intact, avec un hachage et une heure de collecte si le processus d'enquête les prend en charge.
Créez des copies d'analyse séparément. La suppression d'une adresse, la modification d'une pièce jointe ou la sauvegarde d'un message reconstruit peuvent modifier les éléments pertinents pour la vérification. Une copie de partage sécurisé peut être utile, mais elle n’est pas automatiquement équivalente à l’original conservé.
Enregistrez la source de tout résultat de vérification. Un outil qui normalise les fins de ligne lors de l'importation peut ne pas évaluer les mêmes octets que le serveur de réception. Si deux outils ne sont pas d’accord, établissez d’abord leurs entrées et leur comportement pris en charge.
Comparez le message avant et après les modificateurs probables
Cartographiez l'itinéraire réel depuis l'expéditeur via les passerelles, les relais, les listes de diffusion et les services de réception. Recherchez des captures contrôlées immédiatement avant et après une transformation suspectée.
Les candidats courants aux enquêtes incluent un pied de page inséré après la signature, la réécriture d'URL, le réencodage MIME , le traitement des pièces jointes et la réparation du contenu mal formé. Ce sont des hypothèses jusqu’à ce que les preuves placent un changement pertinent d’un coup.
Utilisez un test contrôlé qui suit le même itinéraire et exerce la fonctionnalité suspectée. Par exemple, comparez un message par ailleurs équivalent avec et sans la règle de pied de page de la passerelle. Ne généralisez pas à partir d’un test direct qui contourne la passerelle de production.
Dans un cas synthétique, la sortie stockée par l'expéditeur est vérifiée avec succès, tandis que le message capturé après une passerelle de non-responsabilité présente une incompatibilité de hachage corporel. La passerelle ajoute un pied de page après la signature de l'expéditeur. Selon ces observations hypothétiques énoncées, cela identifie une dépendance de configuration à résoudre, plutôt qu'une raison pour remplacer la clé publique DKIM .
Comprendre ce que la canonisation peut tolérer
Règles de canonisation de DKIM permettre des normalisations particulières. Ils ne sécurisent pas l’édition de contenu arbitraire. La canonisation du corps assouplie n'autorise pas à réécrire des liens ou à ajouter un paragraphe après la signature.
Inspectez l'algorithme spécifié par la signature et utilisez un vérificateur qui l'implémente correctement. Ne diagnostiquez pas à partir d'un rendu visuellement identique : deux messages affichés peuvent contenir des octets signés différents.
Sous RFC 6376 §3.5, une valeur l= limite les octets de corps canonisés couverts par le calcul défini. Il ne s’agit pas d’une solution générale pour modifier une passerelle, et laisser délibérément le contenu hors protection modifie l’évaluation de la sécurité. Utilisez les configurations prises en charge et examinez les implications plutôt que d’ajouter une limite de longueur pour supprimer un symptôme.
Corrigez l'itinéraire modificateur, puis réévaluez l'alignement
Lorsque l'organisation contrôle l'itinéraire, organiser les modifications requises avant l'étape finale de signalisation appropriée. Si un service re-signe le courrier, vérifiez la nouvelle identité de signataire et ce qu'elle prouve. Une signature transmise provenant d'un intermédiaire indépendant ne s'aligne pas automatiquement sur le domaine From visible d'origine ; RFC 9989 §4.4.1 nécessite que l'identité de signature authentifiée s'aligne.
Pour les itinéraires indirects légitimes hors du contrôle de l’expéditeur, évaluez les orientations d’interopérabilité applicables. Ne désactivez pas le traitement de sécurité et n’affaiblissez pas une stratégie de domaine uniquement parce qu’un test échoue.
Répétez le flux de travail métier concerné et conservez les preuves avant et après. Utilisez ensuite Diagnostic d'alignement DMARC pour déterminer s'il reste un chemin aligné de dépassement. L'incident se termine lorsque la transformation concernée et ses effets sont compris et que l'itinéraire prévu a été vérifié.
Choisissez la prochaine étape de diagnostic
Utilisez cette séquence de décision proposée ; il n'enregistre aucun test exécuté :
- Aucune clé utilisable ou délai d'expiration de la requête de clé : suivez le résultat de la recherche sous RFC 6376 §6.1.2 plutôt que de diagnostiquer un pied de page.
- Le hachage corporel recalculé diffère de bh : comparez la représentation du corps, les paramètres c/l réels et la valeur bh enregistrée sous RFC 6376 §6.1.3. Un bh endommagé ou mal généré, ou une erreur d'implémentation du signataire/vérificateur, est également une cause possible ; le décalage à lui seul ne prouve pas une modification corporelle.
- Le hachage du corps correspond mais la signature échoue : inspectez les en-têtes signés, le calcul de la signature et la relation clé-signataire ; faire correspondre bh seul n'est pas un laissez-passer DKIM .
- Plusieurs signatures ne sont pas d'accord : gardez chaque résultat lié à ses propres d et s avant de décider si un chemin aligné qui passe reste.