Problème d'expiration du délai de messagerie SMTP

Question

Lorsque je crée un utilisateur pour mon application Web, un e-mail SMTP (utilisant SMTPClient d'ASP.NET) est envoyé à l'utilisateur avec le mot de passe généré automatiquement.Cependant, ce que je remarque parfois, c'est que le délai expire et que le nouvel utilisateur ne recevra tout simplement pas l'e-mail contenant le mot de passe.

Très bien, je vais donc afficher un message indiquant que le mail n'est pas passé mais que l'utilisateur est créé.

Par conséquent, l’administrateur système dispose jusqu’à présent de 2 options :

1. Réinitialisez le mot de passe de l'utilisateur et espérez qu'un autre e-mail SMTP sera envoyé avec le mot de passe généré automatiquement.
2. Supprimez et recréez l'utilisateur.

Je pourrais annuler la création de l'utilisateur si le smtp n'est pas envoyé, mais quelle est la meilleure pratique pour résoudre ce problème ?

Je pense que je devrais réessayer d'envoyer l'e-mail 3 fois avec un délai d'attente de 5 secondes chacune.Donc, 15 secondes seraient le pire des cas.

Est-ce la voie à suivre ?

Answer 1

Eh bien, en fonction de votre plate-forme, si vous pouvez simplement transmettre votre courrier à un MTA local, celui-ci devrait gérer les tentatives, etc.Votre programme peut simplement mettre le courrier en file d'attente et continuer, sans vous soucier des délais d'attente, des listes grises, etc.

Si le message ne peut toujours pas être envoyé, vous pouvez toujours essayer de le renvoyer (via une fonction de réinitialisation du mot de passe).Si cela échoue également, il y a très probablement une erreur dans l'adresse e-mail, et je suggérerais de supprimer le compte, ce qui obligerait l'utilisateur à se réinscrire.

Bien entendu, cela peut ne pas être possible sur certains systèmes, selon ce qui peut être fait avec un utilisateur non confirmé - cela dépend vraiment de ce que vous autorisez les gens à faire avant que leur courrier électronique ne soit validé.

Answer 2

Il semble que votre application Web communique directement en SMTP avec le serveur de messagerie de votre utilisateur.Votre application Web est un MUA (agent utilisateur de courrier) qui parle au MTA de l'utilisateur (agent de transfert de courrier).] Rien ne dit que le MTA de l'utilisateur doit être accessible ou fonctionner pour le moment.Vous devez exécuter votre propre MTA afin de vous assurer que quelqu'un assure la file d'attente, les tentatives, etc.

Si vous voulez vraiment vous mettre en quatre, vous pouvez faire ce que vous faites (une seule tentative cependant), mettre le message en file d'attente et continuer à réessayer selon un calendrier plus lent pendant au moins 24 heures, et exposer cet état inachevé au utilisateur.

La réponse officielle sur la façon dont votre application est censée se comporter peut être trouvée dans RFC1123 (Exigences pour les hôtes Internet – Application et support):

5.3.1.1 Stratégie d'envoi

Le modèle général d'un expéditeur-SMTP est un ou plusieurs processus qui tentent périodiquement de transmettre un courrier sortant.Dans un système typique, le programme qui compose un message a une méthode pour demander l'attention immédiate pour un nouveau courrier sortant, tandis que le courrier qui ne peut pas être transmis immédiatement doit être mis en file d'attente et réduit périodiquement par l'expéditeur.Une entrée de file d'attente de courrier comprendra non seulement le message lui-même mais aussi les informations d'enveloppe.

L'expéditeur doit retarder la réessayer une destination particulière après une tentative qui a échoué.En général, l'intervalle de réception doit durer au moins 30 minutes;Cependant, des stratégies plus sophistiquées et variables seront bénéfiques lorsque l'expéditeur-SMTP peut déterminer la raison de la non-livraison.

Les tentatives se poursuivent jusqu'à ce que le message soit transmis ou que l'expéditeur abandonne;Le temps d'abandon doit généralement être d'au moins 4 à 5 jours.Les paramètres de l'algorithme de réessayer doivent être configurables.

Answer 3

Si vous utilisez ASP.NET et les classes System.Net.Mail, vous envoyez probablement le courrier via l'instance IIS sur la machine du serveur Web (je n'en suis pas sûr puisque vous ne l'avez pas spécifié).Il n'existe pas de bon moyen de savoir ce qui se passe avec votre agent de transfert de courrier (IIS SMTP).Il a sa propre logique de nouvelle tentative et, par défaut, la transmission du message peut prendre beaucoup de temps.

Comment détectez-vous que le courrier n’a pas été livré ?D'où vient le "timeout" ?

Vous devez disposer d'un processus en arrière-plan qui gère l'envoi du courrier.Si la livraison au MTA réussit, vous devez supposer que tout va bien.À moins que vous ne soyez sur liste noire pour spam, la plupart des MTA continueront de réessayer jusqu'à ce qu'ils réussissent.Si vous obtenez réellement une erreur en envoyant le message avec votre MTA, réessayez définitivement ou déterminez la cause de l'échec et corrigez le bogue.Honnêtement, cette partie ne devrait jamais échouer.

Vous souhaiterez peut-être surveiller l'adresse de retour des messages de non-remise afin de pouvoir prendre des mesures lorsque vous savez avec certitude quand l'e-mail n'a pas été livré.Mais si l'utilisateur ne peut pas encore se connecter au système, il n'existe aucun moyen efficace de lui faire savoir ce qui s'est passé.Vous pourriez peut-être définir un cookie avec une valeur que vous associez à l'e-mail et mettre quelque chose sur la page de connexion/inscription si vous ne parvenez pas à livrer le courrier.

Answer 4

À mon humble avis, vous devez en informer l'utilisateur, lui demandant de vérifier l'e-mail, sans nouvelle tentative.

Si l'utilisateur ne vérifie pas l'e-mail et quitte la page, vous feriez mieux de restaurer le compte puisque l'utilisateur ne peut de toute façon pas y accéder.

La plupart des cas d'expiration seraient causés par des comptes de messagerie invalides.Les utilisateurs ont fait une erreur ou vous ont donné une adresse e-mail inexistante pour éviter d'être spammé.

Dans la mesure du possible, ne demandez pas les e-mails de vos utilisateurs.La règle numéro un de la programmation devrait être :NE PAS gêner l'utilisateur.