Un pied de page peut transformer un message sortant correctement signé en un DKIM échec. La réparation commence par la séquence de traitement : identifiez quel système a signé le message, quel système a inséré le pied de page et quelle signature le destinataire a évaluée. La publication d’une autre clé DNS ne peut pas ajouter un texte de couverture de signature après sa création.
Prouver quels octets ont changé
Enregistrez un message contrôlé immédiatement après la signature et un autre après la passerelle, en utilisant l'exportation de messages bruts plutôt que le texte copié à partir d'un client de messagerie. Conservez les fichiers originaux. Enregistrez les balises d, s, c, h et toute signature l de chaque signature. Un message peut avoir plusieurs signatures avec une couverture et des résultats différents.
DKIM calcule un hachage du corps canonisé. Dans le cadre d'une couverture complète ordinaire, un nouveau pied de page ajoute un contenu substantiel et modifie ce hachage. Corps détendu canonisation supprime certaines différences d'espaces ; il ne supprime pas une clause de non-responsabilité, un bloc HTML ou une nouvelle partie MIME . Une inadéquation de hachage de corps concerne les entrées et les valeurs de hachage de corps comparées : la représentation du corps, les paramètres c/l et la valeur bh. Un bh endommagé ou mal généré, ou une erreur d'implémentation du signataire/vérificateur, peut également expliquer une incompatibilité. La comparaison dans RFC 6376 section 6.1.3 ne prouve pas en soi qu’une passerelle a changé le corps. Un échec général de signature peut plutôt impliquer un en-tête signé, une recherche de clé ou une syntaxe de signature. RFC 6376 §3.4, RFC 6376 §3.7 et RFC 6376 §6.1 décrire ces contrôles distincts.
Comparez les échantillons à la limite où le pied de page est appliqué. Inspectez les parties texte/plain et texte/html, les limites MIME et l'encodage de transfert. Un pied de page visible apparemment identique peut être sérialisé différemment. Si la passerelle change également de sujet, vérifiez si le sujet est répertorié dans h : la réparation du corps à elle seule ne restaurera pas une signature sur un en-tête modifié.
Testez la commande plutôt que de deviner
Scénario illustratif : une application crée une facture, le serveur sortant la signe, et une passerelle ajoute ensuite une mention légale. Le destinataire signale une incompatibilité de hachage corporel pour la signature de l'application. Dans une alternative contrôlée, la passerelle ajoute d'abord la notification et un signataire autorisé signe le message sérialisé final. Un résultat positif sur ce deuxième chemin soutient le diagnostic de commande. Il s'agit d'observations de test proposées, et non de résultats d'un locataire réel.
Utilisez les mêmes variantes de message via les deux chemins, y compris le HTML, le texte brut et une pièce jointe. Enregistrez les résultats de l’authentification du destinataire à partir d’une limite de confiance, du domaine de signature et du domaine visible De. Le pass DKIM seul est insuffisant pour DMARC si la signature de passage ne correspond pas au domaine de l'auteur. Une signature de passerelle sans rapport peut être vérifiée correctement sans fournir ce chemin aligné.
Choisissez une limite de signature détenue
La conception durable habituelle consiste à effectuer les modifications de contenu requises avant l’opération de signature finale autorisée. Cela peut impliquer de déplacer le signataire plus tard, de déplacer l'insertion du pied de page plus tôt ou de configurer la passerelle pour signer le message final en utilisant un domaine contrôlé par l'organisation. Confirmez le comportement pris en charge et la propriété de la clé avant de sélectionner une conception. Ne présumez pas que chaque passerelle prend en charge la signature de domaine personnalisé.
Si une signature existante est rompue, l’ajout d’une nouvelle signature valide ne répare pas la précédente. Évaluez la nouvelle signature selon ses propres mérites et vérifiez alignement séparément. N'activez pas la balise body-length l uniquement pour faire disparaître les pieds de page du calcul de hachage : cela laisse un suffixe non signé et crée le compromis de sécurité décrit dans RFC 6376 §8.2.
Terminez par un contrôle de régression
Conservez un diagramme d'itinéraire montrant le dernier composant qui change de corps et le signataire immédiatement après. Re-testez lorsque les règles de non-responsabilité, la réécriture de l'antivirus ou le routage sortant changent. Le succès signifie que le pied de page requis est présent, que la signature prévue est vérifiée, que son domaine répond à la politique d'alignement prévue et que les messages critiques arrivent toujours par l'itinéraire attendu. Conservez un plan de restauration pour le changement de configuration sans considérer la suppression d'une mention légale requise comme un remède automatique.
Utiliser un enregistrement d'acceptation de régression
Pour chaque variante de texte brut synthétique, HTML et pièce jointe, noter : pied de page présent ; dernier saut de changement de corps ; signataire final d/s ; sélectionné c/h/l ; résultat du récepteur de confiance ; Domaine d'auteur et alignement ; et le résultat de la route commerciale. Si le pied de page est manquant, l'exigence de notification n'est pas remplie même lorsque DKIM passe. Si le pied de page est présent mais que seul un domaine de passerelle non lié passe, l'exigence d'alignement DKIM prévue n'est pas satisfaite. Il s’agit de critères d’acceptation et non de vérifications terminées.