Este capítulo es una breve introducción a la forma de configurar smail y, además, dará una idea general de la funcionalidad que este programa provee. Aunque smail es muy similar en comportamiento a sendmail, sus archivos de configuración son totalmente diferentes.

El archivo de configuración principal es /usr/lib/smail/config. Este archivo es el que se debe editar para ajustar los valores específicos al sistema que se está configurando. Si únicamente es un ordenador terminal de UUCP, serán relativamente pocas las opciones a cambiar. Hay además otros archivos que configuran las opciones de encaminamiento y transporte que se pueden modificar; se hablará brevemente sobre la forma de hacerlo.

La forma de operación normal de smail hace que procese y entregue todo el correo de entrada inmediatamente. Si se tiene un tráfico relativamente alto, se puede preferir que smail guarde todos los mensajes en una cola, y los procese a intervalos regulares.

Cuando se trabaja con correo dentro de una red TCP/IP, es frecuente que smail funcione como demonio: en el momento de arrancar la máquina, se invoca desde el archivo rc.inet2, y se coloca en segundo plano, desde donde espera que haya una conexión TCP que entre por el puerto SMTP (el puerto 25 es lo normal). Este esquema es muy bueno cuando se espera una gran cantidad de tráfico, pues smail no se lanza por separado para cada conexión que ingresa. La alternativa es usar a inetd como el administrador del puerto SMTP, y lanzar una copia de smail cada vez que haya una conexión en este puerto.

El programa smail tiene muchas opciones que se usan para controlar su comportamiento; describirlas una por una en detalle no es de gran utilidad. Afortunadamente smail tiene varios modos estándar de operación que se habilitan cuando es invocado con un nombre especifico tal como rmail o smtpd. Es común que estos nombres específicos sean enlaces simbólicos al binario de smail. Se verán mas de éstos cuando se discutan algunas otras características de smail.

Hay dos enlaces a smail que deben existir siempre: /usr/bin/rmail y /usr/sbin/sendmail.1

Cuando se crea y se envía un mensaje de correo con un agente de usuario tal como elm, el mensaje se pasara a rmail para su entrega, con la lista de destinatarios dada en la línea de comandos. Lo mismo sucede con el correo que entra vía UUCP. Algunas versiones de rmail, sin embargo, invocan a /usr/sbin/sendmail en vez de a rmail, por lo que son necesarios ambos enlaces. Por ejemplo, si smail esta en /usr/local/bin, se debe escribir lo siguiente en la línea de comandos:

Si se quiere investigar mas sobre los detalles de configuración de smail, se debe buscar en las páginas del manual smail(1) y smail(5). Si no estuviesen incluidas en su distribución preferida del Linux, se pueden obtener junto con el código fuente de smail.

Para usar smail en un entorno que solo tiene UUCP, la instalación básica es muy sencilla. Primero se debe asegurar de que estén los dos enlaces simbólicos a rmail y sendmail mencionados anteriormente. Si se espera recibir conexiones de SMTP de otros sitios, también se debe hacer un enlace de rsmtp a smail.

En la distribución de smail de Vince Skahan, se encuentra un archivo muestra de configuración. Su nombre es config.sample y esta en /usr/lib/smail. Se debe copiar a config y editarlo para ajustar los valores específicos de su sistema.

Suponiendo que su máquina se llama swim.twobirds.com, y esta registrado en los mapas UUCP como swim y su relevo UUCP es ulysses, entonces el archivo config podría ser como el siguiente:

_____________________________________________
1 Esta es la nueva ubicación estándar de sendmail de acuerdo con el Estándar del Sistema de Archivos de Linux. Otra ubicación común es /usr/lib.

La primera instrucción le indica a smail los dominios a los que su sistema pertenece. Se deben insertar sus nombres aquí, separados con signos de punto y coma. Si el nombre de su sistema esta registrado en los mapas de UUCP, será necesario agregar además la palabra uucp. Cuando se manipula un mensaje de correo, smail determina el nombre de su nodo usando una llamada de sistema hostname(2) y revisa la dirección del destinatario con respecto al nombre del nodo, revisando cada uno de los nombres de la lista. Si la dirección coincide con cualquiera de estos nombres, o el nombre del sistema no esta calificado, el receptor se considera local y smail intenta entregar el mensaje a un usuario o alias dentro del sistema local. En cualquier otro caso, el receptor se considera remoto y se intenta entregar al nodo adecuado.

La palabra clave visible_name debe contener un solo nombre de dominio totalmente calificado de la máquina que se desea utilizar para los mensajes que se envían hacia fuera. Este nombre se usa cuando se genera la dirección de quien envía el correo en todos los mensajes de salida. Es importante asegurarse de que el nombre que se use sea reconocido por smail como una referencia al sistema local (i.e. el nombre del ordenador con uno de los dominios listados en el atributo visible_domain). Si no se hiciese de esta forma, las respuestas a los mensajes enviados rebotaran hacia fuera del nodo local.

La última instrucción pone la ruta utilizada para el encaminamiento del relevo UUCP (descrito en la sección 13.4). Con este cambio mostrado, smail enviara cualquier correo dirigido hacia direcciones remotas al relevo. Como los mensajes serán entregados a través de UUCP, el atributo debe especificar un sistema conocido para los programas UUCP que corran en su sistema. Consulte el capítulo 12 sobre el tema de como hacer que su nodo sea conocido por UUCP.

Hay una opción que se utiliza en el archivo anterior que aun no ha sido explicada; ésta es uucp_name. La razón para utilizar esta opción es la siguiente: normalmente smail utiliza el valor que devuelve hostname(2) para cosas que hace el UUCP tales como poner en el encabezado From_ el camino de regreso del correo. Si el nombre del nodo no esta registrado en el mapa de UUCP, es necesario indicar a smail que en vez de éste utilice el nombre de dominio completamente calificado.2 Esto se puede hacer agregando la opción uucp_name al archivo de configuración config.

_____________________________________________
2 La razón de esto es: Suponga que el nombre de su sistema es monad y que no esta registrado en los mapas y además hay un lugar registrado en los mapas que se llama monad. Cada correo que se dirija a monad!root, aun cuando haya sido enviado desde un vecino directo UUCP, viajara hasta el otro monad. Esto es una molestia para todos.

Hay otro archivo en /usr/lib/smail, que se llama paths.sample. Este es un ejemplo de la forma que tiene un archivo de caminos, paths. Sin embargo, este archivo no es necesario a menos que se tengan enlaces de correo a mas de un lugar. Si fuese necesario hacerlo, se debe escribir uno nuevo o generar uno partiendo de los mapas de Usenet. El archivo paths se describirá mas adelante, en este mismo capítulo.

Si esta funcionando una instalación con dos o más nodos conectados por medio de una red local, es necesario designar a uno de ellos para que maneje la conexión UUCP con el mundo exterior. Entre las máquinas de la red local, es muy probable que se quiera intercambiar correo con SMTP sobre TCP/IP. Suponga que se tiene nuevamente el ejemplo de la Cervecera Virtual, y vstout se configura como una pasarela UUCP.

En un entorno de red, es preferible mantener todos los archivos con el correo de los usuarios en un solo sistema de archivos, que puede ser montado con NFS desde todas las demás máquinas. Esto permite a los usuarios desplazarse de máquina en máquina sin tener que mover su correo por todos lados (o peor, revisar tres o cuatro ordenadores para ver su correo recién recibido cada mañana). Así mismo, es deseable hacer que las direcciones de los usuarios sean independientes del ordenador en la cual el correo se almacena. Es una práctica común utilizar el nombre del dominio como la dirección de quien envía el correo en vez de utilizar el nombre de la máquina servidora del correo. El usuario Janet, por ejemplo, podría especificar su dirección como janet@vbrew.com en vez de janet@vale.vbrew.com. A continuación se explicara como hacer que el servidor reconozca el nombre del dominio como un nombre válido para su instalación.

Otra forma de mantener todos los apartados postales en un anfitrión central es utilizar POP o IMAP. POP quiere decir, por sus siglas en ingles Post Office Protocol, es decir, Protocolo de Oficina Postal y permite a los usuarios tener acceso a sus archivos de correo a través de una conexión TCP/IP. IMAP, o Protocolo de Acceso Interactivo al Correo por sus siglas en ingles de Interactive Mail Access Protocol, es similar a POP, excepto que es mas general. Ambos clientes y servidores para IMAP y POP han sido portados a Linux, y están disponibles en sunsite.unc.edu bajo el directorio /pub/Linux/system/Network.

La configuración para la Cervecera funciona de la siguiente forma: todos los nodos, con excepción del servidor de correo vstout, encaminan todo el correo que va hacia el exterior hacia este servidor, utilizando la técnica de encaminamiento al relevo de correo. vstout encamina todo el correo que va hacia el exterior al verdadero nodo de relevo que, a su vez, envía todo el correo de la Cervecera; este último nodo se llama moria.

El archivo estándar config para todas las máquinas con la excepción de vstout es como sigue:

Esto es muy parecido a lo que se ha hecho para configurar un sistema que solo funciona con UUCP. La diferencia principal es que el medio de transporte utilizado para enviar el correo al nodo de relevo es SMTP. El atributo visible_domain hace que smail utilice el nombre del dominio en vez de utilizar el nombre del sistema local en todo el correo de salida.

En la pasarela de correo UUCP vstout el archivo config es ligeramente distinto:

Este archivo de configuración, config, utiliza un esquema diferente para indicar a smail como se llama el sistema local. En vez de dar una lista de dominios y permitir que busque el nombre del nodo con una llamada al sistema, se especifica una lista explícitamente. La lista de arriba contiene tanto el dominio completamente calificado como el del sistema no calificado, y el nombre del dominio completo en sí mismo. Esto hace que smail reconozca a janet@vbrew.com como una dirección local, y entregue el mensaje a janet.

La variable auth_domains indica el nombre de los dominios para los cuales vstout es considerado como autoridad. Esto es, si smail recibe cualquier correo con una dirección hacia host .vbrew.com en donde host no corresponde a ninguna máquina existente, se rechaza el mensaje y se devuelve al remitente del mismo. Si esta línea no esta, cualquier mensaje rechazado será enviado nuevamente al relevo de correo, quien lo mandara a vstout, y así sucesivamente hasta que se descarte por exceder la cuenta máxima de saltos.

La primera cosa que se debe hacer es decidir si se ejecutara smail como un demonio independiente, o si se permitirá que inetd administre el puerto SMTP e invoque a smail cuando un cliente solicite una conexión SMTP. Normalmente es preferible la operación como un demonio independiente en el servidor de correo, debido a que esto carga la computadora menos que lanzar una copia nueva de smail cada vez que se solicite una conexión individual. Cuando un servidor de correo entrega casi todo el correo que recibe directamente a los usuarios, es preferible optar por la operación con inetd.

Independientemente del modo de operación que se haya elegido para cada anfitrión individual, es importante asegurarse que se tiene la siguiente línea en el archivo /etc/services:

Esto define el número del puerto TCP que smail utilizará para las conexiones SMTP. 25 es el puerto estándar definido por el RFC de Números de Puerto Asignados.

Cuando se ejecuta como demonio, smail se coloca a sí mismo en segundo plano, y esperará a que ocurra una conexión en el puerto SMTP. Cuando haya una conexión, lanza un proceso y conduce una conversación SMTP en dicho puerto. El demonio smail se lanza normalmente invocándolo desde el script rc.inet2 con la siguiente instrucción:

El modificador -bd indica que se funcionara como demonio, y -q15m hace que se procesen los mensajes acumulados en la cola cada 15 minutos.

Si en cambio, se quiere utilizar inetd, el archivo /etc/inetd.conf deberá contener una línea como la siguiente:

smtpd debe ser un enlace simbólico al binario de smail. Recuerde que tiene que forzar a que inetd relea inetd.conf enviándole una señal HUP después de hacer estos cambios.

El modo demonio y el modo inetd son mutuamente excluyentes. Si se ejecuta smail como demonio, asegúrese de que este comentada cualquier línea en inetd.conf para el servicio smtp. De manera similar, cuando se tenga a inetd como administrador de smail, asegúrese de que rc.inet2 no lanza al demonio smail.

Si algo va mal con la instalación, hay algunas herramientas que pueden ayudar a encontrar cual es la raíz del problema. El primer lugar que se debe revisar es el conjunto de archivos de registro de smail. Están en /var/spool/smail /log, y se llaman logfile y paniclog, respectivamente. El primero lista todas las transacciones, mientras que el último solo se usa cuando haya mensajes de error relacionados con errores en la configuración y similares.

Un ejemplo típico de una línea en el logfile es el siguiente:

Esto muestra que un mensaje de root a root@vstout.vbrew.com ha sido correctamente entregado al sistema vstout a través de SMTP.

Los mensajes que smail no pudo entregar generan una línea similar en el archivo de registro, pero con el mensaje de error en vez de la parte que dice entregado (delivered):

El error de arriba es típico para una situación en la cual smail reconoce correctamente que el mensaje debería ser entregado a vstout pero que no fue posible establecer la conexión al servicio SMTP en vstout. Si esto sucede, es posible que tenga un problema de configuración o bien que el soporte TCP este ausente de los binarios del smail.

Este problema no es tan raro de encontrar. Hay varios binarios de smail que vienen con distribuciones de Linux y que no tienen soporte de red TCP/IP. Si este es su caso, debe recompilar el programa smail. Una vez instalado smail, se debe revisar si se tiene soporte de red TCP haciendo un telnet al puerto SMTP de su máquina. Una conexión exitosa al servidor SMTP se muestra a continuación (la entrada por teclado se marca con este tipo de letra):

Si esta prueba no produce el mensaje de SMTP (la línea que comienza con el código 220), debe asegurarse de que su configuración es verdaderamente correcta antes de recompilar smail, como se describirá a continuación.

Si hay algún problema con smail que no se pueda localizar con el mensaje de error que smail genera, se pueden activar los mensajes de depuración. Para hacer esto, se debe utilizar el modificador -d, seguido de un numero opcional que especifique el nivel de detalle de la información (no se debe dejar ningún espacio entre el modificador y el argumento numérico).

Entonces, smail mostrará un informe de su operación en la pantalla que dará mas pistas acerca de lo que puede estar mal.

Si esta seguro de que su smail carece de soporte de red TCP, es necesario obtener el código fuente. Es posible que ya este incluido en su distribución si la obtuvo en CD-ROM, si no fuese así, se puede conseguir en la red via FTP.3

La mejor forma de compilar smail, es comenzar con el conjunto de archivos de configuración de la distribución de Vince Skahan. Para incluir el controlador de TCP dentro de la compilación, se debe poner la macro DRIVER_CONFIGURATION en el archivo conf/EDITME con el parámetro bsd-network o arpa-network. El primero se utiliza para las instalaciones de red local, pero cuando se está en Internet es necesario usar arpa-network.

La diferencia entre estas dos es que la segunda tiene un manejador especial para el servicio BIND que permite reconocer registros MX, lo cual la primera no puede hacer.

Como se menciono anteriormente, smail es capaz de entregar los mensajes inmediatamente o encolarlos para un proceso posterior. Si se decide encolar los mensajes, smail guardara todo el correo en el directorio messages debajo de /var/spool/smail. No se procesaran hasta que se le indique explícitamente que lo haga (a este proceso se le conoce como "ejecutar la cola").

Se puede seleccionar uno de tres modos de entrega definiendo el atributo delivery_mode en el archivo config para que este como foreground, background, o queued. Es decir, proceso normal, proceso en segundo plano, o proceso en cola. Estas opciones seleccionan la entrega normal (procesamiento inmediato de los mensajes de entrada), en segundo plano (los mensajes son entregados por medio de un hijo del proceso receptor: el proceso padre muere inmediatamente después de la creación del hijo), y el encolado. El correo de entrada siempre será encolado independientemente de esta opción si la variable booleana queue_only esta puesta en el archivo config.

Si se activa el modo de cola, se debe asegurar de que las colas se revisen regularmente; probablemente cada 10 o 15 minutos. Si se ejecuta smail como demonio, se debe agregar la opción -q10m en la línea de comandos para procesar la cola cada 10 minutos. De forma alternativa, se puede invocar runq desde el cron en esos intervalos de tiempo. runq deberá ser un enlace a smail.

Se puede revisar la cola del correo al invocar smail con la opción -bp. De manera equivalente, se puede hacer que mailq sea un enlace a smail, e invocar mailq:

_____________________________________________
3 Si compro una distribución Linux a un proveedor comercial, se puede solicitar el código fuente con "un cargo de envío nominal" (que solo cubra los gastos), de acuerdo con las condiciones de copia de smail.

Esto muestra un solo mensaje que esta esperando en la cola de mensajes. El registro de transacciones (que solo se mostrará si se da a mailq la opción -v) puede dar una explicación adicional de por que el mensaje esta esperando para su entrega. Si aun no se ha intentado entregar el mensaje, no se mostrará la información del registro.

Aun cuando no se utilice el modo de cola, smail pondrá de forma ocasional los mensajes en la cola cuando falle la entrega inmediata por una razón transitoria. Para las conexiones SMTP, esto puede ser debido a que el nodo siguiente sea un inalcanzable; pero los mensajes pueden también ser pospuestos cuando el sistema de archivos del receptor este lleno. En cualquier caso, debe poner una cola que se revise, por ejemplo, cada hora (utilizando runq), porque si no, cualquier mensaje pospuesto se quedara encolado indefinidamente.

Hay otras muchas opciones en el archivo config, algunas poco usadas en sistemas sencillos. Sin embargo, mencionaremos algunas que sí que serán útiles con frecuencia:

error_copy_postmaster
Si esta variable booleana se pone, cualquier error generará un mensaje al administrador de correo. Normalmente esto solo se hace para los errores que se deben a una configuración incorrecta. La variable puede activarse poniéndola en el archivo config, precedida por un signo de suma (+).

max_hop_count
Si la cuenta de saltos para un mensaje (i.e. el número de nodos que se han atravesado) es igual o excede a este numero, los intentos de entrega producirán un mensaje de error que será enviado a quien genero el mensaje. Esto se utiliza para prevenir que los mensajes entren en un ciclo infinito. La cuenta de saltos se calcula generalmente a partir del numero de campos
Received: que se encuentran en el encabezado del correo. Además, esta cuenta también puede ser ajustada de forma manual utilizando la opción -h en la línea de comandos. Esta variable tiene como valor por defecto 20.

postmaster
La dirección del administrador de correo. Si la dirección Postmaster no puede ser resuelta como dirección local valida, entonces ésta se utiliza como último recurso. El valor por defecto es root.

smail divide la entrega del correo en tres partes, la ruta, el módulo de entrega local y el módulo de transporte.

El módulo de encaminamiento resuelve todas las direcciones remotas, determinando el nodo al que el mensaje será enviado y el transporte que será utilizado. Dependiendo de la naturaleza del enlace, se utilizarán transportes diferentes tales como UUCP o SMTP.

Las direcciones locales se dan al módulo de entrega local que resuelve cualquier reenvío o alias. Por ejemplo, la dirección podría ser un alias o una lista de correo, o el usuario podría querer reenviar su correo a otra dirección. Si la dirección resultante es remota, se maneja de nuevo en el módulo de encaminamiento, de otra forma se asigna a un transporte para su entrega local. Normalmente, la acción a realizar será entregar a un archivo de correo, pero los mensajes también pueden ser pasados a la entrada de un comando (por ejemplo, un filtro de correo que el usuario quiera establecer) o agregados a un archivo arbitrario cualquiera.

El módulo de transporte, finalmente, es el responsable de la entrega, independientemente del método que se haya escogido. Intenta entregar el mensaje y en caso de problemas, puede devolver un mensaje al remitente o posponer la entrega para intentarlo de nuevo más tarde.

Con smail se tiene mucha flexibilidad para configurar estas tareas. Para cada una de ellas, hay varios controladores4 disponibles, de los cuales se puede elegir el más adecuado.

Se debe indicar a smail la elección a través de los siguientes archivos: routers, directors y transports, que se encuentran en /usr/lib/smail. Si estos archivos no existiesen, se toman valores por defecto razonables que funcionan en la mayor parte de los sistemas que utilizan SMTP o UUCP como transporte. Si se quiere cambiar la política de encaminamiento de smail, o modificar un transporte, es conveniente obtener los archivos ejemplo que vienen con la distribución de los programas fuente de smail 5, copiar los archivos ejemplo a /usr/lib/smail, y modificarlos de acuerdo con sus necesidades. Los archivos de ejemplos de configuración están también en el Apéndice B.

_____________________________________________
4 Aquí, conocemos por controladores a los distintos módulos internos de smail capaces de utilizar un método de entrega de mensajes u otro. Así, tenemos controladores para UUCP o para SMTP 5 Los archivos de configuración por defecto se encuentran en samples/generic bajo el subdirectorio de los programas fuente.

Cuando se le da un mensaje, smail revisa primero si el destino está en el sistema local o en un nodo remoto. Si la dirección del ordenador destino corresponde a uno de los nodos locales configurados en el archivo config, el mensaje es tratado por el módulo de entrega local. Si no fuese así, smail transmite la dirección del destino a varios controladores de encaminado para encontrar a que máquina se debe transmitir el mensaje. Los controladores se pueden indicar en el archivo routers; si este archivo no existe, se utiliza un conjunto de encaminadores por defecto.

El nodo destino se pasa a todos los encaminadores por turno, y aquel que encuentra la ruta mas especifica es seleccionado. Por ejemplo, suponga que hay un mensaje dirigido a joe@foo.bar.com y que un encaminador conoce una ruta para todos los nodos que pertenecen al dominio bar.com, mientras que otro tiene la información sobre el camino directo al sistema foo.bar.com. Como el segundo es más especifico, es elegido sobre el primero. Si hubiese dos encaminadores que proveen una solución correcta e igual de especifica, se elige al primero que este en el archivo routers.

A continuación, el encaminador elegido especifica que transporte utilizará, por ejemplo UUCP, y genera así una nueva dirección destino. La nueva dirección se pasa al transporte junto con el nombre del sistema a quien se le debe pasar el mensaje. En el ejemplo anterior, smail podría encontrar que foo.bar.com se puede encontrar via UUCP utilizando la trayectoria ernie!bert. Así generará un nuevo destino bert!foo.bar.com!user, y utilizará esta dirección, a través del transporte UUCP, como la que será transmitida a ernie.

Cuando se utilice la configuración por defecto, los siguientes encaminadores estarán disponibles:

o Si la dirección del nodo destino se puede resolver utilizando las llamadas de biblioteca gethostbyname(3) o gethostbyaddr(3), el mensaje será entregado via SMTP. La única excepción es si la dirección que se encuentra se refiere al sistema local, en cuyo caso será enviado al módulo de entrega local.

smail también reconoce las direcciones IP escritas como cuarteto de puntos como nombre legal de máquina, siempre y cuando pueda ser resuelto a través de una llamada a gethostbyaddr(3). Por ejemplo scrooge@[149.76.12.4] podría ser válida aunque muy rara como dirección para scrooge en quark.physics.groucho.edu.

Si su máquina esta en Internet, estos encaminadores no son lo que usted necesita, debido a que no soportan registros MX. Vea mas adelante lo que se debe hacer en este caso.

Los valores por defecto funcionan para la mayor parte de las instalaciones sencillas, pero no son útiles si las necesidades de encaminamiento son algo más complejas. Si se enfrenta con uno de los problemas que se discutirán a continuación, es necesario instalar su propio archivo routers para cambiar los valores por defecto. Un archivo ejemplo routers con el que se puede empezar esta en el apéndice B. Algunas distribuciones de Linux traen además, un conjunto de archivos de configuración hechos a la medida para solventar esas dificultades.

Es probable que el peor de los problemas surja cuando su máquina viva en un universo dual con enlaces de marcado telefónico via IP y UUCP. Entonces se tendrán nombres de nodos en el archivo hosts con los cuales solo se comunica ocasionalmente a través de un enlace SLIP, y smail intentara entregar cualquier correo por medio de estos sistemas usando SMTP. Este comportamiento no es deseable normalmente debido a que, si el enlace SLIP se activa de forma regular, SMTP es mucho más lento que mandar el correo con UUCP.

Con los valores por defecto, no se puede evitar que smail se porte mal.

Este problema se puede evitar revisando con smail el archivo paths antes de preguntar por el sistema de resolución, y poner a todos los nodos a los que se quiera forzar la entrega via UUCP en el archivo paths. Si nunca se quiere enviar ningún mensaje sobre SMTP, se pueden eliminar poniendo como comentarios todos los encaminadores que están basados en el sistema de resolución.

Otro problema es que las opciones por defecto no proporcionan encaminado de correo Internet verdadero, debido a que un encaminador basado en un DNS no evalúa los registros MX. Para habilitar el soporte completo para el encaminamiento de correo Internet, es necesario eliminar al encaminador poniéndolo como comentario, y quitar el comentario de aquel que utiliza BIND. Sin embargo, algunas distribuciones de Linux incluyen binarios de smail que no tienen el soporte para BIND incluido y, si se habilita BIND, se obtendrá un mensaje en el archivo paniclog que dice "router inet_hosts: driver bind not found", es decir, "no se encuentra el controlador de bind", por lo que será necesario obtener el código fuente y recompilar smail (vea la sección 14.2 mas arriba).

Para concluir, generalmente no es buena idea utilizar el controlador uuname. Por una parte, generará un error de configuración cuando no se tenga UUCP instalado, debido a que no encontrará al programa uuname. Por la otra, es que se tienen mas sistemas listados en su archivo Systems de UUCP que aquellos con los que se mantiene correo. Estos pueden ser nodos con los cuales únicamente se intercambian noticias, o sistemas de los cuales se bajan archivos ocasionalmente via UUCP anónimo, pero no se tiene mas tráfico que éste.

Para resolver el primer problema, se puede sustituir el programa uuname con un script que haga un simple exit 0. La solución mas general es, sin embargo, editar el archivo routers y borrar todo el driver.

El programa smail espera encontrar una base de datos de alias de trayectorias en el archivo paths en el subdirectorio /usr/lib/smail. Este archivo es opcional, por lo que si no se quiere hacer ningún encaminamiento por medio de alias de trayectorias, simplemente se borra el archivo paths.

El archivo paths debe ser un archivo ASCII ordenado que contiene líneas que mapeen los nombres de los nodos destino a trayectorias UUCP con signos de admiración. El archivo tiene que estar ordenado debido a que smail utiliza búsqueda binaria para encontrar un sitio.

No se permiten comentarios en este archivo, y el nombre del sitio debe estar separado de la trayectoria utilizando un carácter de tabulación. Las bases de datos de alias de trayectorias se discuten con mas detalle en el capítulo 13.

Si se genera este archivo a mano, es importante asegurarse de incluir todos los nombres validos para un sistema. Por ejemplo, si a una máquina se le conoce por un nombre simple UUCP y un nombre de dominio totalmente calificado, se debe añadir una línea para cada uno de ellos. El archivo debe estar ordenado (para ello, enviarlo al comando sort(1)).

Si su nodo es simplemente terminal, no será necesario tener un archivo paths: basta con ajustar los atributos de nodo de relevo en su archivo config, y dejarle todo el trabajo de encaminamiento que su correo genere.

Es común que una dirección local de correo sea solo el nombre del usuario, en cuyo caso el mensaje se entrega en su archivo de correo, /var/spool/mail /usuario. En otros casos se incluyen alias y nombres de la lista de correo, y correo redirigido por el usuario. En estos casos, la dirección local se expande a una nueva lista de direcciones que pueden ser locales o remotas.

Independientemente de estas direcciones "normales", smail puede manejar otros tipos de destino para los mensajes locales tales como nombres de archivos o comandos (que reciben el mensaje por su entrada estándar). Estas no son propiamente direcciones, de tal forma que no se puede mandar correo, por ejemplo a /etc/passwd@vbrew.com; solo son válidas si se han tomado de un archivo alias o de redireccionamiento.

Un nombre de archivo es cualquier cosa que comience con una diagonal (/) o una tilde (~). El segundo se refiere al directorio inicial del usuario, y es posible solo si el nombre del archivo ha sido tomado de .forward o una línea de redirección del archivo de correo (ver mas abajo). Cuando smail manda el mensaje a un archivo, lo añade al final del archivo y, de ser necesario, lo puede también crear.

Una instrucción por tubería puede ser cualquier comando UNIX precedido por el simbolo (|). Esto hace que smail envíe el comando al shell junto con sus argumentos, pero sin el '|' que lo encabeza; pasando el mensaje a la entrada estándar del comando.

Por ejemplo, para meter una lista de correo en un grupo de noticias local, se podría utilizar un script llamado gateit y configurar un alias local que entregue todos los mensajes de esta lista de correo al script, utilizando "_gateit".

Si la invocación contiene un espacio en blanco, se debe encerrar entre comillas dobles.

Debido a los problemas de seguridad que pueden ser ocasionados aquí, es importante cuidar que no se ejecute el comando si la dirección ha sido obtenida de alguna forma dudosa (por ejemplo, si el archivo de alias del cual la dirección se ha obtenido puede ser escrito por cualquiera).

El caso mas común para una dirección local es mostrar el archivo de correo del usuario. Este apartado postal esta en /var/spool/mail y tiene el nombre del usuario. También es propiedad de éste, con grupo mail y tiene el modo 660. Si no existe, smail lo crea.

Observe que aunque /var/spool/mail es el lugar estándar para poner los archivos de correo, algunas aplicaciones tienen diferentes trayectorias compiladas en ellos, por ejemplo /usr/spool/mail. Si la entrega a los usuarios en su sistema falla constantemente, se puede intentar hacer un enlace simbólico a /var/spool/mail para ver si esta situación mejora.

Hay dos direcciones que smail necesita para funcionar: MAILER-DAEMON y Postmaster. Cuando se devuelve un mensaje de informe debido a un correo que no pudo ser entregado, se envía una copia a la cuenta del administrador postal (el postmaster) para su revisión (en el caso de que este mensaje pudiera ser debido a un problema de configuración).

El usuario MAILER-DAEMON se utiliza como la dirección del remitente del mensaje devuelto.

Si estas direcciones no tienen nombres de cuentas validas en su sistema, smail mapea implícitamente MAILER-DAEMON a postmaster, y postmaster a root. Es conveniente cambiar esto dándole un alias postmaster al responsable del mantenimiento de los programas de correo.

Un usuario puede redirigir su correo a una dirección alternativa utilizando uno de los dos métodos que soporta smail. Una opción es poner

en la primera línea de su archivo de correo. Esto enviará todo el correo que se reciba a la lista de receptores especificada allí. La otra es crear un archivo .forward en el directorio principal del usuario, que contenga una lista de los receptores separados por comas. Con este sistema de redireccionamiento, todas las líneas del archivo son leídas e interpretadas.

Observe que cualquier tipo de dirección puede ser utilizada. Así, un ejemplo práctico del archivo .forward para cuando se tome unas vacaciones puede ser  

La primera dirección entrega el mensaje que llega al archivo de correo de janet, mientras que la instrucción vacation provoca la devolución de un mensaje que informa al remitente que janet esta de vacaciones.

El programa smail entiende los archivos de alias compatibles con los del sendmail de Berkeley. Las líneas en el archivo de alias pueden ser de la forma alias: receptores

receptores es una lista de direcciones separadas por comas que será sustituida por el alias. La lista de receptores puede continuar a través de varias líneas si la siguiente línea comienza con un carácter de tabulación.

Hay una característica especial que permite que smail maneje listas de correo desde un archivo de alias: si se especifica ":include:nombrearchivo " como receptor, smail leerá el archivo especificado, y sustituirá su contenido con una lista de receptores.

El archivo de alias principal es /usr/lib/aliases. Si se decide hacerlo escribible por todo el mundo, smail no entregara ningún mensaje a los comandos de shell que pudiese contener el archivo. Un archivo de ejemplo se muestra a continuación:

Si hay un error cuando se entrega a una dirección generada por el archivo aliases, smail intentara enviar una copia del mensaje de error al "dueño del alias". Por ejemplo, si la entrega a biff no se logra cuando se envío un mensaje a la lista de correo development, se enviara una copia del mensaje de error al remitente, así como también al postmaster y a owner-development. Si la dirección del dueño no existe, no se generará el mensaje de error adicional.

Cuando se entrega a un archivo o cuando se invocan programas en el archivo aliases, smail se convierte en el usuario nobody para evitar problemas de seguridad6. En especial cuando se entrega a un archivo esto constituye una verdadera molestia. En el archivo de ejemplo que se dio anteriormente, los archivos de registro .log deben ser propiedad y ser escribibles por el usuario nobody, o la entrega hacia ellos fallara.

_____________________________________________
6 N. del T.: nobody significa nadie, y es un usuario que se utiliza cuando no se identifica al dueño de un proceso, y si bien se desea su ejecución, también es cierto que no deseamos crear un agujero en nuestros mecanismos de seguridad, por lo cual nobody es un usuario con los privilegios reducidos al mínimo.

En vez de utilizar el archivo aliases, las listas de correo también pueden ser administradas por medio de archivos en el directorio /usr/lib/smail /lists. Una lista de correo llamada nagbugs se debe describir en el archivo lists/nag-bugs, el cual deberá contener las direcciones de los miembros separadas por comas. La lista puede estar en varias líneas, con líneas de comentarios que comienzan con el símbolo #.

Para cada lista de correo, un usuario (o alias) llamado owner-nombredelista debe existir; cualquier error que ocurra cuando se resuelva una dirección será enviado a este usuario. Esta dirección se usa también como la dirección del remitente en todos los mensajes de salida en el campo de encabezado Sender:.

Hay varios transportes compilados en smail que utilizan el conjunto de programas UUCP.

En un entorno UUCP, los mensajes se pasan normalmente al invocar rmail en el siguiente nodo, dándole el mensaje en la entrada estándar y la dirección a quien va dirigido en la línea de argumentos. En el sistema, rmail deberá ser un enlace al programa smail.

Cuando se maneja un mensaje con el transporte UUCP, smail convierte la dirección destino a una trayectoria UUCP con símbolos de admiración. Por ejemplo, user@host se transformara en host!user. Cualquier ocurrencia del operador de direcciones '%' será conservada, de tal forma que user%host@gateway se convertirá en gateway!user%host.

Sin embargo, mail nunca generará esa dirección por si mismo.

De manera alternativa, smail puede enviar y recibir lotes de BSMPT via UUCP. Con BSMTP, uno o mas mensajes son empaquetados en un solo lote que contiene las instrucciones para que el controlador del correo local funcione como si se hubiera establecido una conexión SMTP real. BSMTP se utiliza frecuentemente en redes de guardar-y-enviar (por ejemplo las basadas en UUCP) para ahorrar espacio en disco. El archivo de ejemplo transports del apéndice B contiene un transporte doblado bsmtp que genera lotes parciales BSMTP en un directorio de colas. Luego, deben ser combinados en los lotes finales utilizando un script de shell que agrega las instrucciones apropiadas HELO y QUIT.

Para habilitar el transporte bsmtp para enlaces UUCP específicos se deben utilizar los archivos llamados método (revise la página del manual smail(5) para mas detalles). Si se tiene únicamente un enlace UUCP, y se utiliza un encaminado a relevo, se puede habilitar el envío de lotes SMTP poniendo la variable de configuración smart_transport a bsmtp en vez de uux.

Para recibir lotes SMTP sobre UUCP, se debe asegurar que se tiene el mismo programa de decodificación de lotes que el sistema remoto que envía los lotes. Si el nodo remoto utiliza smail también, es necesario hacer un enlace llamado rsmtp a smail. Si el sistema remoto corre sendmail, se debe además instalar un script llamado /usr/bin/bsmtp que haga un simple "exec rsmtp" (una enlace simbólico no funcionara).

El smail soporta actualmente un controlador de SMTP para entregar el correo sobre conexiones TCP.7 Es capaz de entregar un mensaje a cualquier numero de direcciones de una máquina, con el nombre de la misma especificado como nombre de dominio totalmente calificado que puede ser resuelto por el software de red, o con la notación de cuarteto de puntos encerrados entre corchetes. En general, las direcciones se resuelven con los controladores de encaminamiento del BIND, gethostbyname(3), o gethostbyaddr(3) que lo entregaran al transporte SMTP.

El manejador de SMTP intentara conectarse al sistema remoto inmediatamente a través del puerto smtp como esta listado en /etc/services. Si no puede ser alcanzado, o expira el tiempo máximo de espera, la entrega del correo se reintentara posteriormente.

La entrega en Internet requiere que las rutas al nodo destino estén especificadas en el formato route-addr descrito en el capítulo 13, en vez de utilizar una trayectoria de signos de admiracion.8 smail transformara user%host@gateway, en donde gateway se alcanza via host1!host2!host3, en la dirección de la ruta-fuente <@host2,@host3:user%host@gateway> la cual será enviada como la dirección del remitente a host1. Para habilitar dicha transformación (utilizando el controlador incluido de BIND), se debe editar la línea del controlador smtp en el archivo transports. Un archivo de muestra transports se da en el Apéndice B.

Algunas veces se desean capturar los nombres de sistema no calificados (i.e. aquellos que no tienen un nombre de dominio) escritos en la dirección del remitente o del receptor, por ejemplo cuando se pasa a través de dos redes, en donde una requiere de nombres de dominio totalmente calificados. En un relevo Internet-UUCP, los nombres de nodo no calificados deben ser mapeados al dominio uucp por defecto. Cualquier otro cambio de dirección distinto a los anteriores son cuestionables.

_____________________________________________
7 Los autores llaman a este soporte "simple". Para una versión futura de smail, han anunciado un mecanismo completo que manejará ésto de manera más eficiente.
8 Sin embargo, el uso de rutas en Internet se desaconseja totalmente. En cambio, se deben utilizar nombres de dominio totalmente calificados.

El archivo /usr/lib/smail /qualify indica a smail que nombres de dominios debe cambiar a que nombres de nodo. Las líneas del archivo qualify consisten en el nombre del sistema comenzando en la columna uno, seguidos del nombre del dominio. Las líneas conteniendo un símbolo # como su primer carácter no blanco se consideran comentarios. Las líneas se buscan en el orden en el que aparecen.

Si no existe el archivo qualify, no se hace ninguna calificación de nombres de nodos.

Un nombre de anfitrión especial (*) indica que todos son nombres de nodos. Así, se puede habilitar un mapeo a todos los sistemas no mencionados antes en un dominio por defecto. Debe ser utilizado solo en la última línea.

En la Cervecera Virtual, todos los sistemas han sido configurados para utilizar nombres de dominio totalmente calificados en las direcciones de los remitentes. Las direcciones de los receptores no calificadas se considera que están en el dominio uucp, de tal forma que solo una línea en el archivo qualify es necesaria.