¿Cómo mejorar el envío de correos electrónicos y la fiabilidad de la entrega?

Question

La aplicación actual usa Simple Java Mail para enviar un par de correos electrónicos por día, pero algunos de los correos electrónicos nunca llegan al cliente.

Según los registros del servidor de aplicaciones, ha habido un par de tiempos de espera del servidor de correo, pero eso no explica todos los casos de correos electrónicos faltantes. Agregar una característica de reintento ayudaría con el problema del tiempo de espera, pero ¿hay algún otro enfoque para mejorar la confiabilidad del correo electrónico en general?

Answer 1

Es la naturaleza de SMTP que no implementa integridad transaccional.

Hace aproximadamente 6 años hice un análisis bastante detallado de por qué los correos de la empresa en la que trabajaba estaban fallando. Solo pude ver hasta el MTA receptor, pero esto mostró una correlación muy fuerte entre el tipo de MTA y la tasa de fallas (en ese momento, Novell Groupwise y Sendmail en el extremo remoto eran los más confiables, MSExchange el menos, con qmail y otros en el medio). Tenga en cuenta que esto fue muy empírico y puede haber reflejado la elección del producto frente a las habilidades disponibles en lugar de los problemas intrínsecos en MTA específicos, y ahora está bastante desactualizado. Además, no es algo que puedas controlar efectivamente.

Aunque, ya que tienes la oportunidad de desarrollar y poner en práctica su propia lógica en la parte superior de la MTA, no hay ninguna garantía de que:

1) si un mensaje de error después de salir de su MTA obtendrá ningún notificación rebote

2) si se envía un mensaje con una solicitud de DSN (ver RFC 1891) que el sistema remoto en realidad enviar de vuelta el DSN

las cosas más importantes que puede hacer para mejorar la capacidad de entrega es conocer mucho sobre SMTP, mantenga su propio MTA y configúrelo según corresponda. Uno de los problemas clave en estos días es que todos están tratando de detener el correo basura, y todos tienen su propio método para hacerlo. Y generalmente no te dicen la receta de su salsa secreta. De hecho, con el filtrado bayesiano, ¡es posible que ni siquiera lo sepan!

Supongo que el siguiente puerto de escala (después de que haya comprobado que su SPF es restrictivo y publicado, y que no está RBL'd) sería ver cómo se establece si su correo se está entregando, como Dije, no puedes confiar en los DSN. No se puede depender de la aplicación de errores en sus correos electrónicos (por ejemplo, enviándolos como HTML con, por ejemplo) ya que la mayoría de los MUA no cargarán contenido remoto (nuevamente para evitar el correo no deseado). Lo cual simplemente deja la opción de mantener el contenido en el servidor y enviar un enlace al contenido original. Pero esto nuevamente asume que sus destinatarios siempre quieren leer su mensaje.

C.

Answer 2

Si solo desea enviar un par de correos electrónicos al día a un conjunto finito de receptores y eso es todo, intente enviarlos a través de una cuenta de Gmail.

Answer 3

Configure un servidor de correo de calidad de producción disponible para su aplicación, y deje que maneje todos los detalles muy sucios del envío confiable de correo. Probablemente estés superando algunas de las limitaciones, como la clasificación gradual, diseñada para mantener alejados a los spambots.

Un escenario razonablemente simple sería Postfix en una máquina Linux. Personalmente me gusta Ubuntu

Answer 4

Thorbjørn y symcbean han tanto proporcionado mucha información útil, pero puede ser abrumador en su integridad.Trataré de hacerlo más accesible:

Lo peor que puedes hacer es crear un cliente SMTP en tu aplicación y confiar en eso para enviar correos a algún lugar del mundo. Una solución mucho mejor es ejecutar localmente un servidor MTA y/o SMTP "estándar" o, en el peor de los casos, dentro de su propia red.

De modo que su aplicación solo tiene que recibir el correo hasta su propio servidor de correo, que con suerte estará en el puerto 25 en la misma máquina. Sin codificación SSL, sin filtro de spam, no hay muchas cosas que pueden salir mal. Además, si su servidor de correo está en la misma máquina que su aplicación, (normalmente) ambos estarán inactivos o ambos arriba.

Una vez que su aplicación ha enviado su correo a su servidor de correo local (que es rápido y casi infalible), es el problema de ese servidor que el correo se envíe al destino final. En un servidor Linux, tendrá algo como Sendmail, qmail, exim o postfix instalado; en Windows, no sé.

Cualquiera de esos servidores de correo "listos para usar" es altamente competente para recibir correo. Ya se ha incorporado una repetición automática, con reintentos después de (por ejemplo) 1 hora, 2 horas, 4, 12, 24 y 48 horas. Su servidor de correo intentará hacer todo lo posible para entregar su correo, y lo hará sin ningún esfuerzo adicional de su parte. Los intentos fallidos aparecerán en el registro del servidor de correo, y usted puede analizar eso y sacar sus conclusiones. Si falla después del último intento posible, eso también se observa en el archivo de registro, y puede concluir que algo estuvo mal en el lado de recepción. Todo este poder ya está incorporado, y ni siquiera debería pensar en tratar de construirlo en un cliente de correo propio.

Nota final: es posible que la transferencia sea exitosa físicamente, es decir, que el mensaje fue entregado, pero luego fue tratado como correo no deseado por el servidor o cliente de correo del destinatario; o el destinatario (humano) simplemente lo borró por accidente. Ningún software resolverá ese problema con certeza.

Answer 5

En mi opinión, ejecutar su propio servidor de correo se está convirtiendo rápidamente en algo del pasado.

Si mi aplicación va a enviar más de unos pocos correos electrónicos, normalmente configuro un proveedor de correo electrónico como servicio y me olvido de ello. La mayoría de ellos le permite usar su SMTP en su aplicación.

Como beneficio adicional, la mayoría de ellos le mostrarán estadísticas sobre quién hace qué con sus correos electrónicos.

Algunos de los nombres más conocidos en ese espacio son sendgrid, mailjet y postmarkApp, pero se puede encontrar una comparación interesante here