17.4. ¿Cómo funciona el encaminamiento del correo?

17.4.1. Encaminamiento en Internet

La configuración del sistema anfitrión del destinatario determina si se está trabajando con un determinado sistema de localización de la ruta de correo en Internet. La opción predeterminada es transmitir el mensaje a su destino determinando primero el anfitrión al que debe ser enviado, y mandándolo allí directamente. La mayoría de los sitios de Internet buscan dirigir todo el correo entrante a un servidor de correo con alta disponibilidad capaz de manejar todo el tráfico y distribuirlo localmente. Para dar a conocer este servicio, el sitio publica el llamado registro MX para su dominio local en su base de datos DNS. MX (Mail Exchanger) significa Intercambiador de Correo y básicamente indica que el anfitrión del servidor es capaz de convertirse en emisor de correo para todas las direcciones del dominio. Los registros MX también pueden manejar el tráfico de anfitriones que no están conectados a la red, como UCCP o FidoNet, que necesitan una pasarela de correo.

Los registros MX siempre tienen siempre asignada una preferencia Esto es positivo. Si son muchos los proveedores de correo existentes (MX) para un anfitrión, el agente de transporte de correo tratará de enviar el mensaje al proveedor cuya preferencia sea la menor. Sólo si esta operación falla, lo enviará a un anfitrión de mayor índice de preferencia. Si el anfitrión local es el proveedor de correo para la dirección de destino, puede enviar los mensajes a un anfitrión menos preferente que él mismo; ésta es una manera segura de evitar los bucles en el correo. Si no hay ningún registro MX para un determinado dominio, o no es disponible, el agente de transporte de correo puede comprobar si la dirección IP del dominio está asociada a él, y así intentar mandarlo directamente a ese anfitrión.

Supongamos que hay una organización dada, por ejemplo Foobar, Inc., que quiere que todo su correo lo controle el servidor de correode su ordenador. Por ello llevará registros MX como el que se muestra a continuación, en la base de datos DNS:

green.foobar.com. IN MX 5 mailhub.foobar.com.

Esto da a conocer a mailhub.foobar.com como proveedor de correo para green.foobar.comcon un nivel de preferencia de 5. Un anfitrión que pretenda enviar un mensaje a joe@green.foobar.com revisa la base de datos DNS y busca el MX en el distribuidor de correo . Si no hay ningún MX con una preferencia menor a 5, el mensaje se envía al distribuidor de correo, que lo entrega a green.

Ésta es una descripción muy básica de cómo funcionan los registros MX. Para obtener más información sobre el encaminamiento de correo en Internet, consulte RFC-821, RFC-974 y RFC-1123.

17.4.2. Encaminamiento en el entorno UUCP

El encaminamiento del correo en las redes UUCP es mucho más complicado que en Internet porque sus programas no realizan el encaminamiento ellos mismos. Antes, todo el correo debía ser dirigido mediante las rutas bang path. Éstas especificaban una lista de sistemas anfitriones separados por signos de exclamación y seguidos por el nombre del usuario, por los que el correo debía pasar. Por ejemplo, para escribir a un usuario llamado Janet que se encuentra en un ordenador llamado moria, usuaríamos la ruta eek!swim!moria!janet.De esta manera el mensaje se enviaría desde su sistema anfitrión a eek,desde aquí a swim, y por último lugar a moria.

El inconveniente obvio de este sistema es que es necesario que el usuario recuerde muchos más datos sobre topología de red que la que Internet requiere. Y mucho peor son los cambios de la topología como los enlaces eliminados o anfitriones que desaparecen —— que produce fallos en los mensajes al no ser el usuario consciente de estos cambios. Y por último, si usted cambia de sitio o se traslada, probablemente deberá actualizar estas rutas.

Una razón por la que el encaminamiento desde la fuente se hizo necesario fue la presencia de nombres de anfitrión ambiguos. Por ejemplo, imaginemos que hay dos sitios llamados moria, uno en los Estados Unidos y otro en Francia. ¿A cuál de los dos se referiría moria!janet ahora? El problema quedaría solucionado especificando una ruta concreta para acceder a moria

El primer paso para evitar la ambigüedad con los nombres de anfitrión fue el proyecto de mapeado UUCP. Se encuentra en la Universidad de Rutgers y registra de manera oficial todos los nombres de anfitrión, junto con información sobre otros sistemas UUCP y su situación geográfica, procurando que no se repita ninguno. Esta información en manos del proyecto de mapeado UUCP, se publica bajo el nombre Mapas Usenet , y son distribuidos regularmente a través de Usenet. El formato típico de entrada a un mapa (eliminados ya los comentarios) es de la siguiente manera:[1]

moria bert(DAILY/2), swim(WEEKLY)

Esta entrada indica que moria está vinculado a bert, al cual llama dos veces al día, y a swim, al cual llama semanalmente. Explicaremos con más detalle lo referente al formato de fichero de mapas.

Con la información sobre la conectividad que obtenemos de los mapas, podemos generar la totalidad de rutas existentes entre su sistema anfitrión y cualquier sitio. Esta información se encuentra en el fichero de rutas, también conocido como base ruta-alias. Supongamos que los mapas indican que usted puede ponerse en contacto con bert a través deernie; una entrada en forma de alias de ruta para moria generado del retazo del mapa anterior podría ser de la siguiente manera:

moria ernie!bert!moria!%s

Si usted propone la dirección janet@moria.uucp, el MTA seguirá la ruta anterior y enviará el mensaje a, ernie con la direcciónbert!moria!janet.

No obstante, crear un fichero de rutas a partir de los mapas Usenet no es buena idea. La información que contienen suele estar distorsionada, y también es posible que no esté actualizada. Es por ello que sólo un determinado número de anfitriones utilizan los mapas UUCP completos para crear sus ficheros de rutas. Muchos sitios mantienen la información de ruta sólo para sitios que se encuentran en su entorno, y envían cualquier mensaje a los sitios que no están presentes en su base de datos a anfitriones más inteligentes con información de ruta más completa. Este esquema se llama encaminamiento por anfitrión inteligente. Los anfitriones que tienen sólo un vínculo de correo UUCP (los llamados leaf sites), no pueden realizar el encaminamiento por su cuenta, deben dejar esa labor a un anfitrión inteligente.

17.4.3. Mezclar UUCP y RFC-822

La mejor manera de evitar los problemas referentes al encaminamiento del correo en las redes UUCP es adoptar el sistema de nombre de dominio de dichas redes. Por supuesto, usted no puede cuestionar un servidor de nombres de UUCP. Sin embargo, muchos sitios UUCP han creado pequeños dominios que coordinan su encaminamiento internamente. En los mapas, estos dominios anuncian uno o dos anfitriones en forma de pasarela de correo propio de tal forma que no tiene que existir un indicador de entrada al mapa para cada anfitrión en el dominio. Las pasarelas de correo controlan tanto el fluido de correo interno como externo al dominio. El plan de encaminamiento dentro del dominio es independiente e invisible para el mundo exterior.

Esto funciona muy bien en el esquema de encaminamiento por anfitrión inteligente. El encaminamiento global de la información sólo lo mantienen los portales; los anfitriones menores dentro de un dominio pueden trabajar únicamente con ficheros de rutas pequeños, escritos a mano que indiquen las rutas de ese dominio y el camino hacia el encaminador. Incluso las pasarelas de correo ya no necesitan la información de ruta para cada anfitrión UUCP del mundo. Aparte de la información de ruta, ahora tan sólo necesitan conocer rutas hacia dominios absolutos. Por ejemplo, esta entrada ruta-alias conducirá todo el correo hacia los sitios en el dominio sub.org hacia smurf:

.sub.org swim!smurf!%s

Todo el correo enviado a claire@jones.sub.org será enviado a swim con la dirección smurf!jones!claire.

La organización jerárquica del nombre de dominio permite a los servidores de correo mezclar rutas más y menos específicas. Por ejemplo, un sistema francés puede tener rutas específicas para los subdominios en ofr, y encaminar el correo hacia los anfitriones en el dominio, us en algún sistema de los Estados Unidos. De esta manera, gracias al encaminamiento basado en el dominio (nombre que recibe esta técnica) tanto el tamaño de las bases de datos de encaminamiento como las necesidades administrativas, se ven reducidos.

La ventaja principal al usar nombres de dominio en un entorno UUCP es que las normas de conformidad con RFC-822 permiten el contacto entre las redes UUCP en Internet. Actualmente, muchos dominios UUCP tienen vínculos con pasarelas de Internet que actúan como anfitrión. Es más rápida y más fiable la información de encaminamiento si mandamos los mensajes por Internet, ya que éstos anfitriones pueden funcionar con DNS en lugar de Mapas Usenet.

Con el fin de se ser localizados desde Internet, los dominios basados en UUCP muestran un registro MX (los registros MX se comentaron en la sección“Sección 17.4.1”). Por ejemplo, supongamos que moria pertenece al dominio orcnet.org gcc2.groucho.edu actúa como su pasarela a Internet. Entonces moria utilizaría gcc2 como anfitrión, para que toda la correspondencia dirigida a dominios extranjeros se distribuyese a través de Internet. Por otro lado, gcc2 mostraría un registro MX para *.orcnet.org y llevaría todo el correo entrante para los sitios orcnet a moria. El asterisco en *.orcnet.org es un comodín que empareja todos los anfitriones de ese dominio que no están relacionados con ningún registro. Esto ocurre con frecuencia sólo con los dominios UUCP.

El único problema que queda es que los programas de transmisión UUCP no pueden funcionar con nombres de dominio ilimitados. Muchos sitios UUCP fueron diseñados para trabajar con nombres de hasta ocho caracteres, o incluso menos, y sin utilizar caracteres alfanuméricos como el punto.

Por lo tanto, habría que hacer un mapeado entre los nombres RFC-822 y los nombres de anfitrión UUCP. El mapeado depende totalmente de su puesta en práctica. Una manera común de mapear los nombres FQDN y los UUCP, es usar el fichero del alias de ruta:

moria.orcnet.org ernie!bert!moria!%s

Esto producirá un bang path al estilo UUCP desde una dirección que especifique un nombre de dominio completamente cualificado. algunos agentesd de transporte proporcionan un fichero especial para esto: sendmail, por ejemplo, usa el fichero uucpxtable.

La transformación inversa (conocida coloquialmente como domainizing ) a veces es necesaria cuando se envía un mensaje desde una red UUCP a Internet. Mientras el emisor utilice el nombre de dominio completo en la dirección de destino, este problema se puede evitar si no eliminamos dicho nombre de dominio. Sin embargo, hay sitios UUCP que no pertenecen a ningún dominio. Normalmente llevan el pseudo-dominio uucp.

La base de datos ruta-alias proporciona la principal información de ruta en las redes basadas en UUCP. La entrada es de esta manera (el nombre del sitio y la ruta están separados mediante tabulaciones):

moria.orcnet.org ernie!bert!moria!%s moria ernie!bert!moria!%s

Esto hace que cualquier mensaje enviado a moria sea entregado pasando por ernie y bert. Tanto el nombre moriacomo el nombre UUCP deben ser dados si el emisor no los incluye.

Si usted quiere dirigir todos los mensajes a los anfitriones dentro de un dominio a su repetidor de correo, puede especificar una ruta en la base de datos del alias de ruta, indicando el nombre de dominio precedido por un punto como el destino. Por ejemplo, si a todos los anfitriones en sub.org llegamos por medio de swim!smurf, la entrada de alias de ruta podrías ser de la siguiente manera:

.sub.org swim!smurf!%s

Escribir el fichero de alias de ruta es aceptable sólo cuando accede a un sitio de Internet donde no son necesarias muchas operaciones de encaminamiento. Si tiene que realizar diversas operaciones de encaminamiento para un gran número de anfitriones, la mejor manera de hacerlo es usar la orden alias de ruta para crear el fichero a partir del fichero de mapas. Los mapas son más fáciles de mantener, porque se añade o elimina un sistema editando la entrada al mapa del sistema y volviendo a crear el fichero de mapa. Aunque los mapas publicados por el Proyecto de Mapeado Usenet ya no se usan tanto para el encaminamiento, las redes pequeñas UUCP nos pueden dar la información sobre el encaminamiento de sus propios mapas.

Un fichero de mapa consiste principalmente en una lista de sitios que cada sistema selecciona, o bien seleccionada por algún sistema. El nombre del sistema empieza en la primera columna y va seguido por una lista de enlaces separados por una coma. La lista puede continuar si la siguiente línea comienza por el tabulador. Cada vínculo consiste en el nombre del sitio seguido por un coste entre paréntesis. El coste es una expresión aritmética formada por números y expresiones simbólicas como DAILY o WEEKLY. Las líneas que empiezan por > se ignoran.

Por ejemplo, consideremos moria, que selecciona swim.twobirds.com dos veces al día y bert.sesame.com que lo hace una por semana. El vínculo a bert usa modem lento a 2.400 bps. moria publicaría la siguiente entrada:

moria.orcnet.org bert.sesame.com(DAILY/2), swim.twobirds.com(WEEKLY+LOW) moria.orcnet.org = moria

La última línea también da a conocer a moria bajo su nombre UUCP. Tenga en cuenta que el coste se debe especificar como DAILY/2 porque conectando dos veces al día limita a la mitad el coste del vínculo

Al usar la información de los ficheros de mapas pathalias es capaz de calcular las rutas óptimas a cualquier destino indicado en el fichero de ruta y producir una base de datos ruta-alias con la que realizar el encaminamiento a estos sitios.

alias de ruta proporciona otras opciones como el ocultamiento del sitio (es decir, que sólo se pueda llegar a los sitios a través de una pasarela). Consulte la página sobre alias de ruta del manual para obtener detalles y una lista completa de vínculos cost.

Los comentarios sobre el fichero de mapas suelen contener información adicional sobre los sitios descritos en él. Existe un formato rígido en el que se puede especificar esta información de tal forma que se pueda recuperar a partir de los mapas. Por ejemplo, un programa llamado uuwho utiliza una base de datos creada a partir de los ficheros de mapa para mostrar tal información de manera cómoda. Por ello, si usted contrata un sitio con una organización que distribuye ficheros de mapas, deberá rellenar dicha entrada. A continuación se muestra un ejemplo de entrada de mapa (es la perteneciente al sitio web de Olaf):

#N monad, monad.swb.de, monad.swb.sub.org #S AT 486DX50; Linux 0.99 #O private #C Olaf Kirch #E okir@monad.swb.de #P Kattreinstr. 38, D-64295 Darmstadt, FRG #L 49 52 03 N / 08 38 40 E #U brewhq #W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993 # monad brewhq(DAILY/2) # Domains monad = monad.swb.de monad = monad.swb.sub.org

El espacio en blanco que sigue a los dos primeros caracteres equivale a una tabulación. El significado de la mayoría de los campos está bastante claro; de todas maneras, en caso de registrarse en cualquier dominio, recibiría dicha descripción detallada. El caso de la L es el más curioso: proporciona la posición geográfica (latitud/longitud) del usuario y se encarga de dibujar los mapas PostScript que controlan todos los sitios web de cada país e incluso de toda la red.[2]