Hispanopedia WikiUn registro de intercambio de correo ( registro MX ) especifica el servidor de correo responsable de aceptar mensajes de correo electrónico en nombre de un dominio. Es un registro de recursos del Sistema de Nombres de Dominio (DNS). Es posible configurar varios registros MX, que generalmente apuntan a un conjunto de servidores de correo para equilibrar la carga y garantizar 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 ellos, y un dominio puede tener uno o más de estos configurados, como se muestra a continuación:
Dominio TTL Clase Tipo Prioridad Host example.com. 1936 IN MX 10 onemail.example.com. example.com. 1936 IN MX 10 twomail.example.com.La información característica de la carga útil de un registro MX [ 1 ] es un valor de preferencia (etiquetado arriba como "Prioridad") y el nombre de dominio de un servidor de correo ("Host" arriba).
El campo de prioridad identifica qué servidor de correo debe tener preferencia; en este caso, ambos valores son 10, por lo que se espera que el correo fluya de manera uniforme tanto a onemail.example.com como a twomail.example.com , una configuración común. El nombre de host debe corresponder directamente a 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 el Sistema de nombres de dominio (DNS) para obtener los registros MX del nombre de dominio de cada destinatario . Esta consulta devuelve una lista de nombres de host de los servidores de intercambio de correo que aceptan correo entrante para ese dominio y sus preferencias. A continuación, el agente remitente intenta establecer una conexión SMTP, probando primero con el host con el valor de "Prioridad" más bajo. El sistema permite crear clústeres de alta disponibilidad de pasarelas de correo 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 tampoco proporciona la capacidad de distribuir la entrega de correo entre 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 la RFC 5321, los registros con el número más bajo son los preferidos. [ 4 ] Esta formulación puede resultar confusa, por lo que a veces se hace referencia al número de preferencia como la distancia : las distancias más pequeñas son más preferibles. Una RFC anterior, la RFC 974, indica que cuando los números de preferencia son iguales para dos servidores, tienen la misma prioridad ; por lo tanto, ambos términos se utilizan indistintamente.
El número de preferencia es un campo sin signo [ 5 ] de 16 bits [ 5 ] [ 6 ] , por lo que los valores válidos van de 0 a 65535.
Lo básico
En el caso más sencillo, un dominio puede tener un único servidor de correo. Por ejemplo, si un MTA consulta los registros MX de example.com y el servidor DNS responde únicamente con mail.example.com con un número de preferencia de 50, el MTA intentará entregar el correo al servidor indicado. En este caso, el número 50 podría ser cualquier entero permitido por la especificación SMTP.
Cuando se devuelve más de un servidor para una consulta MX, se debe intentar primero con el servidor con el número de preferencia más bajo. Si hay más de un registro MX con el mismo número de preferencia, se deben intentar todos ellos antes de pasar a las entradas de menor prioridad. Un cliente SMTP debe poder intentar (y reintentar) cada una de las direcciones relevantes de la lista en orden, hasta que se logre una entrega exitosa. [ 4 ]
Distribución de carga
El método estándar para distribuir una carga de correo entrante entre varios servidores consiste en devolver el mismo número de preferencia para cada servidor del conjunto. Al determinar a qué servidor de igual preferencia enviar el correo, "el servidor SMTP del remitente DEBE asignarlos aleatoriamente para distribuir la carga entre varios servidores de correo para una organización específica", a menos que exista una razón clara para favorecer a uno en particular. [ 4 ]
Un enfoque alternativo consiste en utilizar servidores multihomed , donde un único host devuelve varias direcciones IP. [ 3 ] Este método traslada la responsabilidad del balanceo de carga al servidor DNS en lugar del remitente SMTP, que en este caso presentará una lista de direcciones IP en un orden específico a los clientes que consultan el registro A del servidor de correo. Dado que la RFC exige que el remitente SMTP utilice el orden especificado en la consulta del registro A, el servidor DNS puede manipular cuidadosamente su balanceo basándose en cualquier método, incluyendo DNS round robin , carga del servidor de correo o algún esquema de prioridad no revelado.
Spammers
Los remitentes de spam pueden dirigir deliberadamente los correos electrónicos primero a uno de los servidores MX de respaldo (de alta distancia) de un dominio, bajo la suposición de que dicho servidor tendrá filtros antispam menos efectivos. Una técnica antispam llamada " nolisting" se basa en asumir este comportamiento.
Gestión de fallos en la entrega
El RFC SMTP [ 4 ] es ambiguo sobre qué tipos de fallos de entrega deben dar lugar a 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 finalizando la conexión inesperadamente (lo cual debe tratarse como un error 451, según la Sección 3.8 de la RFC), la Sección 4.5.4.1 dice:
El remitente DEBE retrasar el reintento de envío a un destino determinado después de que un intento haya fallado.
Sin embargo, cuando el remitente vuelve a intentarlo, la RFC no especifica si esto debe hacerse al mismo servidor o a un registro MX más "distante". En la Sección 5.1 sí dice :
Cuando la búsqueda se realiza correctamente, la asignación puede generar una lista de direcciones de entrega alternativas en lugar de una sola, debido a la presencia de múltiples registros MX, la configuración de múltiples direcciones IP o ambas. Para garantizar una transmisión de correo confiable, el cliente SMTP DEBE poder intentar (y volver a intentar) cada una de las direcciones relevantes de esta lista en orden, hasta que se logre una entrega exitosa.
Algunos servidores (como Sendmail y Postfix 2.1 o posterior) [ 7 ] intentarán contactar con el siguiente servidor MX más lejano tras ciertos tipos de fallos de entrega temporales, como fallos de saludo. [ 8 ] Otros servidores (como qmail y Postfix 2.0 o anterior) solo utilizarán registros MX más distantes si no se pudo contactar con los servidores especificados en los registros MX de menor distancia. A pesar de la diferencia, ambos comportamientos son válidos, ya que la RFC no es específica.
Recurrir al registro de direcciones
En ausencia de un registro MX, los remitentes de correo electrónico intentarán entregar el mensaje a la dirección registrada, por ejemplo, example.com.
Esto se basa en la RFC 5321, sección 5.1, que establece :
- Los clientes SMTP deben consultar 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 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
El RFC 821 se publicó en 1982. Solo hace referencias superficiales al DNS, ya que en ese momento la transición de HOSTS.TXT al DNS aún no había comenzado. El RFC 883, la primera descripción del DNS, se publicó más de un año después, a finales de 1983. En él se describían los registros MD y MF, que eran experimentales y poco utilizados. Según los RFC 897 y 921, la transición al DNS comenzó en 1983, pero la eliminación gradual de HOSTS.TXT no estaba prevista hasta finales de 1985 y no se eliminó por completo hasta finales de la década de 1990.
En enero de 1986, los RFC 973 y 974 declararon obsoletos los registros MD y MF, los reemplazaron por MX y definieron la búsqueda MX con una alternativa a A. El RFC 974 recomienda que los clientes realicen una búsqueda WKS [ 9 ] en cada host MX para comprobar si admite SMTP y, de no ser así, descarten la entrada MX. Sin embargo, el RFC 1123 modificó esto, estableciendo que no se debe comprobar WKS.
Esto significa que SMTP llevaba al menos un año en uso con HOSTS.TXT, y luego un par de años más con A, MD y MF, antes de la llegada de MX. MD y MF eran difíciles de usar, por lo que la mayoría de la gente simplemente usaba el registro A. En esas circunstancias, MX sin la opción de usar A como alternativa no habría funcionado debido a la considerable base instalada de servidores de correo que utilizaban registros A. El uso inicial de MX era 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. [ 10 ]
Documentos de normas
- RFC 1035 (1987), Nombres de dominio: implementación y especificación
- RFC 1912 (1996), Errores comunes de operación y configuración de DNS
- RFC 5321 (2008), Protocolo simple de transferencia de correo
- RFC 7505 (2015), Un registro MX nulo sin servicio para dominios que no aceptan correo
Obsoleto:
- RFC 974 (1986), Enrutamiento de correo y el sistema de dominios (obsoleto por RFC-5321)
- RFC 2821 (2001), Protocolo simple de transferencia de correo (obsoleto por RFC-5321 )
Véase también
Referencias
- ↑ En estos ejemplos, el nombre de dominio en cuestión se encuentra 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 autoritativo .
- ↑ RFC 2181, Sección 10.3, Aclaraciones a la especificación DNS , R. Elz, R. Bush (julio de 1997)
- 1 2 CÓMO - Configurar Round Robin y balanceo de carga , Página modificada: 28 de febrero de 2014, zytrax.com
- 1 2 3 4 RFC 5321
- 1 2 RFC 974
- ↑ RFC 1035 sección 3.3.9
- ↑ Si el MX principal responde, pero falla a mitad de la transacción, Postfix 1.2 y 2.0 no intentarán usar un MX de respaldo. Archivado el 23/06/2009 en Wayback Machine , Re: no cambia a mx con menor prioridad, De: Victor Duchovni (Victor.DuchovniMorganStanley.com) Fecha: Vie 11 Nov 2005
- ↑ Un error de saludo es un código de error que se envía en lugar del saludo estándar SMTP o en respuesta a él.
- ↑ Craig Partridge (enero de 1986). ENRUTAMIENTO DE CORREO Y EL SISTEMA DE DOMINIOS . IETF . doi : 10.17487/RFC0974 . RFC 974. Consultado el 18 de noviembre de 2011.
Para cada MX, se debe realizar una consulta WKS para comprobar si el nombre de dominio indicado admite el servicio de correo deseado. Los registros MX que incluyan nombres de dominio que no admitan el servicio deben descartarse. Este paso es opcional, pero se recomienda encarecidamente.
- ↑ Esta sección está adaptada del mensaje ietf-smtp de John Levine, archivado el 1 de junio de 2008 en Wayback Machine.
- Tipos de registros DNS
- Correo electrónico