Un registro de intercambiador de correo ( registro MX ) especifica el servidor de correo responsable de aceptar mensajes de correo electrónico en nombre de un nombre de dominio. Es un registro de recursos en el Sistema de nombres de dominio (DNS). Es posible configurar varios registros MX, que normalmente apuntan a una matriz de servidores de correo para el equilibrio de carga y la redundancia.
Descripción general
Los registros de recursos son el elemento de información básico del sistema de nombres de dominio (DNS). Un registro MX es uno de estos, y un dominio puede tener uno o más de estos configurados, como se muestra a continuación:
Host de prioridad de tipo de clase TTL de dominioexample.com. 1936 EN MX 10 onemail.example.com.example.com. 1936 EN MX 10 twomail.example.com.
La información de carga útil característica de un registro MX [1] es un valor de preferencia (arriba etiquetado como "Prioridad") y el nombre de dominio de un servidor de correo ("Host" arriba).
El campo de prioridad identifica qué servidor de correo se debe preferir; en este caso, los valores son 10, por lo que se esperaría que el correo fluyera uniformemente tanto a onemail.example.com como a twomail.example.com , una configuración común. El nombre de host debe correlacionarse directamente con uno o más registros de direcciones (A o AAAA) en el DNS y no debe apuntar a ningún registro CNAME . [2]
Cuando se envía un mensaje de correo electrónico a través de Internet, el agente de transferencia de correo (MTA) remitente consulta al Sistema de nombres de dominio los registros MX del nombre de dominio de cada destinatario . Esta consulta devuelve una lista de nombres de host de servidores de intercambio de correo que aceptan correo entrante para ese dominio y sus preferencias. Luego, el agente de envío intenta establecer una conexión SMTP, probando primero el host con el valor de "Prioridad" más bajo. El sistema permite crear clústeres de pasarelas de correo de alta disponibilidad para un dominio si es necesario. [3]
El mecanismo MX no otorga la capacidad de proporcionar servicio de correo en números de puerto alternativos , ni brinda la capacidad de distribuir la entrega de correo a través de un conjunto de servidores de correo de prioridad desigual asignando un valor de ponderación a cada uno.
Preferencia, distancia y prioridad de MX
Según RFC 5321, los registros con el número más bajo son los más preferidos. [4] Esta redacción puede ser confusa, por lo que el número de preferencia a veces se denomina distancia : las distancias más pequeñas son más preferibles. Una RFC más antigua, RFC 974, indica que cuando los números de preferencia son los mismos para dos servidores, tienen la misma prioridad , por lo tanto, esos dos términos se usan indistintamente.
Los basicos
En el caso más simple, un dominio puede tener solo un servidor de correo. Por ejemplo, si un MTA busca los registros MX para example.com, y el servidor DNS respondió solo con mail.example.com con un número de preferencia de 50, entonces el MTA intentará entregar el correo al servidor listado. En este caso, el número 50 podría haber sido cualquier número entero permitido por la especificación SMTP.
Cuando se devuelve más de un servidor para una consulta MX, primero se debe probar el servidor con el número de preferencia más pequeño. Si hay más de un registro MX con el mismo número de preferencia, se deben probar todos antes de pasar a las entradas de menor prioridad. Un cliente SMTP debe poder probar (y reintentar) cada una de las direcciones relevantes en la lista en orden, hasta que un intento de entrega tenga éxito. [4]
Distribución de la carga
El enfoque estándar para distribuir una carga de correo entrante en una serie de servidores es devolver el mismo número de preferencia para cada servidor del conjunto. Al determinar a qué servidor de igual preferencia enviar correo, "el remitente-SMTP DEBE aleatorizarlos para distribuir la carga entre múltiples intercambiadores de correo para una organización específica", a menos que haya una razón clara para favorecer uno. [4]
Un enfoque alternativo es utilizar servidores de host múltiple , donde un host devuelve varias direcciones IP. [3] Este método coloca la carga en el sistema DNS en lugar del remitente SMTP para realizar el equilibrio de carga, que en este caso presentará una lista de direcciones IP en un orden específico a los clientes que consultan el registro A del intercambiador de correo. . Dado que el RFC requiere que el remitente SMTP use el orden dado en la consulta del registro A, el servidor DNS es libre de manipular cuidadosamente su balance basado en cualquier método, incluido el DNS por turnos , la carga del servidor de correo o algún esquema de prioridad no revelado.
MX "Copia de seguridad"
Algunos dominios tendrán varios registros MX, uno de los cuales está destinado a ser una "copia de seguridad", con un número de preferencia más alto para que normalmente no se elija como destino para la entrega de correo electrónico.
Sin embargo, en el caso de errores de los hosts con números más bajos (quizás debido a una interrupción de algún tipo), los servidores de correo electrónico de envío se entregarán al host de "respaldo": queue.example.com en el ejemplo siguiente:
Host de prioridad de tipo de clase TTL de dominioexample.com. 1936 EN MX 10 onemail.example.com.example.com. 1936 EN MX 10 twomail.example.com.example.com. 1936 EN MX 100 queue.example.com.
Si el servidor de respaldo tiene acceso directo a los buzones de correo de los usuarios, el correo continuará allí, pero de lo contrario, probablemente se pondrá en cola en queue.example.com hasta que se resuelva la interrupción.
En ausencia de este tipo de arreglo, cuando los servidores de correo de un dominio están todos fuera de línea, los servidores de envío deben poner en cola los mensajes destinados a ese dominio para reintentarlos más tarde. Sin embargo, estos servidores de envío no tienen forma de ser notificados de que los servidores de un dominio previamente desconectado ahora están disponibles, por lo que recurren a un programa de sondeo , y solo descubrirán que el dominio está disponible la próxima vez que intenten la entrega. La demora entre el momento en que los servidores de un dominio receptor se conectan y el momento en que finalmente se entregan los mensajes retrasados puede ser, por lo tanto, de minutos a días, dependiendo del programa de reintentos de los servidores de envío, y el dominio receptor no tiene visibilidad ni control sobre esto.
Spammers
Los spammers pueden dirigir deliberadamente el correo a uno de los servidores MX de respaldo (de alta distancia) de un dominio en primer lugar, asumiendo que dicho servidor tendrá filtros antispam menos efectivos. Una técnica anti-spam llamada nolisting se basa en asumir este comportamiento.
Manejo de fallas en la entrega
El SMTP RFC [4] es ambiguo acerca de exactamente qué tipos de fallos de entrega deben resultar en un nuevo intento de entrega a través de registros MX más distantes (aquellos con valores de preferencia más altos).
Cuando los servidores indican fallas temporales, ya sea enviando explícitamente un error 4xx o terminando la conexión inesperadamente (que debe tratarse como un error 451, de acuerdo con la Sección 3.8 de la RFC), la Sección 4.5.4.1 dice:
El remitente DEBE retrasar el reintento de un destino en particular después de que un intento haya fallado.
Sin embargo, cuando el remitente vuelve a intentarlo, la RFC no dice si debe ser en el mismo servidor o en un registro MX más "distante". Dice, en la Sección 5.1 :
Cuando la búsqueda se realiza correctamente, la asignación puede dar como resultado una lista de direcciones de entrega alternativas en lugar de una sola dirección, debido a varios registros MX, multihoming o ambos. Para proporcionar una transmisión de correo confiable, el cliente SMTP DEBE poder probar (y volver a intentar) cada una de las direcciones relevantes en esta lista en orden, hasta que el intento de entrega sea exitoso.
Algunos servidores (como Sendmail y Postfix 2.1 o posterior), [5] intentarán el siguiente servidor MX más lejano después de algunos tipos de fallas de entrega temporal, como fallas de saludo. [6] Otros servidores (como qmail y Postfix 2.0 o anteriores) solo usarán registros MX más distantes si los servidores especificados en los registros MX de distancia más corta no pudieron ser contactados en absoluto. A pesar de la diferencia, ambos comportamientos son válidos, ya que el RFC no es específico.
Volver al registro de direcciones
En ausencia de un registro MX, los remitentes de correo electrónico intentarán enviarlos al registro de direcciones, por ejemplo, example.com.
Esto se basa en RFC 5321 sec. 5.1, que establece:
- Los clientes SMTP deben buscar un registro MX;
- Si ( y solo si ) no hay ningún registro MX para el dominio, trate el dominio como si tuviera un registro MX con el dominio dado como el nombre de host de destino y un valor de preferencia de 0
- Realice búsquedas A o AAAA según sea necesario para determinar la dirección IP del nombre de host de destino
Antecedentes históricos
RFC 821 se publicó en 1982. Solo hace referencias de paso a DNS, porque en ese momento la transición de HOSTS.TXT a DNS aún no había comenzado. RFC 883, la primera descripción del DNS, se publicó más de un año después, a fines de 1983. Describía los registros MD y MF experimentales y poco utilizados. Según RFC 897 y RFC 921, la transición a DNS comenzó en 1983, pero HOSTS.TXT no estaba programado para eliminarse hasta finales de 1985 y no se eliminó por completo hasta finales de la década de 1990.
En enero de 1986, RFC 973 y RFC 974 desaprobaron los registros MD y MF, los reemplazaron con MX y definieron la búsqueda MX con respaldo a A. RFC 974 recomienda que los clientes realicen una búsqueda WKS [7] en cada host MX para ver si en realidad es compatible con SMTP y, si no, descarta la entrada MX. Sin embargo, RFC 1123 cambió esto para decir que WKS no debería estar marcado.
Esto significa que SMTP había estado en uso durante al menos un año usando HOSTS.TXT, y luego otro par de años usando A, MD y MF, antes de que apareciera MX. MD y MF eran difíciles de usar, por lo que la mayoría de la gente solo usaba el disco A. Dadas las circunstancias, MX sin respaldo a A no habría funcionado debido a la importante base instalada de servidores de correo que utilizan registros A. El primer uso de MX fue para identificar puertas de enlace a otras redes, pero no se generalizó hasta que el DNS estuvo bien establecido a principios de la década de 1990. [8]
Documentos de normas
- RFC 1035 (1987), Nombres de dominio: implementación y especificación
- RFC 1912 (1996), Errores comunes de configuración y funcionamiento de DNS
- RFC 5321 (2008), Protocolo simple de transferencia de correo
- RFC 7505 (2015), un registro de recursos sin servicio "MX nulo" para dominios que no aceptan correo
Obsoletos:
- RFC 2821 (2001), Protocolo simple de transferencia de correo (obsoleto por RFC-5321 )
- RFC 974 (1986), Enrutamiento de correo y sistema de dominio (obsoleto por RFC-5321)
Ver también
Referencias
- ^ En estos ejemplos, el nombre de dominio en cuestión está en la primera columna, el TTL (tiempo de vida) en la segunda y la tercera es la "Clase de registro" (en este caso, IN para Internet), luego MX para identificar el tipo de registro. El TTL es un período de validez, que indica cuándo se debe actualizar la información desde un servidor de nombres autorizado .
- ^ RFC 2181, Sección 10.3, Aclaraciones a la especificación de DNS , R. Elz, R. Bush (julio de 1997)
- ^ a b HOWTO - Configure Round Robin y Load Balancing , Página modificada: 28 de febrero de 2014., zytrax.com
- ^ a b c d RFC 5321
- ^ Si el MX primario responde, pero falla a mitad de la transacción, Postfix 1.2 y 2.0 no intentarán un MX de respaldo. Archivado 2009-06-23 en Wayback Machine , Re: no cambia a mx con menor prioridad, De: Victor Duchovni (Victor.DuchovniMorganStanley.com) Fecha: viernes 11 de noviembre de 2005
- ^ Un saludo fallido es un código de error que se envía en lugar de o en respuesta al saludo estándar SMTP.
- ^ Craig Partridge (enero de 1986). ENRUTAMIENTO DE CORREO Y SISTEMA DE DOMINIO . IETF . doi : 10.17487 / RFC0974 . RFC 974 . Consultado el 18 de noviembre de 2011 .
Para cada MX, se debe emitir una consulta WKS para ver si el nombre de dominio enumerado realmente admite el servicio de correo deseado. Los RR de MX que enumeran nombres de dominio que no admiten el servicio deben descartarse. Este paso es opcional, pero se recomienda encarecidamente.
- ^ Esta sección es una adaptación de John Levine mensaje IETF-SMTP Archivado 2008-06-01 en la Wayback Machine