taken - Cumplimiento del código de error SMTP

error smtp 550

Question

No estoy muy seguro de si este es el mejor lugar para plantear esta pregunta (o en serverfault). Estoy usando un componente .NET SMTP de terceros para enviar correos electrónicos directamente al servidor de correo de los destinatarios. Necesito hacer esto para obtener el resultado en tiempo real de la entrega. Enviar a través de otro servidor SMTP requiere que obtenga el resultado de forma asíncrona a través de los informes de DSN, lo cual es demasiado complicado para la naturaleza de mi aplicación.

De todos modos, tengo problemas con el servidor SMTP de destino que devuelve un código de error que no concuerda con el mensaje de error. Como tal, no puedo etiquetar la entrega como un rebote fuerte o suave. Por ejemplo, el código de error de respuesta es 450 (es decir, el buzón de correo no está disponible), pero el mensaje de respuesta tiene que ver con un tiempo de espera excedido. Cuando envío el mismo mensaje nuevamente, se procesó. Claramente un problema de tiempo de espera para el envío anterior.

También me di cuenta de que el problema podría no ser el servidor SMTP receptor, sino el servidor de seguridad / proxy (como se llame), que está protegiendo el servidor.

¿Alguien ha encontrado un problema similar y cómo lo enfrentas?

PD: Trataré de proporcionar más detalles de mi registro cuando regrese a mi oficina.

Answer 1

Suena como greylisting. Lo cual es gracioso, porque cuando comencé a leer tu pregunta, ese fue uno de los primeros obstáculos que pude anticipar.

La lista gris es un método antispam que funciona mediante una entrega fallida en base a que los MTA legítimos intentarán volver a enviar el mensaje después de un período de tiempo. Lamentablemente, dos cosas no funcionan a su favor:

• El período de lista gris se puede elegir al azar. Lo que significa que a veces se necesitarán varios intentos antes de que se acepte un mensaje para la entrega.
• Aunque los códigos 4xx siempre deben tratarse como fallas blandas y se usan para este propósito, no hay ningún requisito para que el servidor le avise que se debe a una lista gris. Algunos serán tan amables y otros no.

La forma de lidiar con eso dependerá de si los fallos blandos se consideran un fracaso final a los fines de lo que está haciendo su aplicación. Si no lo son, tendrás que idear algunas colas y nuevos intentos confiables. Mi honesto consejo para usted es que probablemente sea más fácil implementar DSN confiable o comprobación de logs que inventar su propio MTA compatible con RFC (y peculiar).