Spécifiez quel message la bannière change
Une clause de non-responsabilité légale sortante, une bannière d'avertissement entrante et une marque de classification en en-tête uniquement peuvent toutes être appelées une bannière de courrier. Ils n'ont pas le même effet sur l'authentification. Identifiez la direction, le point d'insertion et la représentation exacte à modifier avant d'interpréter un DKIM résultat. Un contrôle réussi à l’entrée peut coexister avec un échec ultérieur après une modification interne du corps.
Il s'agit d'une évaluation proposée, sans modification des règles de transport ni message envoyé. Porte des preuves originales : échantillons de livraison directe et indirecte avec comparaison de l'itinéraire, de l'enveloppe, des signatures et des résultats fiables. Les cas fictifs illustrent les limites ; ce ne sont pas des observations d’un client locataire.
Séparer la correspondance des règles de la transformation du contenu
Une règle de non-responsabilité nécessite à la fois une condition qui sélectionne les messages et une action qui les modifie. La documentation Exchange Online de Microsoft décrit les ajouts en haut ou en bas des messages et les conditions permettant de les limiter au courrier sortant. Ces fonctionnalités documentées n'identifient pas les règles installées dans une organisation particulière. Enregistrez la portée réelle, les exceptions et la priorité d’un examen de configuration autorisé avant de prédire les résultats. Règles de non-responsabilité de Microsoft
Distinguez une correspondance de règle enregistrée d’un message transformé réel. Microsoft déclare que Test sans conseils de stratégie enregistre les résultats sans ajouter de clause de non-responsabilité. Ce mode peut aider à évaluer la sélection, mais il ne peut pas à lui seul démontrer si le contenu inséré survivrait à la vérification DKIM ou s'afficherait correctement. Planifiez une transformation de message contrôlée et autorisée séparément lorsque la preuve de ces effets est nécessaire. Mode de règles Microsoft
Comparez les entrées signées plutôt que l'étiquette
La vérification DKIM dépend des instances d'en-tête sélectionnées et de la couverture du corps canonique. L'ajout d'une étiquette visuelle non signalée dans l'interface d'une application de messagerie ne constitue pas nécessairement une modification du message stocké. L'insertion d'un texte d'avertissement HTML dans une partie MIME est un changement de message. Un en-tête ajouté en dehors de la couverture de signature sélectionnée peut avoir un résultat différent de la modification d'un champ Objet signé. RFC 6376 sections 3.4 à 3.5 et 5.4
Ne prétendez pas que chaque modification de contenu brise inévitablement DKIM . Certaines différences disparaissent sous la configuration canonisation, et la couverture peut être affectée par la sélection d'en-tête ou l=. Pour une signature couvrant tout le corps, une clause de non-responsabilité ordinaire qui ajoute du texte sans espace modifie l'entrée canonique et invalide cette signature, en supposant qu'elle ait été vérifiée au préalable. La canonisation assouplie n'est pas une autorisation d'ajouter du texte arbitraire. RFC 6376 sections 3.4 et 3.5
Placer les résultats de l'authentification sur la chronologie du traitement
Pour le courrier entrant, une passerelle de confiance identifiée peut authentifier le message d'origine avant d'ajouter un avertissement pour les lecteurs internes. Un système ultérieur peut alors voir les octets modifiés et obtenir un résultat différent. Préserver à la fois le temps d’évaluation et la représentation évaluée. Authentication-Results n'est utile que dans le cadre d'un modèle de confiance établi ; un champ non fiable revendiquant le succès n'établit pas ce que la passerelle a réellement vérifié. RFC 8601 section 7
Pour le courrier sortant d'une organisation, déterminez si la clause de non-responsabilité prévue est appliquée avant son signataire aligné autorisé. Un dernier saut externe qui ajoute du texte après la signature peut nuire à cette signature. Ne déduisez pas l’ordre réel à partir de la seule priorité des règles lorsque le signataire et le moteur de règles appartiennent à des services différents. Capturez le chemin réel et les modalités de traitement prises en charge avant de proposer une modification de commande. RFC 6376 section 5.1
Suivez deux cas de bannières fictives
Dans le premier cas fictif, example.com signe un message complet, puis un relais sortant ajoute « Pour un usage professionnel uniquement ». Supposons que la signature soit vérifiée avant le relais et que les nouveaux mots apparaissent à l'intérieur de sa couverture corporelle canonisée. La représentation finale ne vérifie plus sous cette signature originale. Un deuxième chemin authentifié aligné nécessiterait une évaluation séparée ; un échec DKIM n’est pas automatiquement un résultat final DMARC échec. RFC 9989 section 5.3
Dans le deuxième cas fictif, l'entrée approuvée d'une organisation réceptrice enregistre une signature originale valide, puis insère une bannière d'avertissement interne. L’évaluation d’entrée préservée et un échec de vérification ultérieur peuvent tous deux être cohérents avec l’historique de traitement. Aucun des deux cas ne prouve comment fonctionne une passerelle réelle. La question du remède diffère : corriger l’ordre de signature sortant dans le premier cas et préserver avec précision les limites d’évaluation dans le second.
Traitez le packaging comme une structure de message différente
Lorsqu'une clause de non-responsabilité ne peut pas être insérée, les choix de secours documentés de Microsoft incluent l'emballage de l'original en tant que pièce jointe dans un nouveau message. La documentation décrit également les règles ultérieures examinant le nouveau message externe. Une signature conservée sur un original joint ne doit pas être confondue avec une signature authentifiant le message extérieur portant la clause de non-responsabilité. Inspectez les deux couches si cette solution de secours est réellement utilisée. Options de secours Microsoft
Microsoft interdit spécifiquement les règles Wrap-in affectant les messages entrants provenant d'expéditeurs externes, car elles interfèrent avec l'analyse des pièces jointes sécurisées. Pour ces règles, Microsoft recommande d'utiliser Reject à la place ; cette solution de secours renvoie le message d'origine à l'expéditeur dans un rapport de non-remise. Cette restriction spécifique au produit ne constitue pas une autorisation de modifier une règle et aucune action de rejet n'a été configurée ou exécutée ici. Restriction des messages entrants Microsoft
L'emballage modifie également l'expérience du destinataire et le traitement en aval. Le plan d'acceptation doit inclure l'ouverture de la pièce jointe, le comportement de réponse, les exigences d'analyse et tout contenu qui doit rester visible. Ne sélectionnez pas une solution de secours uniquement parce qu’elle évite un indicateur d’authentification. Le contenu crypté ou autrement non modifiable nécessite une décision de traitement approuvée par le propriétaire plutôt qu'une exception universelle supposée.
Séparez les avertissements et les décisions de livraison
Une clause de non-responsabilité n'authentifie pas son auteur et une bannière d'avertissement ne prouve pas que le message a échoué DMARC . DMARC évalue le domaine de l'auteur par rapport à des identifiants authentifiés alignés ; la disposition du message reflète également la politique du récepteur et d’autres signaux. Décrivez indépendamment la règle réelle et le résultat de l'authentification, en particulier lorsqu'une bannière est basée sur une origine externe plutôt que sur un échec d'authentification. RFC 9989 sections 4.1 et 5.3
Clôturez une évaluation approuvée avec des échantillons de messages bruts directs et indirects, des preuves de correspondance de règles, des copies transformées et des résultats par signature. Incluez les messages qui doivent correspondre et ceux qui ne doivent pas correspondre, du texte brut et du HTML le cas échéant, et une gestion répétée qui pourrait faire double emploi avec une clause de non-responsabilité. Aucun de ces contrôles en direct n'a eu lieu ici, donc le rendu, le comportement des locataires et la livraison réelle restent des portes ouvertes.