La modification d'une passerelle sortante peut modifier un message signé même lorsque son objectif visible est simplement d'acheminer le courrier. Les pieds de page, la réécriture de liens, la conversion MIME et les modifications d'en-tête peuvent invalider un fichier existant. Signature DKIM. Localisez les limites exactes de modification et de signature avant de modifier DNS ou de blâmer le fournisseur de réception.
Dessinez l'ordre de traitement des messages
Documentez le résultat de l'application, le premier signataire, les transformations de passerelle, le signataire final et le destinataire. Capturez un message brut autorisé immédiatement avant et après la passerelle, lorsque cela est possible. Préserver les fins de ligne CRLF et les octets exacts ; copier un message affiché dans un éditeur de texte peut créer des modifications qui ne se sont jamais produites pendant le transport.
DKIM signe des en-têtes sélectionnés et un corps canonisé. Inspectez les caractères d, s, h, c de la signature ainsi que toute restriction relative à la longueur du corps. Détendu canonisation tolère des différences de formatage spécifiques, et non des modifications de contenu arbitraires. Un pied de page ajouté après la signature du corps entier modifie normalement le hachage du corps. RFC 6376, articles 3.4, 5 et 6.
Comparez les limites de signature sur papier
Supposons que From alerts@example.test , une signature originale valide avec d=example.test et sélecteur premièrement, une canonisation du corps assouplie et aucune limite de longueur de corps l=. Aucune clé réelle ni message signé n'est fourni.
- Avant la transformation de la passerelle : la validité de la signature est une prémisse et non un résultat cryptographique observé.
- Après avoir ajouté un pied de page de texte non vide qui modifie le corps complet canonique : le hachage du corps d'origine ne correspond plus, de sorte que la signature originale échouerait selon les hypothèses énoncées.
- Après la signature finale autorisée des octets transformés avec d=example.test et selector final : une nouvelle signature correctement générée et vérifiée de manière indépendante pourrait fournir un chemin DKIM aligné. La validité réelle d’une nouvelle signature n’a pas été testée. L'ancienne signature n'est pas réparée ; le conserver ou le supprimer est un choix de traitement distinct.
Aucune génération de clé, signature, vérification ou exécution de passerelle n'a eu lieu pour cette comparaison écrite. En production, capturez les octets avant/après réels et les données clés, puis mesurez plutôt que supposez chaque résultat.
Interpréter le résultat de manière étroite
Une ancienne signature défaillante observée après un pied de page établirait que cette transformation rompt cette signature. Il n’établit pas que chaque modification de la passerelle brise chaque signature. Un en-tête non signé peut changer sans affecter l'ensemble d'en-têtes signé. La canonisation peut également préserver la validité de certains changements d'espaces. Testez les fonctionnalités réelles de la passerelle, les structures MIME et les paramètres de signature au lieu d'extrapoler à partir d'un seul message texte.
L'exemple écrit suppose la même signature et le même domaine From, mais n'exécute pas l'intégralité DMARC découverte ou la politique d'un fournisseur de réception. DMARC nécessite un chemin d'authentification aligné et un domaine de signature de passerelle non lié ne le fournit pas automatiquement. alignement. RFC 9989. Une nouvelle signature valide doit encore être évaluée par rapport à l'identité de l'auteur prévue.
Choisissez la limite de signature de production
Lorsque cela est pris en charge, placez la signature autorisée finale après des transformations légitimes qui autrement modifieraient le contenu signé. Configurez le nouveau signataire avec un domaine et un sélecteur valides sous l'autorité approuvée de l'organisation. Publiez et vérifiez sa clé publique avant de diriger le trafic de production via elle. Conservez les anciens sélecteurs nécessaires pour les messages en file d'attente ou retardés dans le cadre d'un plan de retrait délibéré.
Ne résolvez pas le problème du pied de page en promettant que la canonisation assouplie accepte toute réécriture. Ne réduisez pas la couverture du corps signé comme solution de contournement de routine ; cela change ce que la signature protège. Si une signature en amont doit survivre, ajustez les transformations ou le routage et vérifiez les octets exacts plutôt que de supposer que la re-signature finale répare la signature antérieure.
Valider le basculement de la passerelle
Testez le texte brut, le HTML, les pièces jointes et les modèles commerciaux représentatifs via l’itinéraire réellement autorisé. Comparez les en-têtes bruts, les résultats d'authentification d'un récepteur de confiance et le rendu des messages. Incluez la gestion des rebonds et le comportement de la file d’attente. Une signature locale établit la validité cryptographique des données clés fournies, et non le placement dans la boîte de réception, la confiance de l'utilisateur ou la livraison de chaque modèle.
Les critères de restauration doivent identifier les flux légitimes ou les chemins d'authentification qui ont échoué et comment restaurer l'ancien ordre de traitement. Conservez les preuves avant de modifier à nouveau les paramètres. Fermez seulement une fois que le nouvel itinéraire et le chemin de récupération prévu sont compris.