Problema de tiempo de espera del correo SMTP

Question

Cuando estoy creando un usuario para mi aplicación web, se envía un correo electrónico SMTP (usando SMTPClient de ASP.NET) al usuario con la contraseña generada automáticamente.Sin embargo, a veces lo que noto es que se agota el tiempo de espera y el nuevo usuario simplemente no recibe el correo electrónico con la contraseña.

Muy bien, mostraré un mensaje indicando que el correo no pasó pero que el usuario está creado.

Por lo tanto, el administrador del sistema tiene 2 opciones hasta ahora:

1. Restablezca la contraseña del usuario y espere que se envíe otro correo SMTP con la contraseña generada automáticamente.
2. Eliminar y volver a crear el usuario.

Podría revertir la creación del usuario si no se envía el smtp, pero ¿cuál es la mejor práctica para abordar este problema?

Estoy pensando que debería volver a intentar enviar el correo electrónico 3 veces con un tiempo de espera de 5 segundos cada una.Entonces 15 segundos sería el peor de los casos.

¿Es este el camino a seguir?

Answer 1

Bueno, dependiendo de su plataforma, si puede simplemente entregar su correo a un MTA local, este debería encargarse de los reintentos y demás.Su programa puede simplemente poner el correo en cola y seguir adelante, sin preocuparse por lidiar con tiempos de espera y listas grises, etc.

Si el mensaje aún no se puede entregar, siempre puedes intentar reenviarlo (mediante una función de restablecimiento de contraseña).Si eso también falla, lo más probable es que haya habido un error en la dirección de correo electrónico y sugeriría eliminar la cuenta, lo que provocaría que el usuario se volviera a registrar.

Por supuesto, esto podría no ser posible en algunos sistemas, dependiendo de lo que se pueda hacer con un usuario no confirmado; eso realmente depende de lo que permita que las personas hagan antes de que se valide su correo electrónico.

Answer 2

Parece que su aplicación web habla SMTP directamente con el servidor de correo de su usuario.Su aplicación web es un MUA (agente de usuario de correo) que habla con la MTA del usuario (agente de transferencia de correo).] Nada dice que la MTA del usuario debe ser accesible o trabajar en este momento.Debe ejecutar su propio MTA para asegurarse de que alguien proporcione colas, reintentos, etc.

Si realmente quiere hacer todo lo posible, puede hacer lo que está haciendo (aunque solo un intento), volver a poner en cola el mensaje y continuar reintentando en un cronograma más lento durante al menos 24 horas, y exponer ese estado inacabado al usuario.

La respuesta oficial sobre cómo se supone que debe comportarse su aplicación se puede encontrar en RFC1123 (Requisitos para hosts de Internet: aplicación y soporte):

5.3.1.1 Estrategia de envío

El modelo general de un remitente-SMTP es uno o más procesos que intentan periódicamente transmitir el correo saliente.En un sistema típico, el programa que compone un mensaje tiene algún método para solicitar atención inmediata para una nueva pieza de correo saliente, mientras que el correo no puede transmitirse de inmediato debe ser en cola y referido periódicamente por el remitente.Una entrada de cola de correo incluirá no solo el mensaje en sí sino también la información sobre el sobre.

El remitente debe retrasar el reintento de un destino en particular después de que un intento haya fallado.En general, el intervalo de reintento debe ser al menos 30 minutos;Sin embargo, las estrategias más sofisticadas y variables serán beneficiosas cuando el remitente-SMTP pueda determinar el motivo de la falta de entrega.

Los reintentos continúan hasta que se transmite el mensaje o el remitente se rinda;El tiempo de renuncia generalmente debe ser de al menos 4-5 días.Los parámetros al algoritmo de reintento deben ser configurables.

Answer 3

Si está utilizando ASP.NET y las clases System.Net.Mail, probablemente esté enviando el correo a través de la instancia de IIS en la máquina del servidor web (no estoy seguro porque no lo especificó).No existe una buena manera de saber qué está pasando con su Agente de transferencia de correo (IIS SMTP).Tiene su propia lógica de reintento y, de forma predeterminada, el mensaje podría tardar mucho en entregarse.

¿Cómo detectas que el correo no fue entregado?¿A qué se debe el "tiempo de espera"?

Debería tener un proceso en segundo plano que maneje el envío de correo.Si la entrega a la MTA se realiza correctamente, debe asumir que todo está bien.A menos que esté en la lista negra de SPAM, la mayoría de los MTA seguirán intentándolo hasta que logren comunicarse.Si realmente recibe un error al enviar el mensaje a su MTA, definitivamente vuelva a intentarlo o averigüe qué está causando la falla y solucione el error.Honestamente, esta parte nunca debería fallar.

Es posible que desee monitorear la dirección de devolución de los mensajes NDR para poder tomar algún tipo de acción cuando sepa con certeza cuándo no se entregó el correo electrónico.Pero si el usuario aún no puede iniciar sesión en el sistema, no hay una buena manera de informarle lo que sucedió.Tal vez podría configurar una cookie con un valor que asocie con el correo electrónico y colocar algo en la página de inicio de sesión/registro si no pudo entregar el correo.

Answer 4

En mi humilde opinión, deberías notificar al usuario y pedirle que verifique el correo electrónico, sin volver a intentarlo.

Si el usuario no verifica el correo electrónico y abandona la página, será mejor que revierta la cuenta ya que el usuario no podrá acceder a ella de todos modos.

La mayoría de los casos de tiempo de espera se deben a cuentas de correo electrónico no válidas.Los usuarios cometieron un error o le dieron una dirección de correo electrónico inexistente para evitar recibir spam.

Si es posible, no solicite los correos electrónicos de sus usuarios.La regla número uno de programación debería ser:NO moleste al usuario.