Aller au contenu

E-mail authentifié : la réception reste à confirmer

Un contrôle de domaine réussi n’indique pas où le message arrive. Distinguez contrôle technique, acceptation et réception visible dans le produit.

Nora Henning2 min de lecture
Enveloppe portant un sceau de vérification bleu devant une fente de boîte aux lettres grise.

Une application peut terminer une tâche métier avec succès puis échouer lors de l’envoi de l’e-mail associé. Si votre interface réunit les deux sous une seule coche verte, l’équipe ne sait pas à quel endroit intervenir.

Un message possède plusieurs états observables

Dans la conception de produit fictive, un portail d’assistance crée la notification N-68. Le service d’envoi accepte la tâche. Un retour du système de messagerie destinataire arrive ensuite. L’interface doit en déduire exactement l’affirmation étayée.

Observation dans la conception

Message à afficher

Pas encore établi

Remise au service d’envoi confirmée

Remis au service d’envoi

Acceptation par le système destinataire

Acceptation par le système destinataire confirmée

Accepté par le système de messagerie destinataire

Classement visible en boîte de réception

La personne chargée du test confirme l’arrivée dans la boîte de test

Visible dans la boîte de test contrôlée

Réception par tous les autres destinataires ou lecture par les clients

Ce tableau propose une correspondance pour la conception. Il ne contient aucun test d’envoi réalisé ici. Les retours disponibles doivent être précisés pour le service utilisé et ses événements.

Le contrôle du domaine répond à une autre question

Un résultat DMARC réussi confirme l’usage autorisé du domaine d’expéditeur, pas la qualité ni l’innocuité du contenu. Il ne constitue pas non plus une garantie générale d’acceptation. Le destinataire peut appliquer d’autres contrôles et décider autrement.

Le message affiché par le produit ne devrait donc pas transformer automatiquement un résultat d’authentification positif en « livré ». Inversement, l’absence en boîte de réception n’explique pas à elle seule quel mécanisme d’authentification serait défaillant. Examinez ensemble le parcours d’envoi et le retour précis.

Traiter les retours comme une partie de l’application

AWS décrit des événements distincts pour les messages retournés et les plaintes, et signale la possibilité de notifications multiples. Pour cette conception, l’application doit donc rattacher les événements au message et définir le traitement des retours répétés. Un second événement ne devrait pas déclencher sans raison un second message.

Si un événement manque, cette partie de l’état reste inconnue. Surveillez ces cas et attribuez leur traitement à un rôle responsable. L’équipe peut ainsi gérer la notification tandis que l’état de la tâche métier reste traçable. L’affirmation dans l’interface suit alors l’observation disponible.

Sources

Écrit par

  • Nora HenningRédactrice sécurité informatiqueNora Henning s’occupe chez ASES des contenus éditoriaux consacrés à la sécurité informatique. Elle écrit sur la sécurité des applications et explique le lien entre les droits d’accès et la protection des données de l’entreprise.

Suivre ASES

À lire aussi

Tous les articles

Votre projet avec ASES

Décrivez-nous votre projet. Nous revenons vers vous avec une première évaluation.