Comportamiento del servidor de prioridad MX

Esta es una pregunta sobre la prioridad del protocolo MX. Si tengo dos servidores como MX con diferente prioridad:

Servidor MX 10A
Servidor MX 20 B

¿Esto garantiza el protocolo que el MX 10 es el preferido? ¿Puede el remitente elegir el secundario por cualquier otro motivo que no sea la disponibilidad primaria?

En otras palabras: si mi servidor A MX funciona bien y tiene una capacidad de conexión infinita (teórica), ¿puedo estar seguro de que nadie intentará una conexión al servidor B?

smtp load-balancing mx-record Tobia
fuente

Respuestas:

En circunstancias normales, el servidor se conectará al primero que esté disponible, pero hay muchas razones por las cuales el primero puede no estar disponible para una persona pero no para la siguiente. Algunas de estas razones incluyen cosas sobre las que no tiene control. Sin embargo, la regla general es intentar de menor a mayor hasta que haya una respuesta y luego usar ese servidor.

Donde suele haber una excepción es el spam. A menudo, los registros MX de menor número apuntarán a servicios alojados, filtrado de spam, etc. El registro MX de mayor número será "a prueba de fallas" y a menudo apuntará directamente a la IP de su servidor. La idea es que si el servicio alojado falla el correo todavía se entregará. Con esto en mente, los Spammers buscarán el número más alto y enviarán correo allí.

Drifter104
fuente

Leí su respuesta interesante y también este artículo: blog.zensoftware.co.uk/2012/07/02/… donde aconsejan contra el mx secundario, pero ... Tengo una pregunta: cómo tener una copia de seguridad y también evitar el spam fest? ¿Es posible?

Tobia

@Tobia, por supuesto, pero simplemente significa no tenerlo apuntando a su propio servidor, pero esto también significa que no tiene redundancia si sus servicios alojados fallan. Solo depende de cuánto confíes en el servicio

Drifter104

Pero también tenga en cuenta que las fallas temporales generalmente serán puestas en cola y reintentadas por el MTA remitente; e incluso si no lo están (o si surge una condición de error permanente) el NDR al remitente probablemente llevará a reintentos manuales (o comunicación fuera de banda) de todos modos.

eggyal

No puede estar seguro porque el cliente también puede tener algunos errores de red y no puede conectarse serverA, luego repare la red e intente conectarse al servidor B.

emi
fuente

Bien, consideremos una situación teórica, ¿puede el cliente "elegir" el servidor B un mx o siempre lo intenta antes del MX primario? Quiero entender si la prioridad MX es algo como el equilibrio de carga o una conmutación por error.

Tobia

Un cliente siempre puede elegir si está programado para hacerlo. Como se indicó en la primera respuesta, la forma general en que los clientes se codifican en los servidores de producción es ir de baja a alta. Los clientes de spam a menudo funcionan de mayor a menor. Los clientes de prueba SMTP a veces incluso dejan que el usuario final decida

netniV

Depende completamente de la persona que escribió el motor SMTP que intenta hacer el contacto. Por diseño, intente MX en orden numérico ascendente, luego intente con el registro A. Sin embargo, el programador es libre de hacer o no hacer eso como lo crea conveniente y el correo normalmente todavía se entregará ...

Brian Knoblauch
fuente

Hacer o no hacer, no hay prueba? Esto se ha cubierto más arriba en las respuestas y los comentarios de dichas respuestas.

netniV

Encontré las respuestas anteriores incompletas ya que ninguna menciona la parte A del registro.

Brian Knoblauch

Responde sí, revisa los comentarios. Hay una referencia a la prioridad, etc. De todos modos, los registros A solo se usarían resolviéndolos de los registros MX.

netniV

Incorrecto. No solo los registros A señalados por los registros MX, sino el registro de dominio A especificado también se usa como un caso de último recurso para determinar el servidor de correo.

Brian Knoblauch

Software de correo correctamente escrita será probar el registro A del dominio. Ese comportamiento se especifica en los RFC.

Ley29