Un message qui semble avoir deux expéditeurs peut impliquer plusieurs choses différentes : un champ De contenant plusieurs auteurs, deux champs De distincts ou un nom d'affichage qui ressemble à une autre adresse. Ce sont des cas d’analyse et de sécurité différents. Une capture d'écran de la ligne de l'expéditeur d'un client de messagerie ne peut pas les distinguer de manière fiable.
Conservez l’en-tête du message d’origine et commencez par sa structure. Ne sélectionnez pas silencieusement l’adresse qui correspond à une signature de passage. Cela peut cacher l’ambiguïté que le destinataire et le destinataire doivent comprendre.
Séparer le nombre de champs du nombre d'adresses
RFC 5322 autorise un seul champ De avec une liste de boîtes aux lettres. Lorsque cette liste contient plusieurs boîtes aux lettres, un champ Expéditeur avec une boîte aux lettres est requis. Les règles de format de message spécifient toujours un champ De, donc deux champs De distincts ne constituent pas la même construction qu'un champ multi-auteur valide.
L'expéditeur identifie l'agent émetteur dans le modèle de format de message. Il ne remplace pas le domaine From car DMARCDomaine de l'auteur de. Répondre à, Return-Path et un nom d'affichage servent également à des fins différentes.
Utiliser la procédure pas à pas de la chaîne d'identité pour garder ces rôles séparés avant d'enquêter sur l'authentification.
Appliquer explicitement la règle de domaine DMARC
RFC 9989Le traitement normal de nécessite précisément un extrait du domaine. Si zéro ou plusieurs domaines sont extraits, son processus de validation ordinaire se termine. La spécification permet à un récepteur de continuer dans le cas de domaines multiples et discute des implications en matière de sécurité et de traitement.
Cela n’autorise pas un outil de diagnostic à choisir l’auteur le plus pratique et à signaler un succès sans réserve. Si un destinataire choisit d'évaluer plusieurs domaines, la procédure et la couverture qui en résultent doivent être enregistrées.
La section 11.5 traite de l'évaluation de chaque domaine et de l'application de la politique la plus stricte parmi les contrôles qui échouent. Il prévient également que le traitement d'un nombre excessif de domaines peut créer un problème de ressources ; si tous ne sont pas traités, l’évaluation est incomplète. Il s'agit de considérations liées au traitement du destinataire et non d'une promesse que chaque produit accepte ou affiche ce courrier de la même manière.
Utiliser des cas contrôlés avec des attentes étiquetées
Les cas ci-dessous sont des fragments d'en-tête synthétiques. Ce ne sont pas des tests exécutés ni des résultats de récepteur rapportés, et chacun aurait besoin du reste d'un message correctement construit dans un test contrôlé.
| Cas | Champs d'illustration | Bilan à enregistrer |
|---|---|---|
| Auteur unique | De : author@example.com | Chemin d'accès ordinaire à un domaine, soumis aux contrôles de messages et d'authentification restants |
| Plusieurs auteurs dans un même domaine | De : author@example.com , editor@example.net | Avec le champ Expéditeur séparé requis pour une boîte aux lettres unique, il peut s'agir d'un format multi-auteur valide ; plusieurs domaines From nécessitent toujours une analyse de gestion exceptionnelle DMARC |
| Dupliquer les champs De | Un champ De pour example.com et un autre pour example.net | Défaut de format de message ; ne pas le réparer de manière invisible en prétendant évaluer le message original |
| Nom d'affichage semblable à une adresse | Afficher le texte contenant une adresse apparente devant une boîte aux lettres réelle | Analysez le domaine de boîte aux lettres réel ; évaluer le risque d'affichage séparément |
Pour chaque cas, conservez la sortie brute du luminaire et de l’analyseur. Comptez les champs, répertoriez les valeurs de boîte aux lettres extraites et enregistrez le résultat du domaine qui a conduit au chemin de traitement choisi. Si deux boîtes aux lettres utilisent le même domaine, ne supposez pas que l'affichage du client de messagerie répond à la manière dont l'évaluateur gère cette construction multi-auteurs ; conserver son résultat d’extraction et tester l’implémentation.
Conserver la preuve d'authentification liée à l'identité analysée
Un SPF ou DKIM le mot de passe pour un domaine ne peut pas expliquer une autre identité affichée sans les informations requises alignement analyse. Préservez toutes les valeurs DKIM d pertinentes et les résultats des récepteurs de confiance. Conservez également les octets From exacts, y compris le pliage et les commentaires, afin que l'analyse puisse être reproduite.
Ne réécrivez pas le De original chez un seul auteur avant de vérifier la signature originale ou d'enquêter sur ce que le système de réception a vu. Une copie réécrite peut être utile en tant que cas de test distinct, mais étiquetez-la comme un appareil modifié avec une question d'identité différente.
Une tentative rejetée peut ne jamais produire d’en-têtes livrés. Préservez la réponse SMTP et les journaux de réception lorsqu'ils sont disponibles plutôt que d'inventer un système de livraison. Authentication-Results échantillon.
Présentation des tests ainsi que traitement
Le problème de sécurité inclut ce que voit un destinataire. Un composant peut évaluer une construction tandis qu'un client de messagerie met en évidence un auteur apparent différent. Dans un environnement de test autorisé, comparez le résultat de l'analyseur, le résultat de l'authentification, la gestion et la ligne d'expéditeur affichée pour exactement le même appareil.
Enregistrez les versions et les paramètres du logiciel avec des observations réelles. Ne copiez pas le comportement d'un client dans une affirmation universelle. RFC 9989 identifie les constructions à domaines multiples comme un moyen potentiel d'éviter le traitement DMARC normal, donc un résultat étiqueté « non évalué » ne doit pas être présenté comme « sûr ».
Une configuration sortante pratique bénéficie généralement d'une boîte aux lettres De vide pour le courrier automatisé ordinaire. Lorsqu'une véritable fonctionnalité multi-auteur est nécessaire, confirmez le format applicable et la gestion prise en charge avec les systèmes qui le traiteront plutôt que de supposer qu'un champ Expéditeur obligatoire résout tous les problèmes d'authentification en aval.
L'enquête est terminée lorsqu'elle préserve la syntaxe d'origine, explique la décision du domaine extrait et relie cette décision à la gestion et à la présentation réelles du récepteur. Gardez visibles les traitements exceptionnels ou incomplets au lieu de fabriquer une seule réponse d’authentification verte.