%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright by Olaf Kirch, okir@monad.swb.de   %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Revisado en 30-Enero-1999 por:                                %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Revisado en 27-Marzo-1999 por:                                %
%   Juan Jose Amor <jjamor@ls.fi.upm.es>                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\def\elmlib{\file{/usr/lib/elm}}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%        S T A R T   O F   C H A P T E R                        %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Correo Electr{\'o}nico}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail}
\index{correo electr{\'o}nico}
\index{correo}
\index{email|see {correo}}

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

\index{correo multi-media}
\index{correo!multi-media}
Se han dise\~nado varios est{\'a}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{\'e}todo
independiente de la m\'aquina para transferir caracteres especiales,
y similares. Mucho se ha discutido recientemente sobre el ``correo 
multi-media'', que tiene que ver con incluir im{\'a}genes y sonido en
los mensajes de correo.
Otro est{\'a}ndar, X.400, ha sido definido por el CCITT.


\index{sendmail@\prog{sendmail}}
\index{Allman, Eric}
Hay ya una gran cantidad de programas de transporte de correo para sistemas
\unix{}. Uno de los m{\'a}s conocidos es el
\prog{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 \prog{sendmail} de nuevo. 
Hay dos adaptaciones para \linux{} del \prog{sendmail-5.56c} disponibles,
una de las cuales se describir{\'a} en el cap{\'\i}tulo~\ref{sendmail}.
La versi{\'o}n de \prog{sendmail} actualmente en desarrollo es la~8.6.5.


\index{smail@\prog{smail}}
\index{Karr, Ronald S.}
\index{Noll, Curt Landon}
El agente de correo de uso m{\'a}s com{\'u}n en \linux{} es el \prog{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{\'\i}a de las distribuciones de \linux{}. En lo
sucesivo nos referiremos a \'el simplemente como \prog{smail}, aunque hay otras
versiones del mismo programa que son totalmente diferentes, y que no 
describiremos aqu{\'\i}.


Comparado con \prog{sendmail}, \prog{smail} es bastante joven a\'un. 
Si se ocupan del correo de un nodo peque{\~n}o sin necesidades de
direccionamiento complicadas, sus capacidades son muy parecidas.
Para nodos grandes, sin embargo, \prog{sendmail} siempre gana, porque
su m{\'e}todo de configuraci{\'o}n es mucho m{\'a}s flexible.


Ambos \prog{smail} y \prog{sendmail} admiten un conjunto de ficheros de
configuraci{\'o}n que deben ser adaptados a cada caso particular.
Aparte de la informaci{\'o}n que se necesita para hacer funcionar el 
subsistema de correo (como puede ser el nombre del ordenador local),
hay muchos m{\'a}s par{\'a}metros que pueden ajustarse. El fichero
principal de configuraci{\'o}n de \prog{sendmail} es muy dif{\'\i}cil de
entender a la primera. Parece como si el gato se hubiese echado una siesta
sobre el teclado con la tecla de may{\'u}sculas pulsada.
Los ficheros de configuraci{\'o}n de \prog{smail} est{\'a}n m{\'a}s estructurados
y son m{\'a}s f{\'a}ciles de entender que los del \prog{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{\~n}os de UUCP o Internet,
el trabajo que se necesita para poner a punto cualquiera de ellos es
pr{\'a}cticamente el mismo.


En este cap{\'\i}tulo trataremos sobre qu{\'e} es el `{}e-mail' y qu\'e temas
tendr{\'a} que abordar usted como administrador del sistema. Los 
cap{\'\i}tulos~\ref{smail} y~\ref{sendmail} dar{\'a}n instrucciones para
poner a punto \prog{smail} y \prog{sendmail} por primera vez.
La informaci{\'o}n que se suministra debe bastar para poner en marcha
peque{\~n}os nodos, pero hay muchas m{\'a}s opciones y usted podr{\'a} pasar
muchas horas felices frente a su ordenador configurando las caracter{\'\i}sticas
m{\'a}s superficiales.


Hacia el final de este cap{\'\i}tulo nos ocuparemos brevemente de c\'omo
poner a punto \prog{elm}, un programa para usuario de correo muy com{\'u}n
en muchos sistemas \unix{}, incluyendo \linux{}.


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


\section{{?`}Qu\'e es un mensaje de correo?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Brief intro to messages and headers. Mentions RFC 822.        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.message-format}
\index{correo!formato de un mensaje}
\index{correo!encabezados}

Un mensaje de correo consta de un contenido ({\it 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{\'\i}as;
en la primera categor{\'\i}a est{\'a}n los datos que son espec{\'\i}ficos
del medio de transporte, como son las direcciones del remitente y
del destinatario. A esto se le llama \emph{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{\'o}n del
mensaje, que no es propio de ning{\'u}n mecanismo de transporte, como es
la l{\'\i}nea del encabezado en la que indicamos el tema del mensaje
({\it Subject}), 
la lista de todos los destinatarios, y la fecha en la que se envi{\'o} el 
mensaje. En muchas redes, se ha convertido en un est{\'a}ndar incluir estos
datos al comienzo del mensaje, formando lo que se denomina 
\emph{encabezado del mensaje (mail header)}. Se separa del 
\emph{contenido del mensaje (mail body)} por una l{\'\i}nea en blanco.
\footnote{
 Se suele a{\~n}adir una \emph{firma (signature)} o \file{.sig} a un
 mensaje, usualmente conteniendo informaci{\'o}n sobre el autor,
 junto con un chiste o cita c{\'e}lebre. Se separa del resto del mensaje con
 una l{\'\i}nea conteniendo ``\term{-- }''.
 %%% Maybe \verb*|-- | would be better?
}

La mayor{\'\i}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{\'o}sito original era especificar un est{\'a}ndar para usar en la ARPANET,
pero dado que fue dise{\~n}ado para ser independiente del entorno de uso,
ha sido f{\'a}cilmente adaptado a otras redes, incluyendo muchas basadas en 
UUCP.


Pero RFC~822 es s\'olo el m{\'a}ximo denominador com{\'u}n. Otros
est{\'a}ndares m{\'a}s recientes han sido concebidos para dar 
respuesta a las crecientes
necesidades como pueden ser, por ejemplo, encriptaci{\'o}n de datos,
soporte de conjuntos de caracteres internacionales, y extensiones
de correo multimedia (multi-media mail extension, MIME).


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


Un encabezado de correo t{\'\i}pico puede ser algo as{\'\i}:


\noindent
\begin{tscreen}
\begin{verbatim}
From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path: <brewhq.swb.de!ora.com!andyo>
Received: from brewhq.swb.de by monad.swb.de with uucp
        (Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST
Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
        (Smail3.1.28.1 #28.6) id <m0pqoQr-0008qhC>; Tue, 12 Apr 94 21:47 MEST
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Apr 94 15:56 -0400
Date: Tue, 12 Apr 1994 15:56:49 -0400
Message-Id: <199404121956.PAA07787@ruby>
From: andyo@ora.com (Andy Oram)
To: okir@monad.swb.de
Subject: Re: Tu parte de RPC
\end{verbatim}
\end{tscreen}


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


\begin{dispitems}
\ditem[\mhdr{From:}]
        Contiene la direcci{\'o}n de correo electr{\'o}nico del remitente,
        y posiblemente el ``nombre real''. Un verdadero zool{\'o}gico de formatos
        distintos se usa aqu{\'\i}.

\ditem[\mhdr{To:}]
        Esta es la direcci{\'o}n de e-mail del destinatario.

\ditem[\mhdr{Subject:}]
        Describe el contenido del mensaje en pocas palabras. Al 
        menos eso es lo que \emph{debiera} hacer.

\ditem[\mhdr{Date:}] 
        La fecha en la que el mensaje fue enviado.

\ditem[\mhdr{Reply-To:}]
        Especifica la direcci{\'o}n a la que el remitente desea que
        el destinatario le conteste. Esto puede ser {\'u}til si se
        tienen varias direcciones, pero se desea recibir la mayor
        parte del correo solo en aqu\'ella que se usa m{\'a}s a menudo.
        Este campo es opcional.

\ditem[\mhdr{Organization:}]
        La organizaci{\'o}n que posee la m{\'a}quina desde la que se ha
        enviado el mensaje. Si la m{\'a}quina usada es la suya propia
        no incluya este campo, o bien indique ``privado'' o cualquier
        trivialidad sin sentido. Este campo es opcional.

\ditem[\mhdr{Message-ID:}]
        Una cadena generada por el transporte de correo en el sistema
        remitente. Es {\'u}nica para cada mensaje.

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

\ditem[\mhdr{X-\sl cualquier-cosa:}]
        Ning{\'u}n programa relacionado con el correo debe protestar sobre
        cualquier encabezado que comience con \mhdr{X-}. Esto se usa
        para implementar caracter{\'\i}sticas adicionales que aun no 
        han sido incluidas en un RFC, o que no lo ser{\'a}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 \mhdr{X-Mn-Key:}.

\end{dispitems}


La {\'u}nica excepci{\'o}n a esta estructura es la primera l{\'\i}nea. Comienza
con la palabra clave \mhdr{From} seguida de un espacio en blanco, en vez
de dos puntos. Para distinguirlo del campo ordinario \mhdr{From:} se
suele denotar como \mhdr{From\_}. Contiene la ruta que ha seguido el
mensaje, escrita al estilo ruta bang de UUCP (explicado m{\'a}s adelante),
la hora y la fecha en que fue recibido por la {\'u}ltima m{\'a}quina que lo 
ha procesado, y una parte opcional que especifica desde qu\'e m{\'a}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 \mhdr{From\_} contin\'ua 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 \'el para
marcar el comienzo de un mensaje en el buz{\'o}n del usuario. Para evitar
problemas potenciales con l\'{\i}neas del contenido del mensaje que comiencen 
tambi{\'e}n con ``From '', se ha convertido en pr{\'a}ctica com{\'u}n distinguir
este {\'u}ltimo caso precedi{\'e}ndolo de un ``$>$''.



\section{{?`}C\'omo se reparte el correo?}
\label{mail.delivery}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Mail transport and Delivery.                                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{correo!escribiendo}
\index{escribiendo correo}
\index{correo!reparto|(}
\index{reparto!correo|(}
\index{intercambio!correo|(}
\index{lmail@\prog{lmail}}
\index{rmail@\prog{rmail}}

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


\index{correo!devuelto}
\index{devolver correo}
Un env{\'\i}o local de correo es, por supuesto, algo m\'as que a{\~n}adir el 
mensaje al buz{\'o}n del destinatario. Usualmente el MTA local entender{\'a}
c\'omo usar alias (definir direcciones locales de destinatarios que dirigen
a otras direcciones) y c\'omo usar redirecciones\footnote{N. del T.: Del
ingl\'es {\it forwarding}},
es decir, dirigir el correo de un usuario a otra direcci{\'o}n). Tambi{\'e}n,
los mensajes que no pudieron ser enviados deben ser normalmente
\emph{devueltos (bounced)} al remitente junto con alg{\'u}n mensaje de error.


\index{Protocolo Simple de Transferencia de Correo|see {SMTP}}
\index{SMTP}
Para env{\'\i}os lejanos, el software de transporte usado depende del tipo 
de enlace. Si el correo debe enviarse a trav{\'e}s de una red que usa TCP/IP,
se usara normalmente SMTP. SMTP son las siglas de 
{\em 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{\'a}quina del destinatario directamente, negociando la transferencia del
mensaje con el demonio SMTP del otro lado.


\index{remoto/a!ejecuci{\'o}n}
\index{UUCP!correo}
\index{correo!sobre UUCP}


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


\index{BSMTP}
\index{SMTP!por lotes}
\index{correo!proceso por lotes}
\index{proceso por lotes!correo}
\index{rsmtp@\prog{rsmtp}}
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{\'a}s de inundar las colas UUCP con cientos de peque{\~n}os mensajes
que ocupan una cantidad de disco desproporcionada.  \footnote{
  Esto es as{\'\i} porque el espacio de disco se asigna usualmente en
  bloques de 1024 Bytes. Incluso un mensaje de como mucho 400 Bytes
  ocupar{\'a} 1 Kb completo.
} 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{\'\i}a normalmente si
usara una conexi{\'o}n SMTP directa. A esto se le llama BSMTP, o
\emph{batched} SMTP (SMTP por lotes). El lote es suministrado al programa
\prog{rsmtp} o \prog{bsmtp} en el sistema remoto, que procesar{\'a} la entrada
como si una conexi{\'o}n SMTP normal hubiese ocurrido.

\index{correo!reparto|)}
\index{intercambio!correo|)}
\index{reparto!correo|)}


\section{Direcciones de correo electr{\'o}nico}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Gives an introduction to Addresses. Could also be used in a   %
% Section on Using mail.                                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.address}
\index{correo!formatos de direcciones|(}
\index{direcciones!correo|(}

Para el correo electr{\'o}nico, una direcci{\'o}n consiste en, al menos,
el nombre de la m{\'a}quina que maneja el correo del destinatario, y 
una identificaci{\'o}n de usuario reconocida por ese sistema. Puede ser
el nombre de acceso del destinatario, pero puede ser tambi{\'e}n cualquier
otra cosa. Otros esquemas de direcciones, como el X.400, usan un conjunto
m{\'a}s general de ``atributos'' que se utilizan para buscar la m\'aquina
del destinatario en un servidor de directorio X.500.


La forma en que se interpreta un nombre de m{\'a}quina, es decir, a qu\'e
nodo va a llegar finalmente nuestro mensaje, y c\'omo 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{\'a}ndar RFC~822, que requiere una notaci{\'o}n 
\host{usuario@m{\'a}quina.dominio}, donde \host{m{\'a}quina.dominio} es el nombre
de dominio totalmente cualificado (Fully Qualified Domain Name, o FQDN) 
de la m{\'a}quina. El signo de {\it arroba} que aparece entre medias se suele
denominar signo ``at''\footnote{
N. del T. de la preposici{\'o}n inglesa ``at'', que significa ``en''}. 
Dado que esta notaci{\'o}n no indica la ruta hasta la m{\'a}quina de destino, sino
que da el nombre ({\'u}nico) de dicha m{\'a}quina, a esto se le suele llamar
una direcci{\'o}n \emph{absoluta}.


\index{correo!direcciones con ruta bang}
\index{direcciones!ruta bang}
En el entorno UUCP original, la forma predominante era
\host{ruta!m{\'a}quina!usuario}, donde \host{ruta} describ{\'\i}a una secuencia
de m{\'a}quinas a trav{\'e}s de las cuales deb{\'\i}a viajar el mensaje para llegar 
a \host{m{\'a}quina}, su destino final. Esta notaci\'{\o}n se llama la
\emph{ruta bang}, porque un signo de exclamaci{\'o}n se denomina
coloquialmente ``bang''. Hoy en d{\'\i}a  muchas redes basadas en UUCP han
adoptado el RFC~822, y entender{\'a}n ese tipo de direcci{\'o}n.


\index{direcciones!hibridas@h{\'\i}bridas}
Estos dos tipos de direcciones no se mezclan muy bien. Supongamos una
direcci{\'o}n \email{m{\'a}quinaA!usuario@m{\'a}quinaB}. No queda claro si el signo
`\email{@}' tiene precedencia sobre la ruta o viceversa: 
{?`}Hemos de enviar el mensaje a \host{m{\'a}quinaB}, que lo enviar{\'a} a
\host{m{\'a}quinaA!usuario}, o debe ser enviado \host{m{\'a}quinaA}, que lo 
redirigir{\'a} a \email{usuario@m{\'a}quinaB}?


Las direcciones que mezclan diferentes tipos de operadores de direcci{\'o}n
se denominan \emph{direcciones h{\'\i}bridas}. El m{\'a}s notorio es el
ejemplo anterior. Se resuelve usualmente d{\'a}ndole precedencia al
signo `\email{@}' sobre la ruta. En el ejemplo anterior, esto significa
enviar el mensaje a \host{m{\'a}quinaB} primero.


% Those awkward $>$ and $<$ are there to protect the > from LaTeX... yuk!
% This will only look okay with LaTeX2e, I fear.
\index{direcciones!route-addr}
\index{correo!direcciones route-addr}
De todos modos, hay una forma de especificar rutas acorde con RFC~822:
\email{$<$@m{\'a}quinaA,@m{\'a}quinaB:usuario@m{\'a}quinaC$>$} denota la 
direcci{\'o}n de \email{usuario} en \host{m{\'a}quinaC}, indicando que
se debe llegar a \host{m{\'a}quinaC} a trav{\'e}s de \host{m{\'a}quinaA}
y \host{m{\'a}quinaB} (en ese orden). Este tipo de direcci{\'o}n se suele 
llamar una \emph{direcci{\'o}n route-addr} (de route, ruta y address,
direcci{\'o}n).


\index{Ye Olde ARPANET kludge}
Y tambi{\'e}n existe el operador de direcci{\'o}n `\email{\%}':
\email{usuario\%m{\'a}quinaB@m{\'a}quinaA} ser{\'a} enviado primero a \host{m{\'a}quinaA},
que sustituir{\'a} el signo de tanto por ciento que se encuentre m{\'a}s
a la derecha en la expresi{\'o}n (en este caso el {\'u}nico) por un
signo `\email{@}'. La direcci{\'o}n quedar{\'a} ahora \user{usuario@m{\'a}quinaB},
y el gestor de correo redirigir{\'a} alegremente el mensaje a la 
\host{m{\'a}quinaB} que lo entregar{\'a} a \email{usuario}. Este tipo de
direcci{\'o}n se suele denominar a veces como ``Ye Olde ARPANET Kludge''
(``La Vieja Chapuza de ARPANET'') y su uso est{\'a} desaconsejado.
Aun as{\'\i}  muchos agentes de transporte de correo generan este tipo
de direcciones.

% It was used on the ARPANET to reach hosts who were not registered
% officially with the Network Information Center, so that messages had to
% be sent via a mail relay that was known to handle mail for these
% ``hidden'' sites.


Otras redes tienen m{\'a}s 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
\var{m{\'a}quina}\email{::}\var{usuario}.\footnote{
 Cuando se intente llegar a una direcci{\'o}n DECnet desde un entorno RFC~822
 se puede usar \email{\var{m{\'a}quina}::\var{usuario}.@\var{relevo}}, donde
 \var{relevo} es el nombre de una pasarela Internet-DECnet conocida.
} Finalmente, el est{\'a}ndar X.400 usa un esquema totalmente distinto,
describiendo a un destinatario por un conjunto de pares atributo-valor,
como pa{\'\i}s u organizaci{\'o}n.


En FidoNet, cada usuario se identifica por un c{\'o}digo como \host{2:320/204.9},
que consiste en cuatro n{\'u}meros que denotan la zona (2 es Europa), red
(320 es Par{\'\i}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{\'\i}a \email{Thomas.Quinot@p9.f204.n320.z2.fidonet.org}. 
{?`}No he dicho antes que los nombres de dominio son f{\'a}ciles de recordar?


Hay algunas implicaciones al usar esos tipos diferentes de direcciones que
ser{\'a}n descritas a lo largo de las pr{\'o}ximas secciones. De todos modos,
en un entorno RFC~822 raramente se usar{\'a} otra cosa que direcciones 
absolutas como \email{\var{usuario}@\var{m{\'a}quina}.\var{dominio}}.

\index{correo!formatos de direcciones|)}
\index{direcciones!correo|)}

\section{{?`}C\'omo funciona el encaminado del correo?}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Extension to the above chapter on addresses.                  %
% Short introduction to maps, pathalias, and name servers.      %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.routing}
\index{correo!encaminado de|(}
\index{encaminado!correo|see {correo, encaminado de}}

El proceso de dirigir un mensaje a la m{\'a}quina del destinatario se
denomina \emph{encaminado}. Adem{\'a}s de encontrar una ruta desde
el nodo emisor al receptor, este proceso incluye tambi{\'e}n chequeo de 
errores as{\'\i} como optimizaci{\'o}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{\'o}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.


\subsection{Encaminado de correo en la Internet}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{mail.routing.internet}{Encaminado de correo en la Internet}
\index{correo!encaminado de!Internet}
\index{correo!encaminado basado en dominios}
\index{correo!centralizado}
\index{manipulacion@manipulaci{\'o}n centralizada del correo}
\index{Internet!encaminado de correo}
\index{Intercambiador de Correo (campo de DNS)}
\index{MX (campo de DNS)}
\index{correo!pasarela de}
\index{pasarela!de correo}

En la Internet, depende enteramente del nodo de destino el que se realice
alg{\'u}n encaminado espec{\'\i}fico de correo. El comportamiento por defecto
consiste en enviar el mensaje al nodo de destino buscando su direcci{\'o}n IP,
y dejando el encaminado de los datos en s\'{\i} a la capa IP de transporte.


\index{correo!encaminado de!entre Internet y UUCP}
Generalmente, la mayor{\'\i}a de los nodos querr{\'a}n que todo el correo
entrante se dirija a un servidor de correo f{\'a}cilmente accesible que sea capaz
de procesar todo ese tr{\'a}fico, y que distribuir{\'a} 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 \emph{Mail Exchanger 
(Intercambiador de correo)} y b{\'a}sicamente quiere decir que el servidor 
va a actuar como
un redistribuidor de correo para todas las m{\'a}quinas de este dominio.
Los campos MX tambi{\'e}n pueden usarse para manipular el tr\'afico dirigido a
m{\'a}quinas que no est{\'a}n ellas mismas conectadas a la Internet, como redes UUCP
 o redes corporativas que contienen informaci{\'o}n confidencial.


Los campos MX tambi{\'e}n tienen una \emph{preferencia} asociada. Es un 
entero positivo. Si existen varios intercambiadores de correo para una
m{\'a}quina, el agente de transporte de correo intentar{\'a} enviar el
mensaje al intercambiador con menor valor de preferencia, y s\'olo si
\'este falla probar{\'a} uno con mayor valor. Si el nodo local es {\'e}l mismo
un intercambiador de correo para la direcci{\'o}n de destino, no 
redirigir\'a los mensajes a cualquier m{\'a}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{\'o}n, digamos la Sociedad ACME, quiere que todo
su correo sea manipulado por su m{\'a}quina llamada \host{mailhub}.  
Entonces tendr{\'a}n un campo MX como el siguiente en su base de datos DNS:


\begin{tscreen}
\begin{verbatim}
acme.com        IN   MX      5    mailhub.acme.com
\end{verbatim}
\end{tscreen}


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


Lo anterior es s\'olo un esbozo de c\'omo funcionan los campos MX. Para m{\'a}s
informaci{\'o}n sobre encaminado de correo en la Internet, por favor consulte
el RFC~974.


\subsection{Encaminado de correo en el mundo UUCP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.routing.uucp}
\index{correo!encaminado de!redes UUCP}
\index{correo!direcciones con ruta bang}
\index{direcciones!ruta bang}
\index{UUCP!correo}

El encaminado de correo en redes UUCP es mucho m{\'a}s complicado que
en la Internet, porque el software de transporte no realiza
ning{\'u}n encaminado. Al principio, todo el correo ten{\'\i}a que ser
dirigido usando rutas bang. Las rutas bang especifican, como hemos dicho ya,
una lista
de nodos a trav{\'e}s de los cuales enviar el mensaje, separados por
signos de admiraci{\'o}n, y seguida del nombre del usuario. Para dirigir
una carta a Juanita, usuaria de una m{\'a}quina llamada \host{moria},
deber{\'\i}amos usar la ruta \email{eel!swim!moria!juanita}. Esto
enviar{\'\i}a el correo desde nuestro nodo a \host{eek}, desde all{\'\i} 
a \host{swim} y finalmente a \host{moria}.


El inconveniente obvio de esta t{\'e}cnica es que obliga a que recordemos
mucho sobre la topolog{\'\i}a de la red, enlaces r{\'a}pidos, etc.
Aun peor, cualquier cambio en la topolog{\'\i}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.


\index{nombre de nodo!ambiguo}
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{\'a}quinas llamadas \host{moria}, una en los
EE.UU., y otra en Francia. {?`}A cual de ellas nos referimos con
\email{moria!juanita}? Esto puede quedar claro especificando que ruta
seguir para llegar a \host{moria}.


\index{UUCP!Proyecto de Cartografia@Proyecto de Cartograf{\'\i}a}
\index{correo!mapas}
\index{Usenet!mapas}
\index{mapas, Usenet}
El primer paso para eliminar ambig{\"u}edades en nombres de nodos fue la
fundaci{\'o}n del \emph{Proyecto de Cartograf{\'\i}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{\'o}n de sus vecinos UUCP y su localizaci{\'o}n geogr{\'a}fica,
asegur{\'a}ndose de que ning{\'u}n nombre se repite. La informaci{\'o}n 
recogida por el Proyecto de Cartograf{\'\i}a se publica como los
\emph{Mapas de Usenet}, que se distribuyen regularmente en
Usenet.\footnote{
 Los mapas de nodos registrados en el Proyecto de Cartograf{\'\i}a UUCP
 se distribuyen en el grupo de noticias \ngrp{comp.mail.maps};
 otras organizaciones pueden publicar mapas separados para su red.
} Una entrada t{\'\i}pica para un sistema en un mapa (despu{\'e}s de 
eliminar los comentarios) ser{\'\i}a algo as{\'\i}:

\begin{tscreen}
\begin{verbatim}
moria
        bert(DAILY/2),
        swim(WEEKLY)
\end{verbatim}
\end{tscreen}

Esta entrada dice que \host{moria} tiene un enlace con \host{bert},
al que llama dos veces al d{\'\i}a (DAILY=diariamente), y con
\host{swim}, al que llama una vez a la semana (WEEKLY). Volveremos
de nuevo al formato del fichero mapa m{\'a}s adelante.


\index{correo!fichero paths@fichero \file{paths}}
\index{pathalias@\prog{pathalias}}
\index{fichero paths@fichero \file{paths}}

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


\begin{tscreen}
\begin{verbatim}
moria           ernie!bert!moria!%s
\end{verbatim}
\end{tscreen}


Si ahora damos una direcci{\'o}n de destino de \email{juanita@moria.uucp},
nuestro MTA escoger{\'a} la ruta mostrada anteriormente, y enviar{\'a} el
mensaje a \host{ernie} con una direcci{\'o}n en el sobre de 
\email{bert!moria!juanita}.


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


\subsection{Mezcla de UUCP y RFC~822}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Relaying between UUCP and RFC 822				%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{correo!centralizado}
\index{manipulacion@manipulaci{\'o}n centralizada del correo}
\index{correo!encaminado de!basado en dominios}
\index{dominios!encaminado de correo}
La mejor cura contra los problemas vistos con el encaminado en redes UUCP es la adopci{\'o}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{\'\i}, muchos nodos UUCP han formado peque{\~n}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.


Esto funciona muy bien con el esquema de encaminado por nodo inteligente
descrito anteriormente. La informaci{\'o}n de encaminado global se
encuentra s{\'o}lo en las pasarelas; a los nodos menores dentro de un 
dominio les basta con un peque{\~n}o fichero \file{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 qu\'e incluir 
informaci{\'o}n de encaminado hacia cada una de las m{\'a}quinas UUCP
en el mundo. Aparte de la informaci{\'o}n completa de encaminado para el
dominio al que sirven, ahora s{\'o}lo necesitan tener en sus bases
de datos rutas a dominios completos. Por ejemplo, la siguiente entrada 
alias de ruta encaminar{\'a} todo el correo para nodos del
dominio \host{sub.org} a \host{smurf}:


\begin{tscreen}
\begin{verbatim}
.sub.org        swim!smurf!%s
\end{verbatim}
\end{tscreen}


Cualquier correo dirigido a \email{claire@jones.sub.org} ser{\'a}
enviado a \host{swim} con una direcci{\'o}n en el sobre tal como
\email{smurf!jones!claire}.


La organizaci{\'o}n jer{\'a}rquica del espacio de nombres de dominio permite
a los servidores de correo mezclar rutas m{\'a}s espec{\'\i}ficas
con otras menos espec{\'\i}ficas. Por ejemplo, un sistema en Francia
puede tener rutas espec{\'\i}ficas hacia subdominios de \host{fr},
pero encaminar cualquier correo dirigido a m{\'a}quinas del dominio
\host{us} hacia alg{\'u}n sistema en los EE.UU. De esta forma, el
encaminado basado en dominios (que es como se denomina esta t{\'e}cnica)
reduce enormemente el tama{\~n}o de las bases de datos de encaminado,
as{\'\i} como las tareas de administraci{\'o}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{\'a}cilmente usar pasarelas
entre redes UUCP y la Internet. Hoy en d\'{\i}a, muchos dominios UUCP tienen
un enlace con una pasarela a Internet que act{\'u}a como su nodo inteligente.
Enviar mensajes a trav{\'e}s de la Internet es m{\'a}s r{\'a}pido, y la 
informaci{\'o}n de encaminado es mucho m{\'a}s 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 \host{moria} pertenece al dominio \host{orcnet.org} y que
\host{gcc2.groucho.edu} act{\'u}a como su pasarela a Internet. Entonces
\host{moria} usar{\'\i}a \host{gcc2} como su nodo inteligente, de modo que
todo el correo hacia dominios remotos ser{\'\i}a enviado a trav{\'e}s de la 
Internet. Por otro lado, \host{gcc2} anunciar{\'\i}a una entrada MX para
\host{orcnet.org}, y enviar{\'\i}a todo el correo entrante para nodos de
\host{orcnet} a \host{moria}.


El {\'u}nico problema que queda es que los programas de transporte UUCP
no pueden manejar nombres de dominio totalmente cualificados. La
mayor{\'\i}a de los paquetes integrados de UUCP fueron dise{\~n}ados para
tratar con nombres de nodos de ocho caracteres como m{\'a}ximo, 
algunos incluso menos, y usar caracteres no alfanum{\'e}ricos, como puntos,
est{\'a} totalmente fuera de lugar para la mayor{\'\i}a.


As{\'\i}, 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{\'o}n.
Una manera com{\'u}n de relacionar FQDNs con nombres UUCP es usar el fichero 
de alias de ruta para esto:


\begin{tscreen}
\begin{verbatim}
moria.orcnet.org  ernie!bert!moria!%s
\end{verbatim}
\end{tscreen}


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


La transformaci{\'o}n inversa (llamada coloquialmente {\it dominizar}) se
necesita a veces cuando se env{\'\i}a correo desde una red UUCP a la
Internet. Mientras el remitente use el nombre de dominio totalmente
cualificado en la direcci{\'o}n de destino, este problema se puede evitar
no eliminando el nombre del dominio de la direcci{\'o}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{\'u}n dominio.
\'Estos se {\it dominizan} usualmente a{\~n}adiendo el pseudo-dominio
\host{uucp}.


\index{correo!encaminado de|)}


\section{Formatos de Fichero Mapa y Alias de Ruta}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Map files                                                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.pathalias} \label{mail.maps}
\index{correo!fichero paths@fichero \file{paths}|(}
\index{fichero paths@fichero \file{paths}|(}
\index{generar un fichero paths@generar un fichero \file{paths}}

La base de datos de alias de ruta ofrece la informaci{\'o}n de 
encaminado principal en redes basadas en UUCP. Una entrada t{\'\i}pica
ser{\'a} como sigue (nombre del nodo y ruta separadas por tabuladores):


\begin{tscreen}
\begin{verbatim}
moria.orcnet.org  ernie!bert!moria!%s
moria             ernie!bert!moria!%s
\end{verbatim}
\end{tscreen}


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


\index{correo!centralizado}
\index{manipulacion@manipulaci{\'o}n centralizada del correo}
\index{correo!encaminado basado en dominios}
Si se quieren dirigir los mensajes destinados a m{\'a}quinas dentro de
alg{\'u}n dominio a su concentrador de correo, se debe tambi{\'e}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{\'a}quinas de
\host{sub.org} pueden ser alcanzadas a trav{\'e}s de \host{swim!smurf}, 
la entrada de alias de ruta debe ser:


\begin{tscreen}
\begin{verbatim}
.sub.org        swim!smurf!%s
\end{verbatim}
\end{tscreen}


Escribir un fichero de alias de ruta es aceptable s{\'o}lo cuando se
est{\'a} manejando un nodo que no necesita hacer demasiados encaminados.
Si se tienen que hacer encaminados hacia un gran n{\'u}mero de m{\'a}quinas,
una manera mejor es usar el comando \prog{pathalias} para crear el fichero
a partir de los ficheros de mapa. Los mapas se pueden mantener con m{\'a}s 
facilidad, porque s\'olo hay que a{\~n}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{\'\i}a de Usenet
ya no se usan demasiado para encaminar, las redes UUCP
peque{\~n}as pueden suministrar informaci{\'o}n de encaminado en su propio
conjunto de mapas.


\index{correo!mapas}
\index{Usenet!mapas}
\index{UUCP!mapas}
\index{mapas, Usenet}
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\'{\i}neas, comenzando cada nueva
l{\'\i}nea con un tabulador.
Cada enlace consiste en el nombre del nodo enlazado, seguido del
coste, entre corchetes. El coste es una expresi{\'o}n aritm{\'e}tica,
consistente en n{\'u}meros y costes simb{\'o}licos. Las lineas que comienzan con
un signo hash (\#) se ignoran.


Como ejemplo, consideremos \host{moria}, que registra a \host{swim.twobirds.com}
dos veces al d{\'\i}a, y a \host{bert.sesame.com} una vez a la semana. 
Adem{\'a}s el enlace con \host{bert} usa s{\'o}lo un m{\'o}dem lento de 2400bps.
\host{moria} publicar{\'\i}a la siguiente entrada en los mapas:


\begin{tscreen}
\begin{verbatim}
moria.orcnet.org
        swim.twobirds.com(DAILY/2),
        bert.sesame.com(WEEKLY+LOW)

moria.orcnet.org = moria
\end{verbatim}
\end{tscreen}


La {\'u}ltima l{\'\i}nea lo har{\'\i}a ser conocido bajo su nombre UUCP tambi{\'e}n.
Obs{\'e}rvese que debe ser \keyword{DAILY/2}, porque llamar dos veces al 
d{\'\i}a reduce a la mitad el coste de ese enlace.


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


\index{pathalias@\prog{pathalias}|(}
\prog{pathalias} proporciona varias posibilidades m{\'a}s, como esconder nodos
(es decir, hacerlos accesibles s\'olo a trav{\'e}s de una pasarela), etc.
V{\'e}ase la p{\'a}gina del manual sobre \prog{pathalias} para m{\'a}s detalles,
adem{\'a}s de una lista completa de costes de enlace.


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


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


A continuaci{\'o}n hay una entrada de mapa de ejemplo (de hecho, es la del
nodo del autor):

\begin{tscreen}
\begin{verbatim}
#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
\end{verbatim}
\end{tscreen}


El espacio en blanco detr{\'a}s de los primeros dos caracteres es un tabulador.
El significado de la mayor{\'\i}a de los campos es bastante obvio; recibiremos
una descripci{\'o}n detallada del dominio con el que vayamos a registrarnos.
El campo \keyword{L} es el m{\'a}s divertido de averiguar: da nuestra posici{\'o}n
geogr{\'a}fica en latitud/longitud y se usa para dibujar los mapas 
{\it postscript} que
muestran todos los nodos de cada pa{\'\i}s, as{\'\i} como los del mundo 
entero.  \footnote{
 Aparecen regularmente en \ngrp{news.lists.ps-maps}. Cuidado: son {\bf 
\emph{enormes}}.
}

\index{correo!fichero paths@fichero \file{paths}|)}
\index{pathalias@\prog{pathalias}|)}
\index{fichero paths@fichero \file{paths}|)}

% \section{Message Grading}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% % Message grades in UUCP and on the Internet                    %
% % The meaning of the precedence field.                          %
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{mail.grades}
% To distinguish between important and less important mail, it is
% possible to assign a \emph{grade} to the message. The mail
% transport software may (or may not) evaluate this information,
% and probably use different transports depending on its value. For example,
% very urgent mail might be forwarded immediately, while ordinary
% mail is queued until the next regular contact is established. Also,
% treatment in case of an error may vary: normally, an undeliverable
% message will ``bounce'' and be returned to the sender in its entirety.
% Junk mail, on the other hand, could be thrown away without notice.
% 
% 
% Normally, the message grade is a special token extracted from 
% the \mhdr{Precedence:} header field.
% If it doesn't exist, or contains an unknown token, the mailer will
% assume a default grade.
% 
% 
% The tokens most widely used (because \prog{sendmail} understands them)
% are, in decreasing order: \keyword{special-delivery}, \keyword{first-class},
% and \keyword{junk}. Other mailers, like \prog{smail}, add more tokens, and
% even allow you define your own set of tokens. It is also up to
% the administrator's whim what treatment she assigns to these
% tokens. She may even decide to give all of them equal precedence.
% For \prog{smail}, this will be explained in section~\ref{smail.grades}
% in chapter~\ref{smail}.




\section{Configuraci\'on de \prog{elm}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.elm}
\index{configuraci\'on!elm@\prog{elm}|(}
\index{elm@\prog{elm}|(}

\prog{elm} significa ``electronic mail'' (correo electr{\'o}nico) y es una
de las utilidades \unix{} m{\'a}s razonablemente bautizadas. Proporciona
una interface de pantalla completa con una buena utilidad de ayuda.
No vamos a explicar aqu{\'\i} como se usa \prog{elm}, s{\'o}lo nos detendremos
en sus opciones de configuraci{\'o}n.


Te{\'o}ricamente, se puede usar \prog{elm} sin configurar, y todo funciona
bien~--- con suerte. Pero hay algunas opciones que deben definirse, aunque
s\'olo se necesitan en contadas ocasiones.


Cuando comienza, \prog{elm} lee un conjunto de variables de configuraci{\'o}n
desde el fichero \file{elm.rc} en \elmlib. Entonces, intentar{\'a} leer
el fichero \file{.elm/elmrc} en nuestro directorio personal. Normalmente
este fichero no se genera a mano. Se crea cuando se escoge ``{\it save
options}'' (grabar opciones) desde el men{\'u} de opciones de \prog{elm}. 


El conjunto de opciones para el fichero privado \file{elmrc} tambi{\'e}n
est{\'a} disponible en el fichero global \file{elm.rc}. La mayor{\'\i}a de
las definiciones en el fichero privado \file{elmrc} sustituir{\'a}n a las
del fichero global.


\subsection{Opciones Globales de \prog{elm}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.elm.global}

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


\begin{tscreen}
\begin{verbatim}
#
# El nombre del nodo local
hostname = vlager
#
# Nombre del dominio
hostdomain = .vbrew.com
#
# Nombre de dominio totalmente cualificado (FQDN)
hostfullname = vlager.vbrew.com
\end{verbatim}
\end{tscreen}


Estas opciones definen la idea que tiene \prog{elm} sobre el nombre de
la m{\'a}quina local. Aunque esta informaci{\'o}n se usa raramente, debemos
definir estas opciones. Obs{\'e}rvese que estas opciones s\'olo tienen efecto
cuando se dan en el fichero global de configuraci{\'o}n; cuando se encuentran
en nuestro \file{elmrc} privado, ser{\'a}n ignoradas.


\subsection{Conjuntos de Caracteres Nacionales}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{mail.elm.charsets}
\index{elm@\prog{elm}!conjuntos de caracteres nacinales}
\index{internacionalizaci{\'o}n para \prog{elm}}
\index{conjuntos de caracteres nacionales en \prog{elm}}
\index{conjuntos de caracteres en \prog{elm}}
\index{ISO-8859-1}
\index{Latin-1, conjunto de caracteres}

Recientemente, han habido propuestas para corregir el est{\'a}ndar RFC~822
para soportar varios tipos de mensajes, como texto simple, datos binarios,
ficheros Postscript, etc. El conjunto de est{\'a}ndares y RFCs que cubren estos
aspectos se suelen conocer como MIME, o Extensiones de Correo
Internet Multiprop{\'o}sito (Multipurpose Internet Mail Extensions).
Entre otras cosas, esto permite al destinatario saber si un conjunto de 
caracteres distinto del est{\'a}ndar ASCII ha sido usado al escribir el mensaje,
por ejemplo usando los acentos o di\'eresis del castellano. Esto tiene
soporte en \prog{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{\'a}ndar que cumple. Tambi{\'e}n se conoce como Latin-1. Cualquier mensaje que
use caracteres de ese conjunto debe llevar la siguiente l{\'\i}nea en su
encabezado:


\begin{tscreen}
Content-Type: text/plain; charset=iso-8859-1
\end{tscreen}


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 \keyword{text/plain} (texto simple) es un valor de \keyword{charset}
(conjunto de caracteres) de \keyword{us-ascii}.


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


\index{metamail@\prog{metamail}}
Como el conjunto de caracteres nativo de \linux{} es ISO-8859-1,
llamar a \prog{metamail} no es necesario para mostrar mensajes que usen
dicho conjunto. Si se le dice a \prog{elm} que la pantalla entiende
ISO-8859-1, no usar{\'a} \prog{metamail} sino que mostrar{\'a} el mensaje
directamente. Esto se puede hacer definiendo la siguiente opci{\'o}n 
en el \file{elm.rc} global:


\begin{tscreen}
displaycharset = iso-8859-1
\end{tscreen}


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


De todos modos, definir esta opci{\'o}n en \file{elm.rc} no es suficiente.
El problema es que cuando muestra los mensajes con el paginador incorporado,
\prog{elm} llama a una funci{\'o}n de biblioteca por cada car{\'a}cter para 
determinar si es mostrable o no. Por defecto, esta funci{\'o}n s\'olo reconoce
caracteres ASCII como mostrables, y muestra todos los dem{\'a}s como
``\term{\car ?}''. Debemos solucionar esto definiendo la variable de 
entorno \keyword{LC\_CTYPE} como \keyword{ISO-8859-1}, que le indica
a la biblioteca que acepte caracteres Latin-1 como mostrables.
El soporte para esta y otras caracter{\'\i}sticas est\'a disponible
a partir de la \file{libc-4.5.8}.


Cuando enviamos mensajes que contienen caracteres especiales del
ISO-8859-1, debemos asegurarnos de definir dos variables m{\'a}s en el
fichero \file{elm.rc}:


\begin{tscreen}
charset = iso-8859-1	\\
textencoding = 8bit
\end{tscreen}


Esto hace que \prog{elm} defina el conjunto de caracteres como ISO-8859-1 en
el encabezado de correo, y lo env{\'\i}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{\'e}n en el
fichero \file{elmrc} privado en lugar de en el global.


\index{elm@\prog{elm}|)}
\index{configurando!elm@\prog{elm}|)}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                             %%
%%              E N D   O F   C H A P T E R                    %%
%%                                                             %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
