Mezclar UUCP y RFC-822


Este esquema se llama enrutamiento por anfitrión inteligente. Los anfitriones que tienen sólo un vínculo de correo UUCP (los llamados leaf sites), no pueden realizar el enrutamiento por su cuenta, deben dejar esa labor a un anfitrión inteligente.
La mejor manera de evitar los problemas referentes al enrutamiento 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 enrutamiento 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 enrutamiento dentro del dominio es independiente e invisible para el mundo exterior.
Esto funciona muy bien en el esquema de enrutamiento por anfitrión inteligente. El enrutamiento global de la información sólo lo mantienen los portales; los anfitriones menores dentro de un dominio pueden trabajar solo con archivos de rutas, pequeños, escritos a mano que indiquen las rutas de ese dominio y el camino hacia el enrutador. 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.
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 enrutamiento basado en el dominio (nombre que recibe esta técnica) tanto el tamaño de las bases de datos de enrutamiento 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ápido y más fiable la información de enrutamiento 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ónla sección de nombre Elección en Internet”). Por ejemplo, supongamos que moria pertenece al dominio orcnet.org gcc2.groucho.edu actúa como su pasarela a Internet. Entoncesmoria 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 would announce an MX record for *.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.
This will produce a pure UUCP-style bang path from an address that specifies a fully qualified domain name. Some mailers provide a special file for this; sendmail, for instance, uses the uucpxt able.
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.
Escribir el archivo de alias de ruta es aceptable sólo cuando accede a un sitio de Internet donde no son necesarias muchas operaciones de enrutamiento. Si tiene que realizar diversas operaciones de enrutamiento para un gran número de anfitriones, la mejor manera de hacerlo es usar el comando de alias de ruta para crear el archivo a partir del archivo 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 archivo de mapa. Aunque los mapas publicados por el Proyecto de Mapeado Usenet ya no se usan tanto para el enrutamiento, las pequeñas redes UUCP nos pueden dar la información sobre el enrutamiento de sus propios mapas.
Un archivo 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 cost entre paréntesis. Cost es una expresión aritmética formada por números y expresiones simbólicas como DAILY o WEEKLY. Las líneas que empiezan por hash se ignoran.

Califica este Artículo

Categoría: Conectividad y Redes.




Deja una respuesta