Un attaquant n'a pas besoin de vaincre SPF ou DKIM écrire « spf=pass” ou « dkim=pass” dans un en-tête. Ces chaînes deviennent dangereuses lorsqu'un outil en aval traite le texte fourni comme une évaluation fiable. La défense repose sur une interprétation tenant compte de la provenance, et non simplement sur une liste plus longue de mots-clés favorables.
Extraction séparée de l’évaluation
Un analyseur peut montrer de manière fiable qu'un message contient un champ particulier. Il ne peut pas établir que le service d'authentification revendiqué l'a produit. Un analyseur doit conserver toutes les occurrences pertinentes, identifier l'origine des preuves fiables et garder les rapports non fiables en dehors du verdict de sécurité. Préservez le champ brut pour l'enquête plutôt que d'effacer silencieusement les preuves de l'original stocké.
RFC 8601 décrit le risque de falsification Authentication-Results et la nécessité d'une gestion des limites de confiance. L'identifiant authserv-id n'a de sens que dans ce contexte établi. Faire correspondre une chaîne configurée n'est pas suffisant si un expéditeur peut injecter un champ avec la même chaîne et que la passerelle lui permet de survivre comme étant apparemment fiable. RFC 8601 section 7.
Tester le cas d'usurpation d'identité du même nom
Dans un test contrôlé hypothétique, un message d'entrée contient Authentication-Results revendiquant l'identifiant authserv-id mx.receiver.example et dmarc=pass. Le véritable destinataire utilise ce même identifiant de service mais détermine un résultat différent. Le texte injecté n'est pas fiable simplement parce que le nom correspond.
La section 5 RFC 8601 exige une conformité MTA pour supprimer un champ de Authentication-Results découvert qui revendique sa limite de confiance mais n'est pas arrivé directement d'un autre MTA de confiance ; son exemple décrit également l’obscurcissement d’une telle affirmation. Vérifiez ensemble la gestion des entrées prise en charge et le verdict du consommateur qui en résulte. Ce guide ne prétend pas qu'une passerelle ait été configurée ou testée.
Pour l’analyste, conservez séparément la copie originale de la preuve autorisée. La conservation des preuves ne signifie pas transmettre un champ non sécurisé comme résultat fiable et en direct. Un test contrôlé doit également couvrir les doublons, les lignes pliées et les rapports légitimes provenant de systèmes en amont explicitement fiables. Les victoires du premier en-tête et les victoires du dernier en-tête ne remplacent pas cette conception des limites.
Évitez les solutions de secours trompeuses
Si aucun résultat fiable n’est disponible, affichez « non établi à partir de preuves de réception fiables » plutôt que de synthétiser une réussite à partir d’une affirmation externe. Si une vérification indépendante est effectuée, étiquetez-la comme une nouvelle évaluation avec son propre temps, ses propres entrées et limites. Une recherche DNS ultérieure peut différer des enregistrements en vigueur lors de la réception originale, de sorte qu'une reconstruction ne donne pas automatiquement le même résultat historique.
Les champs liés à l'ARC ne sont pas non plus des substituts ordinaires Authentication-Results auxquels on peut faire confiance simplement par l'orthographe. Un analyseur a besoin des décisions de validation et de confiance du récepteur applicables avant de s'appuyer sur un historique affirmé en amont. ARC la validation de la chaîne et la confiance du destinataire restent des exigences distinctes ; aucune validation ARC n'a été effectuée pour ce guide. Voir RFC 8617.
Donnez à l’opérateur un résultat exploitable
Signalez la source fiable sélectionnée, les réclamations ignorées et le motif de l'exclusion. Si la gestion des limites est inconnue, faites part de cette incertitude à l'administrateur de messagerie avant de recommander des modifications DNS . Conserver les originaux exportés par l'analyste immuables ; appliquer la gestion des entrées prise en charge requise au courrier en direct et conserver les journaux autorisés qui expliquent la décision. L’objectif n’est pas de cacher le matériel contrôlé par l’attaquant ; il s’agit d’empêcher ces éléments de contrôler le verdict.
Vérifiez la sélection du verdict en toute sécurité
- Conservez une copie autorisée des preuves avant analyse.
- Testez uniquement un chemin de réception contrôlé avec une portée explicite.
- Incluez un champ falsifié utilisant le nom du service de confiance, et pas seulement un nom externe évident.
- Confirmez la suppression de l'entrée ou l'obscurcissement et l'exclusion en aval du verdict.
- Signalez la provenance manquante plutôt que de convertir une chaîne de transmission externe en authentification.