Conocemos como encaminamientoel proceso de dirigir un mensaje al sistema anfitri�n del receptor. Aparte de localizar una ruta desde el sitio del emisor hasta el de destino, la elecci�n de rutas implica la detecci�n de errores e incluso la optimizaci�n de la velocidad y el coste.
Hay una gran diferencia entre la elecci�n de rutas por parte de un sitio UUCP y un sitio de Internet. En Internet, la funci�n principal a la hora de dirigir los datos al anfitri�n del receptor (cuando el protocolo IP lo conoce), la realiza la capa de red IP, mientras que en el entorno UUCP, la ruta tiene que ser provista por el usuario o generado por el agente de transmisi�n de correo.
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 [email protected] 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.
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 [email protected], 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.
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 [email protected] 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 [email protected]
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U brewhq
#W [email protected] (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]
| [1] | Los mapas para los sitios registrados en el proyecto de mapeado UUCP se distribuyen a trav�s del grupo de noticias comp.mail.maps ; otras organizaciones pueden publicar distintos mapas para sus redes. |
| [2] | Suelen ser publicados en news.lists.ps-maps. Ojo! Son INMENSOS. |