Si un servidor de correo de menor prioridad solo sirve el código 450, ¿los servidores de envío al reintentar utilizarán un servidor de mayor prioridad?

Si un servidor de correo de menor prioridad solo sirve el código 450, ¿los servidores de envío al reintentar utilizarán un servidor de mayor prioridad?

Tenía un servidor de correo de respaldo que se alimentaba de un montón de mensajes y solo quiero configurar un servidor simple para enviar 450todos los mensajes.

Sin embargo, no estoy seguro de que sea una buena idea porque si los servidores de envío al reintentar no intentan enviar al servidor de mayor prioridad, los mensajes nunca podrán entregarse.

No pude encontrar nada en los RFC sobre esto, pero ¿los servidores vuelven a intentarlo en un servidor de mayor prioridad o intentan siempre en el mismo servidor que respondió 450?

Respuesta1

Cuando falla la entrega SMTP(sin recibir permanentemente5xyrespuesta SMTP de finalización negativa) y no hay ningún MX alternativo/de respaldo definido, IIRC elLos RFC lo dejan en manos de la implementación del remitentesi se intenta la entrega nuevamente y con qué frecuencia y durante cuánto tiempo se realizarán los intentos de entrega posteriores. Los estándares también dejan en manos de la implementación del remitente si y¿Qué tan pronto se reciben las notificaciones de retrasos temporales en la entrega?ser devuelto al remitente original y/o¿Qué tan rápido aparece una notificación de error de falla de entrega permanente?es regresado.

Cuando más de unoregistro MXestá definido para el dominio del destinatario, entonces, para cada intento de entrega, un remitente que cumpla con los estándares debe intentar la entrega a todos los registros MX, uno tras otro y respetando su prioridad, hasta que cualquiera de los MX acepte el mensaje (el remitente recibe un2xxrespuesta SMTP de finalización positiva), o un MX rechaza el mensaje (con un5xyrespuesta SMTP de finalización negativa permanente) o hasta que todos hayan sido contactados.
Cuando ninguno de los registros MX (principal o de respaldo) ha aceptado o rechazado permanentemente el mensaje de correo para su dominio, entonces esperaría que se siga la misma ruta de falla, específica de la implementación del remitente, que en el caso en que no existan registros MX alternativos. Yo otras palabras:"el remitente puede poner el mensaje en cola para un intento de entrega posterior o darse por vencido".

Hacer o no hacer

El concepto completo de múltiples registros MX y un servidor de correo de respaldo bajo su propio control es el hecho de que usted lo controla y no tiene que depender de la política de colas y reintentos del remitente original, o la ausencia de la misma.

Cuando no quieres ese control;Cuando no desee que su MX de respaldo ponga en cola su correo pero quiera dejar la cola y el reintento de entrega en manos del remitente, simplemente no configure un registro MX de respaldo en absoluto.Eso debería tener el mismo efecto (si no mejor) que configurar un MX de respaldo que apunte a un servidor que solo genera errores y que en realidad no aceptará ni pondrá en cola su correo electrónico.

En mi humilde opinión, el propósito previsto de un MX de respaldo

Es que cuando su servidor principal se desconecta y/o deja de estar disponible debido a una interrupción o mantenimiento planificado, los RFC y una implementación correcta del protocolo SMTP por parte del remitente deben garantizar que los mensajes de correo electrónico dirigidos a su dominio se envíen a su respaldo. MX, donde el correo será aceptado y puesto en cola durante el tiempo necesario para que finalice la interrupción (planificada).
Su servidor de correo de respaldo (y no el remitente) controlará si y cuándo se enviarán o no las notificaciones de retraso/fallo en la entrega del correo al remitente original.
Una vez que finalice la interrupción y su servidor de correo principal y sus buzones de correo estén en línea nuevamente, puede vaciar la cola en el MX de respaldo y (casi) inmediatamente recibir todo el correo en cola. Con elETRNComando SMTP, por ejemplo.

Respuesta2

Como se sugiere en el comentario de jcaron:

¿Hay alguna razón para tener un segundo MX que envíe 450? No tener nada en absoluto (es decir, ningún servidor que responda en ese puerto, o ningún segundo MX en la lista) debería tener el mismo resultado y sería menos trabajo... Pero tenga en cuenta que cualquiera que sea la solución, los remitentes no conservan el correo para siempre. Si bien muchos lo volverán a intentar durante días, algunos tendrán un tiempo de espera mucho más corto (¡y algunos incluirán su dirección en la lista negra al primer error!).

La solución adecuada a su problema XY es no tener un MX de respaldo. Nunca es necesario tener más de un MX. Cada remitente legítimo vuelve a intentar la entrega durante más de un día, a menudo durante más de una semana. En el caso de que su servidor tenga un tiempo de inactividad y no pueda aceptar el correo de inmediato, dejarlo como responsabilidad del sistema de correo del remitente, en lugar de algún servicio de cola de terceros incompleto, es obviamente lo correcto. No sólo evita que su correo sea "comido"; también evita confiar en un tercero con autoridad para interceptar su correo y garantiza que el remitente será notificado (mediante su propio sistema de correo) en caso de que una interrupción extremadamente prolongada haga que su correo no pueda entregarse.

En cuanto a su pregunta real, no se especifica lo suficiente cómo funciona el reintento para SMTP y no estoy seguro de que haya algunagarantizarque un remitente conforme volvería a probar su principal después de encontrarlo inalcanzable, en lugar de continuar intentando entregar al MX secundario falso informando fallas temporales. Entonces, incluso sin el razonamiento anterior por quéno deberíaSi tienes un MX secundario, creo que es una mala idea probar este truco en particular.

En caso de que sea relevante, mi experiencia con esto es de más de 22 años ejecutando continuamente un sistema de correo personal/de sitio pequeño y sin haber usado nunca más de un MX.

información relacionada