Un rebond arrivant après que quelqu'un a déjà rejeté un message est facile à mal lire. Il peut décrire la tentative initiale, le remplacement ou un événement retardé en aval. Établissez l’identité et le calendrier de chaque soumission avant de prendre une autre action. La notification la plus récente dans la boîte de réception ne constitue pas nécessairement une preuve du message le plus récent.
Distinguer un avertissement d'une panne de terminal
Une notification d'état de livraison peut signaler un retard plutôt qu'un échec. RFC 3464 les définit comme des valeurs d'action différentes. Un rapport retardé signifie que, lorsqu'il a généré le rapport, le système de reporting poursuivrait les tentatives de livraison ; consultez ses champs d'état et mettez les preuves en file d'attente plutôt que de traiter l'avertissement comme une annulation. Will-Retry-Until, lorsqu'il est fourni, fournit un horizon de nouvelle tentative indiqué, et non une preuve que la livraison est déjà terminée. RFC 3464 section 2.3.
Action : échec signifie que le rapport MTA tentatives abandonnées pour ce destinataire. Il peut accompagner un statut 4.xx transitoire, qui décrit la cause plutôt qu'une promesse d'une autre tentative. Un constat d'échec est terminal pour l'action de diffusion signalée, mais il ne peut concerner qu'un seul destinataire et une seule tentative. Préservez le blocage des destinataires, l’heure de soumission d’origine, le système de reporting et le diagnostic. Une soumission corrigée ultérieurement a son propre cycle de vie même lorsque son sujet et son contenu semblent identiques au premier message.
Construire la chronologie à partir des preuves de file d'attente
Créez une ligne par tentative ou notification : heure de soumission, identifiant de file d'attente, destinataire de l'enveloppe, ID de message, saut d'acceptation ou de rejet, classe de réponse et disposition actuelle. Incluez les tentatives de livraison originales ainsi que les resoumissions manuelles. N'utilisez pas l'heure d'arrivée de la notification comme substitut à l'heure de la dernière tentative décrite dans le rapport.
Pour une route à sauts multiples, un relais sortant peut accepter le message et continuer à fonctionner une fois que l'application l'a marqué comme envoyé. Demandez quel système possède actuellement la file d'attente. Le bouton de renvoi d'une application peut créer une nouvelle soumission plutôt que de demander à la file d'attente de relais existante d'essayer plus tôt. Cette différence détermine le risque de livraisons et de traitements commerciaux en double.
Suivez une chronologie hypothétique à deux files d'attente
À 9h00, supposons qu'une soumission originale entre dans la file d'attente Q-original. A 09h10, un destinataire reçoit un refus temporaire de capacité et reste en attente. À 09h20, un utilisateur appuie sur Renvoyer, créant un remplacement Q. À 09h30, la capacité revient et les deux files d'attente atteignent plus tard l'acceptation finale des DATA. Ces délais inventés expliquent la commande, et non un intervalle de nouvelle tentative conforme aux normes ou un calendrier du fournisseur.
Le remplacement n'a pas annulé l'original, donc deux événements de livraison acceptés sont possibles. Un avertissement de retard concernant l'arrivée du Q-original après 9h30 pourrait décrire son état antérieur, et non l'état actuel du remplacement du Q. Utilisez le destinataire, les identifiants de file d’attente, les temps de tentative et les journaux actuels pour établir cette relation. Des sujets similaires ou des ID de message à eux seuls ne le prouvent pas.
Aucune transaction n'a été exécutée pour cet exemple. En cas d'incident réel, distinguez chaque saut accepté de la livraison confirmée dans la boîte aux lettres et demandez au propriétaire de l'application si des messages en double pourraient déclencher des actions commerciales en double. Préservez les deux enregistrements plutôt que de réécrire l'original pour un remplacement réussi.
Décider si une autre soumission est justifiée
Vérifiez d'abord l'état actuel des tentatives d'origine et de remplacement. Si l'un ou l'autre est toujours en file d'attente ou si sa réponse finale est incertaine, un autre renvoi augmente l'ambiguïté. Un délai d'attente après l'envoi des données du message peut laisser l'expéditeur incertain si le destinataire a accepté le message, un risque reconnu dans la discussion sur le délai d'attente et la fiabilité de SMTP . RFC 5321 sections 4.5.3.2 et 6.1.
Si un original reste en attente, utilisez les contrôles de file d'attente pris en charge par le service uniquement avec les autorisations appropriées. Ne supprimez pas le courrier professionnel en file d'attente simplement pour régler l'incident, et ne présumez pas qu'une annulation a réussi jusqu'à ce que le système la confirme. Pour le contenu transactionnel urgent, coordonnez-vous avec le propriétaire de l'application afin que la transmission répétée des messages ne répète pas une action commerciale irréversible.
Fermez chaque tentative séparément
Enregistrez si chaque soumission a échoué, a expiré, est restée en attente, a été annulée via une action autorisée ou a été acceptée au niveau du saut concerné. Liez la notification tardive à la tentative qu’elle décrit réellement. Si la corrélation reste incertaine, dites-le plutôt que de déclarer l’échec de l’envoi le plus récent.
Communiquez le résultat pratique à l'expéditeur : si le destinataire prévu a reçu l'information et si une action en double nécessite une attention particulière. Gardez l'acceptation SMTP , la livraison par boîte aux lettres et l'achèvement des activités distincts. Un calendrier précis est plus utile qu’un autre renvoi non vérifié.
Décidez avant un autre renvoi
- Original en attente : confirmez la propriété de la file d'attente et les contrôles de tentative suivante pris en charge.
- Remplacement en attente : enquêtez-le séparément ; son existence n'annule pas l'original.
- Acceptation incertaine : concilier la réception des preuves avant d'ajouter une autre copie.
- Échec final : établir à quel destinataire et à quelle soumission il appartient.
- Clôture : enregistrez chaque soumission et confirmez si une action commerciale en double nécessite votre attention.