Network Working Group Craig Partridge Request for Comments: 974 CSNET CIC BBN Laboratories Inc Enero 1986 ENCAMINAMIENTO DE CORREO Y EL SISTEMA DE DOMINIOS (Traducción al castellano: Febrero de 2000) (Por Domingo Sánchez Ruiz ) Status de este memorándum Este RFC presenta una descripción de cómo los sistemas de correo de Internet deben encaminar mensajes basándose en la información aportada por el sistema de dominios descrito en los RFCs 882, 883 y 973. La distribución de este memorándum tiene carácter ilimitado. Introducción Es el propósito de este memorándum explicar cómo los programas gestores de correo tienen que decidir cómo encaminar un mensaje dirigido a un nombre de dominio de Internet dado. Esto implica una discusión de cómo los gestores de correo interpretan los RRs de tipo MX, que se utilizan para encaminamiento de mensajes. Nótese que este memorándum no dice nada acerca de cómo los gestores de correo tienen que tratar con los RRs de tipo MB y MG, que se utilizan para interpretar los nombres de los buzones de correo. Con el advenimiento de RFC-882 y RFC-883, ciertas presuposiciones acerca de las direcciones de correo han cambiado. Hasta ahora, normalmente, uno podía asumir que si su mensaje estaba dirigido a un buzón de correo, por ejemplo, a LOKI.BBN.COM, bastaba con abrir una conexión SMTP a LOKI.BBN.COM y pasarle el mensaje. Este sistema fallaba en ciertas situaciones, como el caso de "hosts" UUCP y CSNET que no estuvieran directamente conectados a Internet, pero estos casos podían ser tratados como casos especiales en archivos de configuración (por ejemplo, la mayoría de los gestores de correo se configuraban para que reenviaran el correo dirigido a un host CSNET de forma automática a CSNET-RELAY.ARPA). Con los dominios, uno no puede simplemente abrir una conexión a LOKI.BBN.COM, sino que en su lugar tiene que preguntar al sistema de dominios dónde deben entregarse los mensajes dirigidos a LOKI.BBN.COM. Y el sistema de dominios puede redirigir un gestor de correo a un "host" enteramente diferente, como SH.CS.NET. O, en un caso más complicado, el gestor de correo puede aprender del sistema de dominios que dispone de una variedad de rutas hacia LOKI.BBN.COM. Este memorándum consiste básicamente en un conjunto de guías sobre Partridge [Pág. 1] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 cómo los gestores de correo deberían comportarse en este mundo más complejo. Se espera que los lectores estén familiarizados con los RFCs 882, 883 y sus actualizaciones (e.g., RFC-973). Lo que los Servidores de Dominio Saben. Los servidores de dominio guardan la información en series de registros de recursos (RR: resource records), cada uno de los cuáles contiene información particular acerca de un nombre de dominio dado (que es habitualmente, pero no siempre, un "host"). La forma más simple de entender un RR es como un par estructurado de datos, un nombre de dominio asociado con datos relevantes, guardado junto con alguna información de tipo adicional para ayudar a los sistemas a determinar cuando el RR es relevante. Para los propósitos de encaminamiento de mensajes, el sistema dispone de un tipo de RRs conocido como MX (Mail Exchanger - Intercambiador de Correo). Cada MX asocia un nombre de dominio con dos datos, un número de preferencia ( un entero de 16 bits sin signo) y el nombre de un "host". El número de preferencia se utiliza para indicar en qué orden el gestor de correo debería intentar entregar correo a los "hosts" MX, siendo el MX con un número de preferencia menor el que se intentaría primero. Se permiten varios MXs con el mismo número de preferencia, teniendo entonces éstos la misma prioridad. Además de la información de correo, los servidores guardan otros tipos de RRs que los gestores de correo pueden encontrar y elegir usar. Estos son: el RR nombre canónico (CNAME), que simplemente establece que el nombre de dominio solicitado es realmente un alias de otro nombre de dominio, el nombre auténtico, o canónico; y el RR Well Known Service (WKS, Servicios Públicos), que guarda la información acerca de qué servicios de red (como SMTP) soporta un nombre de dominio dado. Guías Generales para el Encaminamiento Antes de entrar en una discusión detallada de cómo se espera que los gestores de correo encaminen el correo, parece razonable ofrecer un breve resumen de cómo este memorándum afronta los problemas que el encaminamiento plantea. El primer y más importante principio se deriva de la misma definición del campo de preferencia de los registros MX, estando pensado para evitar bucles en la ruta del correo. Si el gestor de correo está en un "host" que aparece como un MX para el "host" de destino, el gestor de correo sólo puede enviar correo a un MX que tenga un valor del Partridge [Pág. 2] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 número de preferencia más bajo que el del propio "host". También es posible causar bucles porque la información de encaminamiento no esté actualizada o completa. La información desactualizada constituye un problema únicamente cuando se cambian las tablas de dominios. Los cambios no quedarán reflejados en los "hosts" afectados hasta que expiren los plazos de los cachés de sus sistemas de resolución de nombres. No hay forma de asegurar que esto no suceda a menos que los gestores de correo solicitantes y sus sistemas de resolución de nombres siempra envíen sus consultas a un servidor de confianza ("authoritative") y nunca utilizen los datos guardados en un caché. Esto no constituye una solución práctica, ya que eliminar el caché del sistema de resolución haría desmesuradamente lento el servicio de correo. Más aún, el problema de tener RRs desactualizados no debería ocurrir si, cuando una tabla de dominio se cambia, los "hosts" afectados (aquellos en la lista de MXs) limpian el caché de sus sistemas de resolución de nombres. En otras palabras, tomando las adecuadas precauciones, la aparición de bucles como consecuencia de informaciones del dominio debería ser evitable, sin tener que exigir a los gestores de correo que pregunten a los servidores de confianza. (La precaución adecuada consiste en consultar al administrador del "host" antes de añadir dicho "host" a la lista de MXs). El problema de datos incompletos también requiere un cierto cuidado cuando se manejan consultas al sistema de dominios. Si la sección de respuesta de una consulta es incompleta, puede que hayan sido omitidos RRs críticos de tipo MX. Esto puede causar la aparición de bucles, o que un mensaje sea etiquetado erróneamente como imposible de enviar ("undeliverable"). Por tanto, los gestores de correo deberían aceptar únicamente contestaciones del sistema de dominio que lleven completas sus secciones de respuesta. Nótese que este problema puede ser evitado en su totalidad utilizando circuitos virtuales para las consultas, pero como esta situación se va a dar en muy raras ocasiones y los datagramas constituyen la forma preferida de interacción con el sistema de dominios, los implementadores deberían restringirse a asegurar que su gestor de correo repetirá una consulta a un circuito virtual cada vez que el bit de truncamiento esté establecido. Determinando Dónde Enviar un Mensaje La explicación de cómo los gestores de correo deberían decidir cómo encaminar un mensaje se discutirá en términos del problema de un gestor de correo en un "host" con nombre de dominio LOCAL intentando enviar un mensaje dirigido a un nombre de dominio REMOTO. Ambos, LOCAL y REMOTO, se les supone que son nombres sintácticamente correctos de dominios. Más aún, a LOCAL se le supone que es el nombre Partridge [Pág. 3] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 oficial de un host en el que el gestor de correo reside (i.e., no es un alias). Realizando una Consulta El primer paso para el gestor de correo de LOCAL consiste en realizar una consulta de RRs de tipo MX a REMOTO. Se recomienda fervientemente que se tome este paso cada vez que un gestor de correo intente enviar un mensaje. La esperanza radica en que los cambios en la base de datos de dominios llegarán así a ser rapidamente utilizados por los gestores de correo, y los administradores de dominios serán capaces de re-encaminar los mensajes en tránsito para los "hosts" defectuosos, simplemente cambiando sus bases de datos de dominios. Algunas respuestas a la consulta que se consideran errores: No obtener ninguna contestación a la petición. El servidor de dominio al que el gestor de correo hizo la consulta no devuelve nada. (Esto es distinto de una contestación que no contenga respuestas a la consulta, lo que no es un error). Obtener una respuesta en la que el campo de truncamiento de la cabecera esté establecido. (Recordar la discusión previa sobre consultas incompletas). Los gestores de correo no deberían utilizar respuestas de este tipo, y sí repetir la consulta utilizando circuitos virtuales en lugar de datagramas. Obtener una respuesta en la que el código de respuesta es distinto de cero. Se espera que los gestores de correo hagan algo razonable ante un error. El comportamiento ante cada tipo de error no se especifa aquí, pero los implementadores deberían notar que diferentes tipos de errores deberían posiblemente ser tratados de manera distinta. Por ejemplo, un código de respuesta de "dominio no existente" debería posiblemente causar que el mensaje de correo fuera devuelto al emisor figurando como no válido, mientras que un código de respueta de "fallo del servidor" probablemente debería causar que se reintentara el envío del mensaje más tarde. Hay otro caso especial. Si la contestación contiene una respuesta que es un RR de tipo CNAME, esto indica que REMOTO es realmente un alias para otro nombre de dominio. La consulta debería entonces repetirse con el nombre de dominio canónico. Si la contestación no contiene una respuesta de error, y no contiene alias, entonces la sección de respuesta debería ser una lista de RRs Partridge [Pág. 4] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 de tipo MX (posiblemente de longitud cero) para el nombre de dominio REMOTO (o para el verdadero nombre de dominio de REMOTO si REMOTO era un alias). La próxima sección describe como se interpreta esta lista. Interpretando la Lista de RRs de tipo MX. NOTA: Esta sección sólo discute cómo los gestores de correo eligen a qué nombres deben intentar enviar un mensaje, obteniéndolos de una lista de RRs. No discute cómo los gestores de correo realmente realizan la entrega. Siempre que se hable de entregar un mensaje, quiere decirse que el gestor de correo debe hacer todo lo que necesite para transferir el mensaje a un sitio remoto, dado el nombre de dominio de ese sitio. (Por ejemplo, un gestor de correo de tipo SMTP intentará averiguar la dirección para ese nombre de dominio, lo que implicará otra consulta al sistema de dominios, y entonces, si consigue la dirección, se conectará por TCP al puerto SMTP). El mecanismo de la transferencia real del mensaje sobre la red hasta la dirección asociada con un nombre de dominio dado no entra dentro de la competencia de este memorándum. Es posible que la lista de MXs en la contestación a la consulta esté vacía. Esto constituye un caso especial. Si la lista está vacía, los gestores de correo tratan este caso como si contuviera un único RR: un RR de tipo MX com un valor de preferencia 0 y como nombre de "host" REMOTO. (I.e., REMOTO es su único MX). Además, el gestor de correo no debería realizar más procesamiento de la lista, sino que debería intentar entregar el mensaje a REMOTO. La idea aquí es que si un dominio falla en comunicar cualquier información acerca de un nombre particular, se le concede el beneficio de la duda y se intenta la entrega. Si la lista no está vacía, el gestor de correo debería eliminarlos RRs irrelevantes de la lista de acuerdo a los siguientes pasos. Nótese que el orden es importante. Para cada MX, se debería realizar una consulta WKS para averiguar si el nombre de dominio devuelto en la lista soporta el servicio de correo deseado. Los RRs de tipo MX que contengan nombres de dominio que no soportan el servicio deberían ser descartados. Este paso es opcional, pero se recomienda fervientemente. Si el nombre de dominio LOCAL aparece lcomo un RR de tipo MX, todos los RRs de tipo MX con un número de preferencia mayor o igual que el del LOCAL deben ser descartados. Después de eliminar los RRs irrelevantes, la lista puede que, de nuevo, esté vacía. Esto se considera una condición de error y puede ocurrir de varias formas. El caso más simple consiste en que las Partridge [Pág. 5] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 consultas WKS hayan descubierto que ninguno de los "hosts" de la lista soportan el servicio deseado. El mensaje entonces queda considerado como imposible de ennviar, aunque los gestores de correo extremadamente persistentes puede que quieran intentar un envío a la dirección de REMOTO (si existe) antes de devolver el mensaje. Otra posibilidad, más peligrosa, consiste en que el sistema de dominio crea que LOCAL está gestionando el mensaje para REMOTO, pero el gestor de correo en LOCAL no esté configurado para gestionar correo para REMOTO. Por ejemplo, si el sistema de dominio lista LOCAL como el único MX para REMOTO, LOCAL borrará todas las entradas de la lista. Pero LOCAL, presumiblemente, está preguntando al sistema de dominio porque no sabe qué hacer con un mensaje dirigido a REMOTO. Claramente algo está mal. Cómo un gestor se apaña para manejar estas situaciones es algo, hasta cierto punto, dependiente de la implementación, y, por tanto, se deja al criterio del implementador. Si la lista de RRs de tipo MX no está vacía, el gestor de correo debería intentar enviar el mensaje a los MXs por orden (intentando primero los de número de preferencia menor). Se le requiere al menos al gestor de correo que intente el envío al MX con valor más bajo. Se recomienda a los implementadores que desarrollen gestores de correo que intenten enviar a los MXs en orden hasta que uno de los MXs acepte el mensaje, o hasta que se haya probado con todos los MXs. Un sistema menos exigente, en que se intenta un número fijo de MXs, también es razonable. Nótese que puede que varios MXs tengan el mismo número de preferencia. En este caso, se debe probar antes con todos los MXs de un determinado que con cualquiera de un valor más alto. Además, en el caso especial en el que hay varios MXs con el valor de preferencia más bajo, se debería probar con todos ellos antes de que el mensaje se juzgue como imposible de envíar. Cuestiones Especiales Menores En la sección anterior no se trató un par de cuestiones especiales porque hubieran complicado la discusión. Serán tratadas aquí sin ningún orden en particular. Los nombres comodín, aquellos que contienen el carácter '*', pueden ser utilizados para el encaminamiento de correo electrónico. Es muy probable que haya servidores en la red que establezcan simplemente que cualquier correo dirigido a un dominio sea encaminado hacia un repetidor ("relay"). Por ejemplo, en el momento de escribir este RFC, todos los correos para los "hosts" en el dominio IL son encaminados hacia RELAY.CS.NET. Esto se hace creando un RR comodín, que declare que *.IL tiene como MX a RELAY.CS.NET. Esto debería ser transparente para el gestor de correo ya que los servidores de dominio ocultarán las concordancias con los comodines. (Si un servidor de dominio asocia *.IL con HUJI.IL, por ejemplo, entonces el servidor devolverá Partridge [Pág. 6] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 un RR conteniendo HUJI.IL, no *.IL). Si por algún accidente un gestor de correo recibe un RR con un nombre de dominio comodín en su sección de datos o nombres, debería descartar el RR. Nótese que el algoritmo para eliminar RRs irrelevantes falla si LOCAL tiene un alias y el alias aparece dentro de los registros de tipo MX para REMOTO. (E.g. REMOTO tiene como un MX a ALIAS, y ALIAS tiene un CNAME de LOCAL). Esto puede evitarse si no se emplean nunca alias en la sección de datos de los RRs de tipo MX. Los implementadores deberían entender que la consulta y su interpretación se realiza únicamente para REMOTO. No se repite para los RRs de tipo MX listados para REMOTO. No se puede pretender soportar encaminamientos de correo más extravagantes construyendo una cadena de MXs. (E.g. UNIX.BBN.COM es un MX para RELAY.CS.NET y RELAY.CS.NET es un MX para todos los hosts en .IL, pero esto no significa que UNIX.BBN.COM acepte cualquier responsabilidad sobre el correo para .IL). Por último, debería notarse que esto es un estándar para encaminamiento en Internet. Los gestores de correo que sirvan a "hosts" pertenecientes a múltiples redes tendrán, presumiblemente, que tomar algunas decisiones acerda de por cuál red encaminan el correo. La manera de tomar estas decisiones está fuera del ámbito de este memorándum, aunque los gestores de correos muy bien pueden utilizar el sistema de dominios como ayuda en sus decisiones. Sin embargo, una vez que un gestor de correo decide enviar un mensaje vía Internet, tiene que aplicar estar reglas para encaminar el mensajer. Ejemplos Para ilustrar la discusión de más arriba, se presentan aquí tres ejemplos de cómo los gestores de correo deberían encaminar los mensajes. Todos los ejemplos manejan la siguiente base de datos: A.EJEMPLO.ORG IN MX 10 A.EJEMPLO.ORG A.EJEMPLO.ORG IN MX 15 B.EJEMPLO.ORG A.EJEMPLO.ORG IN MX 20 C.EJEMPLO.ORG A.EJEMPLO.ORG IN WKS 10.0.0.1 TCP SMTP B.EJEMPLO.ORG IN MX 0 B.EJEMPLO.ORG B.EJEMPLO.ORG IN MX 10 C.EJEMPLO.ORG B.EJEMPLO.ORG IN WKS 10.0.0.2 TCP SMTP C.EJEMPLO.ORG IN MX 0 C.EJEMPLO.ORG C.EJEMPLO.ORG IN WKS 10.0.0.3 TCP SMTP D.EJEMPLO.ORG IN MX 0 D.EJEMPLO.ORG Partridge [Pág. 7] RFC 974 Encaminamiento de Correo y el Sistema de Dominios Enero 1986 D.EJEMPLO.ORG IN MX 0 C.EJEMPLO.ORG D.EJEMPLO.ORG IN WKS 10.0.0.4 TCP SMTP En el primer ejemplo, un gestor de correo SMTP en D.EJEMPLO.ORG está intentando enviar un mensaje dirigido a A.EJEMPLO.ORG. De la respuesta a su consulta, el gestor aprende que A.EJEMPLO.ORG tiene tres RRs de tipo MX. D.EJEMPLO.ORG no es ninguno de los tres RRs de tipo MX y los tres soportan correo SMTP (hecho determinado a partir de las entradas WKS), por tanto, no se elimina ninguno de los MXs. El gestor de correo está obligado a intentar enviar el correo a A.EJEMPLO.ORG ya que es el MX de menor valor. Si no tiene acceso a A.EJEMPLO.ORG, puede (pero no está obligado a proceder así) probar con B.EJEMPLO.ORG y si B.EJEMPLO.ORG no responde, puede probar con C.EJEMPLO.ORG. En el segundo ejemplo, el gestor de correo está en B.EJEMPLO.ORG, y, nuevamente, está intentado enviar un mensaje dirigido a A.EJEMPLO.ORG. De nuevo hay tres RRs de tipo MX para A.EJEMPLO.ORG, pero en este caso el gestor de correo debe descartar los RRs cuyo MX sea él mismo o C.EJEMPLO.ORG (porque el RR de tipo MX con C.EJEMPLO.ORG tiene un número de preferencia mayor que el del RR con B.EJEMPLO.ORG). Sólo queda el RR con A.EJEMPLO.ORG, y, por tanto, sólo puede intentar la entrega a A.EJEMPLO.ORG. En el tercer ejemplo, se considera un gestor de correo en A.EJEMPLO.ORG que está intentando entregar un mensaje a D.EJEMPLO.ORG. En este caso sólo hay dos RRs de tipo MX, ambos con el mismo número de preferencia. Cualquiera de estos MXs aceptará los mensajes para D.EJEMPLO.ORG. El gestor de correo debería intentar un MX primero (cuál de ellos es elección del gestor, aunque D.EJEMPLO.ORG parece el más razonable), y si la entrega falla debería probar con el otro MX (e.g. C.EJEMPLO.ORG). N.T.: RFCs en castellano: http://www.arrakis.es/~pjleon/rfc-es http://lucas.hispalinux.es/htmls/estandares.html Lista RFC-ES: http://www.rediris.es/list/info/rfc-es.html Partridge [Pág. 8]