Uno de los usos más comunes de las redes informáticas desde sus orígenes ha sido el correo electrónico. Empezó siendo un simple servicio que copiaba un fichero de una máquina a otra, y lo añadía al fichero mailbox (buzón de correo) del destinatario. Básicamente, en esto sigue consistiendo el e-mail (correo electrónico), aunque el crecimiento continuo de la red y, consiguientemente, el aumento de la complejidad de encaminado, ha hecho necesario un esquema más elaborado.

Se han diseñado varios estándares de intercambio de correo. Los nodos conectados a la Internet cumplen uno recogido en el RFC 822, complementado en algunos RFCs que describen un método independiente de la máquina para transferir caracteres especiales, y similares. Mucho se ha discutido recientemente sobre el "correo multimedia", que tiene que ver con incluir imágenes y sonido en los mensajes de correo. Otro estándar, X.400, ha sido definido por el CCITT.

Hay ya una gran cantidad de programas de transporte de correo para sistemas UNIX. Uno de los mas conocidos es el sendmail, de la Universidad de Berkeley, que se usa en diversas plataformas. El autor original fue Eric Allman, que esta trabajando activamente en el equipo sendmail de nuevo. Hay dos adaptaciones para Linux del sendmail-5.56c disponibles, una de las cuales se describirá en el capítulo 15. La versión de sendmail actualmente en desarrollo es la 8.6.5.

El agente de correo de uso mas común en Linux es el smail-3.1.28, escrito por Curt Landon Noll y Ronald S. Karr y con Copyright de los mismos autores. Este es el que se incluye en la mayoría de las distribuciones de Linux. En lo sucesivo nos referiremos a él simplemente como smail, aunque hay otras versiones del mismo programa que son totalmente diferentes, y que no describiremos aquí.

Comparado con sendmail, smail es bastante joven aun. Si se ocupan del correo de un nodo pequeño sin necesidades de direccionamiento complicadas, sus capacidades son muy parecidas. Para nodos grandes, sin embargo, sendmail siempre gana, porque su método de configuración es mucho mas flexible.

Ambos smail y sendmail admiten un conjunto de ficheros de configuración que deben ser adaptados a cada caso particular. Aparte de la información que se necesita para hacer funcionar el subsistema de correo (como puede ser el nombre del ordenador local), hay muchos mas parámetros que pueden ajustarse. El fichero principal de configuración de sendmail es muy difícil de entender a la primera. Parece como si el gato se hubiese echado una siesta sobre el teclado con la tecla de mayúsculas pulsada. Los ficheros de configuración de smail están más estructurados y son más fáciles de entender que los del sendmail, pero no dan al usuario tanto poder a la hora de ajustar el comportamiento del gestor de correo.

De todos modos, para nodos pequeños de UUCP o Internet, el trabajo que se necesita para poner a punto cualquiera de ellos es prácticamente el mismo.

En este capítulo trataremos sobre que es el 'e-mail' y que temas tendrá que abordar usted como administrador del sistema. Los capítulos 14 y 15 darán instrucciones para poner a punto smail y sendmail por primera vez. La información que se suministra debe bastar para poner en marcha pequeños nodos, pero hay muchas mas opciones y usted podrá pasar muchas horas felices frente a su ordenador configurando las características más superficiales.

Hacia el final de este capítulo nos ocuparemos brevemente de como poner a punto elm, un programa para usuario de correo muy común en muchos sistemas UNIX, incluyendo Linux.

Para mas información sobre temas específicos de correo electrónico sobre Linux, por favor, consulte el 'Electronic Mail HOWTO' de Vince Skahan, que aparece en comp.os.linux.announce con regularidad. Las distribuciones fuente de elm, smail y sendmail contienen también una documentación muy extensa que debe solucionar la mayoría de sus dudas sobre instalación y puesta a punto. Si busca información sobre correo electrónico en general, hay varios RFCs que tratan específicamente este tema. Una lista de ellos se encuentra en la bibliografía al final del libro.

Un mensaje de correo consta de un contenido (body), que es el texto que ha escrito el remitente, y datos especiales que especifican el destinatario o destinatarios, el medio de transporte, etc., de manera similar a lo que aparece en el sobre de una carta ordinaria.

Estos datos administrativos se clasifican en dos categorías; en la primera categoría están los datos que son específicos del medio de transporte, como son las direcciones del remitente y del destinatario. A esto se le llama el sobre (envelope). Puede ser modificado por el software de transporte a medida que el mensaje es transmitido.

La segunda variedad es cualquier dato necesario para la manipulación del mensaje, que no es propio de ningún mecanismo de transporte, como es la línea del encabezado en la que indicamos el tema del mensaje (Subject), la lista de todos los destinatarios, y la fecha en la que se envío el mensaje. En muchas redes, se ha convertido en un estándar incluir estos datos al comienzo del mensaje, formando lo que se denomina encabezado del mensaje (mail header). Se separa del contenido del mensaje (mail body) por una línea en blanco. 1

La mayoría del software para transporte de correo que se usa en el mundo UNIX usa un formato de encabezado definido en el RFC 822. Su propósito original era especificar un estándar para usar en la ARPANET, pero dado que fue diseñado para ser independiente del entorno de uso, ha sido fácilmente adaptado a otras redes, incluyendo muchas basadas en UUCP.

Pero RFC 822 es solo el máximo denominador común. Otros estándares mas recientes han sido concebidos para dar respuesta a las crecientes necesidades como pueden ser, por ejemplo, encriptación de datos, soporte de conjuntos de caracteres internacionales, y extensiones de correo multimedia (multimedia mail extension, MIME).

En todos esos estándares, el encabezado consiste en varias líneas, separadas por caracteres de retorno de carro. Cada línea consiste en un nombre de campo, que comienza en la columna uno, y el campo en si, separados por dos puntos (:) o un espacio. El formato y la semántica de cada campo varia dependiendo del nombre del mismo. Un campo del encabezado se puede continuar más allá de una línea, si la línea siguiente comienza con un carácter de tabulación. Los campos pueden aparecer en cualquier orden.

Un encabezado de correo típico puede ser algo así:

_____________________________________________
1 Se suele añadir una firma (signature) o .sig a un mensaje, usualmente conteniendo información sobre el autor, junto con un chiste o cita célebre. Se separa del resto del mensaje con una línea conteniendo "--".

Usualmente, todos los campos del encabezado necesarios son generados por la interface con el servidor de correo que usted use, como elm, pine, mush, o mailx. Algunos, sin embargo, son opcionales, y pueden ser añadidos por el usuario. elm, por ejemplo, permite editar parte del encabezado del mensaje. Otros campos son añadidos por el software de transporte de correo. Una lista de campos de encabezado comunes y su significado se da a continuación:

From:
Contiene la dirección de correo electrónico del remitente, y posiblemente el "nombre real". Un verdadero zoológico de formatos distintos se usa aquí.

To:
Esta es la dirección de e-mail del destinatario.

Subject:
Describe el contenido del mensaje en pocas palabras. Al menos eso es lo que debiera hacer.

Date:
La fecha en la que el mensaje fue enviado.

Reply-To:
Especifica la dirección a la que el remitente desea que el destinatario le conteste. Esto puede ser útil si se tienen varias direcciones, pero se desea recibir la mayor parte del correo solo en aquella que se usa mas a menudo. Este campo es opcional.

Organization:
La organización que posee la máquina desde la que se ha enviado el mensaje. Si la máquina usada es la suya propia no incluya este campo, o bien indique "privado" o cualquier trivialidad sin sentido. Este campo es opcional.

Message-ID:
Una cadena generada por el transporte de correo en el sistema remitente. Es única para cada mensaje.

Received:
Cada nodo que procesa su correo (incluyendo las máquinas del remitente y el destinatario) insertan este campo en el encabezado, dando el nombre del nodo, una identificación de mensaje, hora y fecha a la que lo recibieron, de que nodo procede, y que software de transporte ha sido usado. Esto se hace así para que usted pueda conocer la ruta que su mensaje ha seguido, y pueda protestar a la persona responsable si algo ha ido mal.

X-cualquier-cosa:
Ningún programa relacionado con el correo debe protestar sobre cualquier encabezado que comience con X-. Esto se usa para implementar características adicionales que aun no han sido incluidas en un RFC, o que no lo serán nunca. Esto se usa, por ejemplo, en la lista de correo de los Activistas de Linux, donde el canal a usar se selecciona con el campo de encabezado X-Mn-Key:.

La única excepción a esta estructura es la primera línea. Comienza con la palabra clave From seguida de un espacio en blanco, en vez de dos puntos. Para distinguirlo del campo ordinario From: se suele denotar como From_. Contiene la ruta que ha seguido el mensaje, escrita al estilo ruta bang de UUCP (explicado mas adelante), la hora y la fecha en que fue recibido por la última máquina que lo ha procesado, y una parte opcional que especifica desde que máquina ha sido recibido. Como este campo es regenerado por cada sistema que procesa el mensaje, alguna veces queda incluido en los datos del sobre.

El campo From_ continúa existiendo por compatibilidad con procesadores de correo antiguos, pero no se usa demasiado en la actualidad excepto por algunos interfaces de usuario de correo que se basan en él para marcar el comienzo de un mensaje en el buzón del usuario. Para evitar problemas potenciales con líneas del contenido del mensaje que comiencen también con "From ", se ha convertido en practica común distinguir este último caso precediéndolo de un ">".

Generalmente, usted escribirá su correo usando un interface de correo como mail o mailx; u otros mas sofisticados como elm, mush, o pine. Estos programas se denominan agentes de usuario de correo (mail user agents), o MUAs para abreviar. Si usted envía un mensaje de correo, el programa interface en la mayoría de los casos se lo pasara a otro programa para que lo transmita. Este programa se denomina el agente de transporte de correo (mail transport agent), o MTA. En algunos sistemas hay agentes de transporte de correo distintos para envíos locales o lejanos; en otros hay solo un MTA. El comando para envíos lejanos se denomina usualmente rmail, el otro se denomina lmail (si existe).

Un envío local de correo es, por supuesto, algo mas que añadir el mensaje al buzón del destinatario. Usualmente el MTA local entenderá como usar alias (definir direcciones locales de destinatarios que dirigen a otras direcciones) y como usar redirecciones2, es decir, dirigir el correo de un usuario a otra dirección). También, los mensajes que no pudieron ser enviados deben ser normalmente devueltos (bounced) al remitente junto con algún mensaje de error.

Para envíos lejanos, el software de transporte usado depende del tipo de enlace. Si el correo debe enviarse a través de una red que usa TCP/IP, se usará normalmente SMTP.

SMTP son las siglas de Simple Mail Transfer Protocol, o Protocolo Simple de Trasferencia de Correo que se define en el RFC 788 y RFC 821. SMTP usualmente conecta con la máquina del destinatario directamente, negociando la transferencia del mensaje con el demonio SMTP del otro lado.

_____________________________________________
2 N. del T.: Del inglés forwarding

En redes tipo UUCP, el correo no suele ser enviado directamente, sino que es redirigido hasta su destino a través de un conjunto de máquinas intermedias. Para enviar un mensaje a través de un enlace UUCP, el MTA remitente ejecutara usualmente rmail en la máquina intermedia usando uux, y suministrándole el mensaje en la entrada estándar.

Dado que esto se hace para cada mensaje por separado, puede producir una carga considerable de trabajo en un nodo procesador de correo grande, además de inundar las colas UUCP con cientos de pequeños mensajes que ocupan una cantidad de disco desproporcionada. 3 Por esto algunos MTAs permiten recopilar varios mensajes de un sistema remoto en un solo lote. El fichero de lotes contiene los comandos SMTP que el nodo local ejecutaría normalmente si usara una conexión SMTP directa. A esto se le llama BSMTP, o batched SMTP (SMTP por lotes). El lote es suministrado al programa rsmtp o bsmtp en el sistema remoto, que procesara la entrada como si una conexión SMTP normal hubiese ocurrido.

Para el correo electrónico, una dirección consiste en, al menos, el nombre de la máquina que maneja el correo del destinatario, y una identificación de usuario reconocida por ese sistema. Puede ser el nombre de acceso del destinatario, pero puede ser también cualquier otra cosa. Otros esquemas de direcciones, como el X.400, usan un conjunto mas general de "atributos" que se utilizan para buscar la máquina del destinatario en un servidor de directorio X.500.

La forma en que se interpreta un nombre de máquina, es decir, a que nodo va a llegar finalmente nuestro mensaje, y como combinar este nombre con el nombre de usuario del destinatario depende enormemente de la red en la que nos encontremos.

Los nodos en la Internet siguen el estándar RFC 822, que requiere una notación usuario@maquina.dominio, donde maquina.dominio es el nombre de dominio totalmente cualificado (Fully Qualified Domain Name, o FQDN) de la máquina. El signo de arroba que aparece entre medias se suele denominar signo "at"4. Dado que esta notación no indica la ruta hasta la máquina de destino, sino que da el nombre (único) de dicha máquina, a esto se le suele llamar una dirección absoluta.

En el entorno UUCP original, la forma predominante era ruta!maquina!usuario, donde ruta describía una secuencia de máquinas a través de las cuales debía viajar el mensaje para llegar a máquina, su destino final. Esta notación se llama la ruta bang, porque un signo de exclamación se denomina coloquialmente "bang". Hoy en día muchas redes basadas en UUCP han adoptado el RFC 822, y entenderán ese tipo de dirección.

_____________________________________________
3 Esto es así porque el espacio de disco se asigna usualmente en bloques de 1024 Bytes. Incluso un mensaje de como mucho 400 Bytes ocupara 1 Kb completo.
4 N. del T. de la preposición inglesa "at", que significa "en"

Estos dos tipos de direcciones no se mezclan muy bien. Supongamos una dirección maquinaA!usuario@maquinaB. No queda claro si el signo '@' tiene precedencia sobre la ruta o viceversa: ¿Hemos de enviar el mensaje a maquinaB, que lo enviará a maquinaA!usuario, o debe ser enviado maquinaA, que lo redirigirá a usuario@maquinaB?

Las direcciones que mezclan diferentes tipos de operadores de dirección se denominan direcciones híbridas. El más notorio es el ejemplo anterior. Se resuelve usualmente dándole precedencia al signo '@' sobre la ruta. En el ejemplo anterior, esto significa enviar el mensaje a maquinaB primero.

De todos modos, hay una forma de especificar rutas acorde con RFC 822: <@maquinaA,@maquinaB:usuario@maquinaC> denota la dirección de usuario en maquinaC, indicando que se debe llegar a maquinaC a través de maquinaA y maquinaB (en ese orden). Este tipo de dirección se suele llamar una dirección route-addr (de route, ruta y address, dirección).

Y también existe el operador de dirección '%': usuario%maquinaB@maquinaA será enviado primero a maquinaA, que sustituirá el signo de tanto por ciento que se encuentre más a la derecha en la expresión (en este caso el único) por un signo '@'. La dirección quedara ahora usuario@maquinaB, y el gestor de correo redirigirá alegremente el mensaje a la maquinaB que lo entregara a usuario. Este tipo de dirección se suele denominar a veces como "Ye Olde ARPANET Kludge" ("La Vieja Chapuza de ARPANET") y su uso está desaconsejado. Aún así muchos agentes de transporte de correo generan este tipo de direcciones.

Otras redes tienen mas formas de expresar direcciones. Las redes basadas en el protocolo DECnet, por ejemplo, usan dos signos de dos puntos como separador, dando lugar a direcciones como máquina::usuario .5 Finalmente, el estándar X.400 usa un esquema totalmente distinto, describiendo a un destinatario por un conjunto de pares atributo-valor, como país u organización.

En FidoNet, cada usuario se identifica por un código como 2:320/204.9, que consiste en cuatro números que denotan la zona (2 es Europa), red (320 es París y Banlieve), nodo (el repetidor/BBS local), y punto (el PC del usuario). Las direcciones Fidonet se pueden traducir a RFC 822: la anterior se escribiría Thomas.Quinot@p9.f204.n320.z2.fidonet.org.

¿No he dicho antes que los nombres de dominio son fáciles de recordar?

Hay algunas implicaciones al usar esos tipos diferentes de direcciones que serán descritas a lo largo de las próximas secciones. De todos modos, en un entorno RFC 822 raramente se usara otra cosa que direcciones absolutas como usuario@máquina.dominio.

_____________________________________________
5 Cuando se intente llegar a una dirección DECnet desde un entorno RFC 822 se puede usar maquina::usuario.@relevo, donde relevo es el nombre de una pasarela Internet-DECnet conocida.

El proceso de dirigir un mensaje a la máquina del destinatario se denomina encaminado. Además de encontrar una ruta desde el nodo emisor al receptor, este proceso incluye también chequeo de errores así como optimización de velocidad y coste.

Hay mucha diferencia en la forma en la que un nodo UUCP maneja el encaminado y la forma en que lo hace un nodo Internet. En la Internet, el trabajo principal de dirigir datos al nodo del destinatario (una vez que se conoce por su dirección IP) se realiza por la capa IP de control de red, mientras que en UUCP, la ruta debe ser suministrada por el usuario, o generada por el agente de transporte de correo.

En la Internet, depende enteramente del nodo de destino el que se realice algún encaminado especifico de correo. El comportamiento por defecto consiste en enviar el mensaje al nodo de destino buscando su dirección IP, y dejando el encaminado de los datos en si a la capa IP de transporte.

Generalmente, la mayoría de los nodos querrán que todo el correo entrante se dirija a un servidor de correo fácilmente accesible que sea capaz de procesar todo ese tráfico, y que distribuirá ese correo localmente. Para anunciar ese servicio, el nodo publica el llamado campo MX para su dominio local en la base de datos DNS. MX significa Mail Exchanger (Intercambiador de correo) y básicamente quiere decir que el servidor va a actuar como un redistribuidor de correo para todas las máquinas de este dominio. Los campos MX también pueden usarse para manipular el tráfico dirigido a máquinas que no están ellas mismas conectadas a la Internet, como redes UUCP o redes corporativas que contienen información confidencial.

Los campos MX también tienen una preferencia asociada. Es un entero positivo. Si existen varios intercambiadores de correo para una máquina, el agente de transporte de correo intentara enviar el mensaje al intercambiador con menor valor de preferencia, y solo si éste falla probara uno con mayor valor. Si el nodo local es él mismo un intercambiador de correo para la dirección de destino, no redirigirá los mensajes a cualquier máquina MX que tenga un valor de preferencia mayor que el suyo propio: esta es una forma segura de evitar bucles de correo.

Supongamos que una organización, digamos la Sociedad ACME, quiere que todo su correo sea manipulado por su máquina llamada mailhub. Entonces tendrán un campo MX como el siguiente en su base de datos DNS:

Esto anuncia que mailhub.acme.com es un intercambiador de correo para acme.com con un valor de preferencia de 5. Una máquina que desee enviar un mensaje a joe@greenhouse.acme.com buscará el registro DNS de acme.com, y encontrará el campo MX apuntando hacia mailhub. Si no hay ningún MX con un valor de preferencia menor que 5, el mensaje será enviado a mailhub, que lo entregara a greenhouse.

Lo anterior es solo un esbozo de como funcionan los campos MX. Para mas información sobre encaminado de correo en la Internet, por favor consulte el RFC 974.

El encaminado de correo en redes UUCP es mucho mas complicado que en la Internet, porque el software de transporte no realiza ningún encaminado. Al principio, todo el correo tenia que ser dirigido usando rutas bang. Las rutas bang especifican, como hemos dicho ya, una lista de nodos a través de los cuales enviar el mensaje, separados por signos de admiración, y seguida del nombre del usuario. Para dirigir una carta a Juanita, usuaria de una máquina llamada moría, deberíamos usar la ruta eel!swim!moria!juanita. Esto enviaría el correo desde nuestro nodo a eek, desde alli a swim y finalmente a moría.

El inconveniente obvio de esta técnica es que obliga a que recordemos mucho sobre la topología de la red, enlaces rápidos, etc. Aun peor, cualquier cambio en la topología de la red _como enlaces que se eliminan o nodos que se quitan_ puede causar que el mensaje no llegue al destino simplemente porque no se estaba al tanto del cambio. Y finalmente en caso de que nos mudemos a otro lugar, deberemos actualizar todas esas rutas.

Sin embargo, un hecho que hizo que fuese necesario el uso del encaminado manual fue la presencia de nombres de nodo ambiguos: por ejemplo, supongamos que hay dos máquinas llamadas moría, una en los EE.UU., y otra en Francia. ¿A cual de ellas nos referimos con moria!juanita? Esto puede quedar claro especificando que ruta seguir para llegar a moría.

El primer paso para eliminar ambigüedades en nombres de nodos fue la fundación del Proyecto de Cartografía UUCP (The UUCP Mapping Project). Se encuentra en la Universidad de Rutgers, y lleva el registro de todos los nombres de nodos oficiales UUCP, junto con información de sus vecinos UUCP y su localización geográfica, asegurándose de que ningún nombre se repite. La información recogida por el Proyecto de Cartografía se publica como los Mapas de Usenet, que se distribuyen regularmente en Usenet.6 Una entrada típica para un sistema en un mapa (después de eliminar los comentarios) seria algo así:

Esta entrada dice que moria tiene un enlace con bert, al que llama dos veces al día (DAILY=diariamente), y con swim, al que llama una vez a la semana (WEEKLY). Volveremos de nuevo al formato del fichero mapa mas adelante.

Usando la información sobre conectividad proporcionada en los mapas, se pueden generar automáticamente las rutas completas de nuestra máquina a cualquier nodo de destino. Esta información se almacena usualmente en el fichero paths, también llamado base de datos de alias de rutas (pathalias database). Suponiendo que los mapas indican que se puede llegar a bert a través de ernie, entonces una entrada de alias de ruta para moría generada a partir del fragmento de mapa anterior quedaría tal que así:

Si ahora damos una dirección de destino de juanita@moria.uucp, nuestro MTA escogerá la ruta mostrada anteriormente, y enviara el mensaje a ernie con una dirección en el sobre de bert!moria!juanita.

De todos modos, construir un fichero paths a partir de los mapas completos de Usenet no es una buena idea. La información proporcionada en ellos normalmente esta bastante distorsionada, y a veces es obsoleta. Así, solo unos pocos nodos grandes usan los mapas mundiales completos de UUCP para construir su fichero paths. La mayoría de los nodos solo mantienen información de encaminado hacia los nodos en sus cercanías, y envían cualquier correo dirigido a nodos que no encuentran en sus bases de datos a un nodo mas inteligente, con una información de encaminado mas completa. Este esquema se denomina encaminado por nodo inteligente (smart-host routing). Las máquinas que tienen un solo enlace de correo UUCP (llamadas nodos hoja) no realizan ningún encaminado propio; confían enteramente en su nodo inteligente para esta tarea.

La mejor cura contra los problemas vistos con el encaminado en redes UUCP es la adopción del sistema de nombres de dominio en ellas. Por supuesto, no se pueden hacer peticiones a un servidor de nombres usando UUCP. Aun así, muchos nodos UUCP han formado pequeños dominios que coordinan su encaminado internamente. En los mapas, estos dominios publican uno o dos nodos como sus pasarelas de correo, de modo que no tenga que haber una entrada en el mapa para cada nodo en el dominio. Las pasarelas pueden distribuir todo el correo que fluye hacia dentro y hacia fuera del dominio. El esquema de encaminado dentro del dominio es completamente invisible para el resto del mundo.

_____________________________________________
6 Los mapas de nodos registrados en el Proyecto de Cartografía UUCP se distribuyen en el grupo de noticias comp.mail.maps; otras organizaciones pueden publicar mapas separados para su red.

Esto funciona muy bien con el esquema de encaminado por nodo inteligente descrito anteriormente. La información de encaminado global se encuentra solo en las pasarelas; a los nodos menores dentro de un dominio les basta con un pequeño fichero paths escrito a mano que contiene la lista de las rutas dentro de su dominio, y la ruta al concentrador de correo. Incluso las pasarelas de correo no tienen por que incluir información de encaminado hacia cada una de las máquinas UUCP en el mundo. Aparte de la información completa de encaminado para el dominio al que sirven, ahora solo necesitan tener en sus bases de datos rutas a dominios completos. Por ejemplo, la siguiente entrada alias de ruta encaminará todo el correo para nodos del dominio sub.org a smurf:

Cualquier correo dirigido a claire@jones.sub.org será enviado a swim con una dirección en el sobre tal como smurf !jones!claire.

La organización jerárquica del espacio de nombres de dominio permite a los servidores de correo mezclar rutas mas especificas con otras menos especificas. Por ejemplo, un sistema en Francia puede tener rutas especificas hacia subdominios de fr, pero encaminar cualquier correo dirigido a máquinas del dominio us hacia algún sistema en los EE.UU.

De esta forma, el encaminado basado en dominios (que es como se denomina esta técnica) reduce enormemente el tamaño de las bases de datos de encaminado, así como las tareas de administración requeridas.

El mayor beneficio de usar nombres de dominio en un entorno UUCP, de todos modos, es que al cumplir con RFC 822 se pueden fácilmente usar pasarelas entre redes UUCP y la Internet. Hoy en día, muchos dominios UUCP tienen un enlace con una pasarela a Internet que actúa como su nodo inteligente. Enviar mensajes a través de la Internet es mas rápido, y la información de encaminado es mucho mas fiable porque los nodos en la Internet pueden usar DNS en vez de mapas Usenet.

Para poder ser alcanzables desde la Internet, los dominios basados en UUCP usualmente hacen que su pasarela a Internet anuncie una entrada MX para ellos (las entradas MX que fueron descritas anteriormente). Por ejemplo, supongamos que moría pertenece al dominio orcnet.org y que gcc2.groucho.edu actúa como su pasarela a Internet. Entonces moría usaría gcc2 como su nodo inteligente, de modo que todo el correo hacia dominios remotos sería enviado a través de la Internet. Por otro lado, gcc2 anunciaría una entrada MX para orcnet.org, y enviaría todo el correo entrante para nodos de orcnet a moría.

El único problema que queda es que los programas de transporte UUCP no pueden manejar nombres de dominio totalmente cualificados. La mayoría de los paquetes integrados de UUCP fueron diseñados para tratar con nombres de nodos de ocho caracteres como máximo, algunos incluso menos, y usar caracteres no alfanuméricos, como puntos, está totalmente fuera de lugar para la mayoría.

Así, es imprescindible disponer de alguna forma de relacionar nombres RFC 822 y UUCP. La forma en que esto se hace es totalmente dependiente de la implementación. Una manera común de relacionar FQDNs con nombres UUCP es usar el fichero de alias de ruta para esto:

Esto producirá una ruta bang al estilo UUCP puro a partir de una dirección que especifica un nombre de dominio totalmente cualificado. Algunos programas de correo suministran un fichero especial para esto; sendmail, por ejemplo, usa el fichero uucpxtable.

La transformación inversa (llamada coloquialmente dominizar) se necesita a veces cuando se envía correo desde una red UUCP a la Internet. Mientras el remitente use el nombre de dominio totalmente cualificado en la dirección de destino, este problema se puede evitar no eliminando el nombre del dominio de la dirección del sobre cuando se redirige el mensaje al nodo inteligente. De todos modos, siguen existiendo algunos nodos UUCP que no son parte de ningún dominio. Estos se dominizan usualmente añadiendo el pseudo-dominio uucp.

La base de datos de alias de ruta ofrece la información de encaminado principal en redes basadas en UUCP. Una entrada típica será como sigue (nombre del nodo y ruta separadas por tabuladores):  

Esto hace que cualquier mensaje a moría sea enviado vía ernie y bert. Ambos nombres de moría (su nombre totalmente cualificado y su nombre UUCP) deben ser suministrados si el programa no tiene una forma separada de relacionar ambos.

Si se quieren dirigir los mensajes destinados a máquinas dentro de algún dominio a su concentrador de correo, se debe también especificar un camino en la base de datos de alias de ruta, dando el nombre del dominio como objetivo, precedido de un punto. Por ejemplo, si todas las máquinas de sub.org pueden ser alcanzadas a través de swim!smurf, la entrada de alias de ruta debe ser:

Escribir un fichero de alias de ruta es aceptable solo cuando se esta manejando un nodo que no necesita hacer demasiados encaminados. Si se tienen que hacer encaminados hacia un gran número de máquinas, una manera mejor es usar el comando pathalias para crear el fichero a partir de los ficheros de mapa. Los mapas se pueden mantener con mas facilidad, porque solo hay que añadir o quitar un sistema editando la entrada de dicho sistema en el mapa, y volver a crear el fichero de mapa. Aunque los mapas publicados por el Proyecto de Cartografía de Usenet ya no se usan demasiado para encaminar, las redes UUCP pequeñas pueden suministrar información de encaminado en su propio conjunto de mapas.

Un fichero de mapa consiste principalmente en una lista de nodos, junto con los nodos que cada sistema registra o lo registran. El nombre del sistema comienza en la columna uno, y sigue una lista de enlaces separados por comas. La lista se puede continuar en varias líneas, comenzando cada nueva línea con un tabulador. Cada enlace consiste en el nombre del nodo enlazado, seguido del coste, entre corchetes. El coste es una expresión aritmética, consistente en números y costes simbólicos. Las líneas que comienzan con un signo hash (#) se ignoran.

Como ejemplo, consideremos moría, que registra a swim.twobirds.com dos veces al día, y a bert.sesame.com una vez a la semana. Además el enlace con bert usa solo un módem lento de 2400bps. moría publicaría la siguiente entrada en los mapas:

La última línea lo haría ser conocido bajo su nombre UUCP también. Obsérvese que debe ser DAILY/2, porque llamar dos veces al día reduce a la mitad el coste de ese enlace.

Usando la información de dichos ficheros de mapa, pathalias puede calcular rutas óptimas para cualquier destino que aparezca en el fichero de rutas, y producir una base de datos de alias de ruta a partir de éste, que se puede usar para encaminar hacia esos nodos.

pathalias proporciona varias posibilidades mas, como esconder nodos (es decir, hacerlos accesibles solo a través de una pasarela), etc. Véase la página del manual sobre pathalias para mas detalles, además de una lista completa de costes de enlace.

Los comentarios en el fichero de mapa contienen generalmente información adicional sobre los nodos descritos en él. Existe un formato rígido para especificar ésta, de manera que pueda ser recuperada de los mapas. Por ejemplo, un programa llamado uuwho usa una base de datos creada a partir de los ficheros de mapa para presentar esta información de una manera elegante.

Cuando se registra un nodo con una organización que distribuye ficheros de mapa a sus miembros, generalmente se debe rellenar una de esas entradas de mapa.

A continuación hay una entrada de mapa de ejemplo (de hecho, es la del nodo del autor):

El espacio en blanco detrás de los primeros dos caracteres es un tabulador. El significado de la mayoría de los campos es bastante obvio; recibiremos una descripción detallada del dominio con el que vayamos a registrarnos. El campo L es el mas divertido de averiguar: da nuestra posición geográfica en latitud/longitud y se usa para dibujar los mapas postscript que muestran todos los nodos de cada país, así como los del mundo entero. 7

elm significa "electronic mail" (correo electrónico) y es una de las utilidades UNIX mas razonablemente bautizadas. Proporciona una interface de pantalla completa con una buena utilidad de ayuda. No vamos a explicar aquí como se usa elm, solo nos detendremos en sus opciones de configuración.

_____________________________________________
7 Aparecen regularmente en news.lists.ps-maps. Cuidado: son enormes.

Teóricamente, se puede usar elm sin configurar, y todo funciona bien, con suerte. Pero hay algunas opciones que deben definirse, aunque solo se necesitan en contadas ocasiones.

Cuando comienza, elm lee un conjunto de variables de configuración desde el fichero elm.rc en /usr/lib/elm. Entonces, intentara leer el fichero .elm/elmrc en nuestro directorio personal. Normalmente este fichero no se genera a mano. Se crea cuando se escoge "save options" (grabar opciones) desde el menú de opciones de elm.

El conjunto de opciones para el fichero privado elmrc también esta disponible en el fichero global elm.rc. La mayoría de las definiciones en el fichero privado elmrc sustituirán a las del fichero global.

En el fichero global elm.rc, se deben definir las opciones que pertenecen a nuestro nombre de máquina. Por ejemplo, en la Cervecera Virtual, el fichero para vlager contendrá lo siguiente:

Estas opciones definen la idea que tiene elm sobre el nombre de la máquina local. Aunque esta información se usa raramente, debemos definir estas opciones. Obsérvese que estas opciones solo tienen efecto cuando se dan en el fichero global de configuración; cuando se encuentran en nuestro elmrc privado, serán ignoradas.

Recientemente, han habido propuestas para corregir el estándar RFC 822 para soportar varios tipos de mensajes, como texto simple, datos binarios, ficheros Postscript, etc. El conjunto de estándares y RFCs que cubren estos aspectos se suelen conocer como MIME, o Extensiones de Correo Internet Multipropósito (Multipurpose Internet Mail Extensions).

Entre otras cosas, esto permite al destinatario saber si un conjunto de caracteres distinto del estándar ASCII ha sido usado al escribir el mensaje, por ejemplo usando los acentos o diéresis del castellano. Esto tiene soporte en elm hasta cierto punto.

El conjunto de caracteres usado por Linux internamente para representar caracteres se suele denominar ISO-8859-1, que es el nombre del estándar que cumple. También se conoce como Latin-1. Cualquier mensaje que use caracteres de ese conjunto debe llevar la siguiente línea en su encabezado:

El sistema que recibe el mensaje debe reconocer este campo y tomar las medidas apropiadas cuando muestra el mensaje. El valor por defecto para mensajes text/plain (texto simple) es un valor de charset (conjunto de caracteres) de us-ascii.

Para poder mostrar mensajes con conjuntos de caracteres distintos al ASCII, elm debe saber como mostrar esos caracteres. Por defecto, cuando elm recibe un mensaje con un campo charset distinto de us-ascii (o un tipo de contenido distinto de text/plain, a todos los efectos), intenta mostrar el mensaje usando un comando llamado metamail. Los mensajes que requieren metamail para ser mostrados aparecen con una 'M' en la primera columna en la pantalla de listado de mensajes (overview).

Como el conjunto de caracteres nativo de Linux es ISO-8859-1, llamar a metamail no es necesario para mostrar mensajes que usen dicho conjunto. Si se le dice a elm que la pantalla entiende ISO-8859-1, no usara metamail sino que mostrará el mensaje directamente. Esto se puede hacer definiendo la siguiente opción en el elm.rc global:

Obsérvese que se puede definir esta opción incluso cuando nunca vayamos a enviar o recibir mensajes que realmente contengan caracteres distintos del ASCII. Esto es así porque la gente que envía esos mensajes, usualmente configura su programa de correo para que incluya el campo Content-Type: (tipo de contenido) adecuado en el encabezado de correo por defecto, vayan o no a enviar mensajes solo ASCII.

De todos modos, definir esta opción en elm.rc no es suficiente. El problema es que cuando muestra los mensajes con el paginador incorporado, elm llama a una función de biblioteca por cada carácter para determinar si es mostrable o no. Por defecto, esta función solo reconoce caracteres ASCII como mostrables, y muestra todos los demás como "^?".

Debemos solucionar esto definiendo la variable de entorno LC_CTYPE como ISO-8859-1, que le indica a la biblioteca que acepte caracteres Latin-1 como mostrables. El soporte para esta y otras características esta disponible a partir de la libc-4.5.8.

Cuando enviamos mensajes que contienen caracteres especiales del ISO-8859-1, debemos asegurarnos de definir dos variables mas en el fichero elm.rc:

Esto hace que elm defina el conjunto de caracteres como ISO-8859-1 en el encabezado de correo, y lo envíe como valores de 8 bit (el comportamiento por defecto es recortar todos los caracteres a 7 bit).

Por supuesto, cualquiera de estas opciones se puede definir también en el fichero elmrc privado en lugar de en el global.