Un message peut utiliser une adresse d'expéditeur familière tout en dirigeant les réponses vers un autre endroit. Cette différence peut être légitime, comme un service de billetterie, ou elle peut rediriger une conversation sensible. Examinez les champs réels et la limite de confiance de réception avant de qualifier la non-concordance d'attaque ou de traiter l'authentification comme une approbation de la destination de la réponse.
Comprendre le rôle du terrain
RFC 5322 décrit Reply-To comme la ou les boîtes aux lettres auxquelles l'auteur suggère d'envoyer des réponses. En son absence, les réponses vont normalement dans la boîte aux lettres De. Il s'agit d'une instruction au format message, distincte de la livraison d'une enveloppe SMTP et d'une décision d'approbation humaine. Les clients et les outils de flux de travail peuvent appliquer leur propre comportement de réponse, alors inspectez le destinataire réel avant d'envoyer une réponse sensible. RFC 5322 section 3.6.2.
DMARC utilise le domaine de l'auteur, et non le champ Répondre à, pour sa relation d'identité. Une passe n'établit donc pas qu'un domaine de réponse différent appartient à la même organisation. Un valide Signature DKIM peut couvrir Reply-To lorsque ce champ est inclus dans la liste des en-têtes signés de la signature, mais l'intégrité d'une valeur ne constitue pas une autorisation de l'utiliser pour une correspondance confidentielle. DMARC et DKIM.
Annotez l'original plutôt qu'une capture d'écran
Conserve les octets bruts du message. Créez une annotation distincte affichant De, Répondre à, Return-Path, DKIM d= and h= values, and the receiving system that produced Authentication-Results. Marquez De et Répondre à comme champs fournis par l'expéditeur, la signature DKIM comme réclamation nécessitant une vérification et les résultats d'authentification comme étant fiables uniquement lorsque leur provenance est établie. RFC 8601.
Ne présumez pas qu’une ligne Authentication-Results copiée est authentique. De même, un champ Return-Path dans un fichier texte enregistré arbitrairement ne prouve pas indépendamment l'enveloppe SMTP . Effectuez une corrélation avec les journaux de réception autorisés si nécessaire.
Comparez trois scénarios d'en-tête écrits
Supposons que ce soit visible depuis billing@supplier.example.test dans chaque cas. L'identité de l'enveloppe, les valeurs DKIM d= et h=, les signatures réelles et les résultats du récepteur de confiance ne sont pas fournis. Une assertion de réussite copiée ne peut pas combler ces lacunes.
- Itinéraire inattendu : Répondre à case@support.example.test ; aucune approbation de flux de travail n'est fournie. Marquez les différents domaines exacts pour examen, conservez les réponses sensibles et demandez au propriétaire du service via un canal connu.
- Route du même domaine : Répondre à help@supplier.example.test . Une règle de non-concordance de domaine exact ne le signalerait pas, mais cela ne constitue pas une preuve que la boîte aux lettres ou les informations demandées sont autorisées.
- Exception de portée : Répondre à case@tickets.example.test ; supposons qu'un inventaire fictif autorise ce service uniquement pour les tickets d'assistance de routine. Traitez-le comme prévu à cette fin, et non comme une autorisation de modification de paiement ou de documents confidentiels.
Ces exemples sont des valeurs et des décisions écrites, et non un fichier .eml inclus, une exécution d'analyseur ou un résultat d'authentification réel. Aucune signature DKIM n’est fabriquée. Le propriétaire du service proposé vérifie à la fois les informations sur le destinataire et celles autorisées avant une véritable réponse ; l'enquêteur du courrier obtient séparément les octets originaux et les preuves d'authentification fiables.
Vérifier la destination de la réponse par rapport au workflow
Demandez au propriétaire du service si la destination externe est attendue pour ce type de message et si elle est appropriée pour les informations proposées. Une boîte aux lettres d'assistance peut légitimement différer d'un expéditeur de facturation, tout en étant inadaptée aux instructions de paiement ou aux pièces jointes sensibles. L'approbation doit correspondre à l'objectif, et pas seulement à l'existence du domaine.
Pour les demandes inattendues, contactez l’expéditeur présumé via un canal indépendant connu. Ne testez pas une destination douteuse en envoyant par courrier électronique du matériel confidentiel. Si un client a automatiquement renseigné Répondre à, annulez le brouillon jusqu'à ce que la destination soit vérifiée.
Fermez la question au niveau du champ
Enregistrez si l’inadéquation était attendue, non autorisée ou non résolue, et quelles preuves étayent cette conclusion. Conservez les résultats d’authentification comme une observation distincte. Cela préserve une distinction utile : un message peut être intact et authentifié par domaine alors que son itinéraire de réponse suggéré est inapproprié pour l'action commerciale.