Vince Skahan (vince@victrola.wa.com) ha estado administrando un gran número de sistemas Unix desde 1987, y actualmente hace funcionar sendmail+IDA en aproximadamente 300 estaciones de trabajo Unix para unos 2000 usuarios.

Admite haber perdido considerablemente el sueño editando unos cuantos ficheros sendmail.cf "por la fuerza bruta" antes de descubrir sendmail+IDA en 1990. Admite asimismo que aguarda ansiosamente la llegada de la primera versión en Perl de sendmail, para todavía mayor disfrute.

Gracias a Neil Rickert y Paul Pomes por la gran cantidad de ayuda proporcionada a lo largo de los años en lo que se refiere al cuidado y mantenimiento de sendmail+IDA y a Rich Braun por hacer el porte inicial a Linux. Las mayores gracias son de lejos para mi mujer Susan, por todo el apoyo en este y otros proyectos.

Se dice que no se es un verdadero administrador de sistemas Unix hasta que se haya editado el archivo sendmail.cf. Se dice asimismo que se está loco si se intenta hacer dos veces.

Sendmail es un programa increíblemente potente. Y también, para la mayoría de la gente, increíblemente difícil de aprender y comprender. Un programa cuyo manual de referencia definitiva ocupa 792 páginas es suficiente para espantar justificadamente a cualquiera. (Sendmail, editado por O'Reilly and Associates)

Con sendmail+IDA es distinto. Se elimina la necesidad de editar el siempre críptico archivo sendmail.cf, permitiendo al administrador definir la configuración de las rutas y direcciones particulares de una máquina especifica, por medio de archivos de apoyo relativamente sencillos de entender, llamados tables. Cambiar a sendmail+IDA puede ahorrarle muchas horas de trabajo y estrés.

En comparación con los demás agentes principales de transporte de correo, es probable que no haya nada que no se pueda hacer más rápida y fácilmente que con sendmail+IDA.

Las actividades más comunes, necesarias para hacer funcionar sistemas Internet o UUCP usuales, pasan a ser tareas fáciles de llevar a cabo.

Configuraciones que normalmente serian extremadamente difíciles, son ahora simples de crear y mantener.

Cuando se escribió este manual, la versión actual de sendmail5.67b+IDA1.5 estaba disponible por FTP anónimo en vixen.cso.uiuc.edu. Esta versión compila sin parches ni modificaciones bajo Linux.

Todos los archivos de configuración necesarios para poder compilar, instalar y hacer funcionar los fuentes de sendmail+IDA bajo Linux se hallan en el archivo newspak-2.2.tar.gz, disponible por FTP anónimo en sunsite.unc.edu, en el directorio /pub/Linux/system/Mail.

El sendmail tradicional se configura a través de un archivo de configuración de sistema (típicamente /etc/sendmail.cf o /usr/lib/sendmail.cf), que no se asemeja ni de lejos a cualquier otro lenguaje que haya podido ver antes. Editar el archivo sendmail.cf para proporcionar un comportamiento personalizado puede ser una experiencia humillante.

Sendmail+IDA hace que este suplicio sea algo del pasado, siendo todas las opciones de configuración controladas por ficheros con formato de listados (tables), con una sintaxis bastante fácil de comprender. Estas opciones son configuradas mediante el procesado de ciertos archivos de información, que son proporcionados con los fuentes, vía "Makefiles" que invocan a m4 (analizador de macros) o dbm (procesador de bases de datos).

El archivo sendmail.cf define únicamente el comportamiento por omisión del sistema. Virtualmente, todos los ajustes especiales se hacen a través de un número de tablas opcionales en vez de editar directamente el archivo sendmail.cf. La figura 15.1 muestra todas las tablas que utiliza sendmail.

Figura 15.1: Archivos de apoyo de sendmail.

El archivo sendmail.cf que utiliza sendmail+IDA no se edita directamente, sino que se genera desde un archivo de configuración m4 proporcionado por el administrador del sistema local. De aquí en adelante, siempre nos referiremos a él simplemente como sendmail.m4.

Este archivo contiene algunas definiciones y en otros casos simplemente apunta a las tablas en donde se lleva realmente a cabo el trabajo. En general, solo es necesario especificar:

o las trayectorias y nombres de archivos utilizados en el sistema local.
o el o los nombres de los sistemas conocidos para propósitos e-mail.
o cual será el gestor de correo por defecto deseado (y quizá también algún nodo inteligente de reenvío 1 de correo).

Hay una gran variedad de parámetros que pueden ser definidos para establecer el comportamiento del sistema local o para ir más allá del comportamiento precompilado. Estas opciones de configuración se identifican en el archivo ida/cf/OPTIONS del directorio fuente.

Un archivo sendmail.m4 para una configuración mínima (UUCP o SMTP confiando todo el correo externo a anfitriones inteligentes conectados directamente) puede ser tan escueto como 10 o 15 líneas de texto excluyendo los comentarios.

_____________________________________________
1 N. del T.: estos nodos se conocen también como relevos, del inglés relay

A continuación se muestra un ejemplo del archivo sendmail.m4 para vstout en la Cervecera Virtual. vstout utiliza SMTP para hablar con todos los anfitriones de la red local de la Cervecera, y envía todo el correo para otros destinos a moria, su nodo de reenvío de Internet, vía UUCP.

Algunas partes del archivo sendmail.m4 son necesarias siempre; otras pueden ser ignoradas si se acepta la configuración por defecto. Las siguientes secciones describirán cada una de las partes del archivo ejemplo sendmail.m4 con mas detalle.

Partes que definen los directorios

LIBDIR define el directorio en donde sendmail+IDA espera encontrar los archivos de configuración, las diversas tablas dbm, y definiciones especiales de índole local. En una típica distribución ejecutable, esto esta ya compilado en el ejecutable de sendmail y no es necesario ponerlo explícitamente en el archivo sendmail.m4.

El ejemplo anterior tiene una línea inicial dnl que significa que esta línea es única y esencialmente un comentario informativo.

Para modificar la localización de los archivos de soporte a un lugar distinto, elimine el dnl inicial de la línea superior, y ajuste el directorio deseado, luego recompile y reinstale el archivo sendmail.cf.

Como definir un sistema de correo local (mailer)

Figura 15.2: Un archivo muestra de sendmail.m4 para vstout.

La mayor parte de los sistemas operativos tienen un programa encargado de la gestión de correo local. Los programas mas comunes para la mayor parte de las variantes de Unix están ya compiladas en el ejecutable de sendmail.

En Linux, es necesario definir explícitamente el gestor local de correo correspondiente, ya que, en algunas distribuciones, puede no estar incluido. Esto se lleva a cabo especificando LOCAL_MAILER_DEF en el fichero sendmail.m4

Por ejemplo, para que el popular programa deliver 2 gestione este servicio, se debe especificar en LOCAL_MAILER_DEF mailers.linux.

El siguiente archivo deberá ser instalado como mailers.linux en el directorio al que apunta LIBDIR. Esto define explícitamente el programa deliver, como gestor de correo interno Mlocal ; por lo que con los parámetros adecuados, sendmail se encargara de entregar correctamente el correo cuyo destino es el sistema local. A menos que se sea un experto de sendmail, es probable que no se desee modificar el siguiente ejemplo.

Hay también una opción compilada por defecto para deliver en el archivo sendmail.mc incluida en el archivo sendmail.cf. Si se opta por ella, se debe evitar el uso del archivo mailers.linux y en cambio definir lo siguiente en el archivo sendmail.m4:

Desafortunadamente, Sendmail.mc asume que el programa deliver esta instalado en /bin, lo cual no es el caso con Slackware 1.1.1 (que lo instala en /usr/bin). En este caso es necesario, ya sea engañarlo con un enlace simbólico o recompilar deliver a partir del código fuente para que resida en /bin.

Gestión de correo rechazado

_____________________________________________
2 deliver fue escrito por Chip Salzenberg (chip%tct@ateng.com). Es parte de varias distribuciones de Linux y se puede encontrar en los sistemas de FTP anónimo mas comunes como ftp.uu.net.

Muchos sistemas consideran importante asegurar que el correo que se envía y se recibe tenga un 100% de fiabilidad. Aun cuando es útil que se examinen los ficheros de registro syslogd(8), en general, el administrador del correo necesitara ver las cabeceras del correo rechazado, de tal forma que pueda determinar si el correo no fue entregado debido a un error del usuario, o a un error de configuración en alguno de los sistemas involucrados.

La definición de POSTMASTERBOUNCE hace que se envíe una copia de cada mensaje rechazado a la persona que ha sido definida como Postmaster para el sistema.

Desafortunadamente, al definir este parámetro, también se incluirá el texto en el mensaje enviado al Postmaster, lo cual en potencia, podría inquietar a los usuarios de correo del sistema en cuanto a su intimidad se refiere.

Es conveniente que los postmasters de sistema se autodisciplinen (o lo hagan por la vía de medios técnicos a través de programitas del shell que borren el texto de los mensajes rechazados que ellos reciben) a no leer el correo que no esta dirigido a ellos.

Asuntos relacionados con el servidor de nombres o Domain Name Service

Hay varias redes bien conocidas que son punto de referencia común en las direcciones de correo por razones históricas, pero que no son validas a efectos DNS. El definir PSEUDODOMAINS evita intentos de búsqueda infructuosos por parte del DNS, que siempre resultaran fallidos.

Como definir los nombres por los que se conoce al sistema local

Frecuentemente, los sistemas quieren ocultar su verdadera identidad, o servir como pasarelas de correo, o recibir y procesar correo dirigido a los nombres anteriores por los cuales se les conocían.

PSEUDONYMS especifica la lista de todos los nombres de sistema para los cuales el sistema local aceptara el correo.

DEFAULT_HOST especifica la dirección de sistema que aparecerá en los mensajes que se originan en el nodo local. Es importante que este parámetro sea ajustado a un valor valido o todo el correo de retorno no podrá ser entregado.

Temas relacionados con UUCP

Con frecuencia, los sistemas son conocidos por un nombre a efectos DNS y otro para propósitos de UUCP.

UUCPNAME permite definir que aparezca un nombre de sistema distinto en los encabezados del correo enviado a través de UUCP.

UUCPNODES define las instrucciones que proporcionan como resultado una lista con las direcciones de sistemas con los cuales se esta conectado directamente a través de conexiones UUCP.

BANGIMPLIESUUCP y BANGONLYUUCP aseguran que el correo diseccionado con la sintaxis "bang" de UUCP sea tratado de acuerdo con el comportamiento de UUCP en vez de utilizar el DNS, mas común hoy en día en Internet.

Sistemas de relevo y de correo

Muchos administradores de sistema no quieren molestarse en llevar a cabo todo el trabajo necesario para asegurar que su sistema sea capaz de encontrar todas las redes (y por supuesto otros sistemas) existentes en el mundo. En lugar de hacer esto, prefieren confiar todo el correo saliente a otro sistema reconocido como "inteligente".

RELAY_HOST define el nombre UUCP del sistema vecino inteligente.

RELAY_MAILER define el gestor de correo utilizado para enviar los mensajes hacia dicho sistema.

Es importante hacer notar que el ajuste de esos parámetros redunda en que todo el correo de salida será redirigido a ese sistema remoto, lo cual afectara la carga de ese sistema. Es necesario asegurarse de obtener el consentimiento explícito del Administrador de correo del sistema remoto antes de configurar el nuestro para que utilice a otro como nodo de reenvío de correo a efectos generales.

Tablas de configuración variadas

Con estas macros, se puede cambiar la localización donde sendmail+IDA busca las diversas tablas dbm que definen el comportamiento "real" del sistema. Es aconsejable depositarlos en LIBDIR.

El archivo maestro Sendmail.mc

Los autores de sendmail+IDA proporcionan el archivo Sendmail.mc que contiene las verdaderas "tripas", que serán convertidas al archivo sendmail.cf. Periódicamente, se sacan nuevas versiones que corrigen errores en el código, o agregan funcionalidad sin necesidad de una nueva versión y la recompilación general de sendmail.

Es importante no editar este archivo.

Bueno, ¿entonces cuales son las líneas indispensables?

Cuando no se están utilizando ninguna de las tablas dbm opcionales, sendmail+IDA entrega el correo vía el gestor de correo por omisión DEFAULT_MAILER (y posiblemente el sistema de reenvío RELAY_HOST y el gestor de correo de reenvío RELAY_MAILER) definidos en el archivo sendmail.m4 utilizado para generar sendmail.cf. Es posible modificar fácilmente este comportamiento cambiando ciertas líneas en los archivos domaintable o uucpxtable.

Un sistema genérico que este en Internet y se comunique por DNS, o uno que sea solo UUCP y envíe todo su correo vía UUCP a través de un RELAY_HOST inteligente, probablemente no necesite de ninguna modificación en una "table" especifica.

Virtualmente todos los sistemas deberían configurar el DEFAULT_HOST y las macros PSEUDONYMS, de tal modo que definan el nombre canónico de sistema, y alias, por los que es conocido, y su DEFAULT_MAILER. Si todo lo que se tiene es un nodo de reenvío y un gestor de correo de reenvío, no es necesario ajustar estos valores por defecto ya que trabajará automáticamente.

Los nodos UUCP probablemente necesiten ajustar su UUCPNAME a su nombre oficial UUCP. También es probable que ajusten su RELAY_MAILER y su RELAY_HOST los cuales habilitaran el encaminado de nodo inteligente a través de un reenvío de correo. El transporte del correo a emplear se define en RELAY_MAILER y normalmente es UUCP-A para sistemas UUCP.

Si su sistema es solo SMTP y emplea 'Domain Name Service' o DNS, se podría cambiar el DEFAULT_MAILER a TCP-A y probablemente borrar las líneas RELAY_MAILER y RELAY_HOST.

Sendmail+IDA proporciona varias tablas que permiten modificar el comportamiento por defecto de sendmail (especificado en el archivo sendmail.m4) y definir un comportamiento especial para situaciones singulares, sistemas remotos y redes. Estas tablas son luego procesadas con dbm, utilizando un Makefile que es parte de la distribución.

Muchos sistemas necesitaran algunas de estas tablas, otros ninguna. Si su sistema no precisa estas tablas, lo mas sencillo es, probablemente, crearlas con longitud cero (con la instrucción touch) y utilizar el archivo Makefile por defecto localizado en LIBDIR en lugar de editar el Makefile en si mismo.

El archivo mailertable define un tratamiento especial para máquinas especificas o dominios que están basados en el nodo o nombre de la red remota. Se utiliza de forma frecuente en los sistemas Internet para seleccionar un nodo de reenvío de correo intermedio, o una pasarela a través de la cual alcanzar una red remota, y para especificar el protocolo en particular (UUCP o SMTP) que se utilizara. Los sistemas UUCP por lo general no necesitan este archivo.

El orden es importante: sendmail lee el archivo desde el principio hacia el fin, y procesa el mensaje de acuerdo con la primera regla que encuentra. Por tanto, lo lógico normalmente es poner las reglas mas explícitas al comienzo del archivo y las mas genéricas al final.

Supongamos que se quiere redirigir todo el correo para el departamento de Ciencias de la Computación de la Universidad Groucho Marx vía UUCP a un sistema de relevo, ada.

Para hacer eso, se debe agregar una línea en mailertable como la siguiente:

Suponga que se quiere redirigir todo el correo al dominio más grande groucho.edu para que vaya a otro sistema de relevo, bighub, para la resolución de sus direcciones y posterior entrega. La expansión de las líneas que van en el archivo mailertable seria la siguiente:

Como se menciono anteriormente, el orden es importante. Invertir el orden de las dos reglas mostradas anteriormente tendría como consecuencia que todo el correo dirigido a .cs.groucho.edu fuese a través del camino mas genérico bighub en vez de utilizar la trayectoria explícita ada que es la que se quiere.

En los ejemplos de mailertable anteriores, el gestor de correo UUCP-A hace que sendmail utilice UUCP como medio de entrega con cabeceras "dominizadas".

La coma entre el gestor de correo y el sistema remoto indica que el mensaje se debe redirigir a ada para la resolución de su dirección y posterior entrega.

Las líneas que van en mailertable tienen el siguiente formato:

Existen diferentes gestores de correo posibles. Las diferencias radican generalmente en como trataran las direcciones. Los gestores de correo típicos son: TCP-A (TCP/IP con direcciones estilo Internet), TCP-U (TCP/IP con direcciones estilo UUCP), y UUCP-A (UUCP con direcciones estilo Internet).

El carácter que separa al gestor de correo de la porción del nodo en la parte izquierda de la línea de mailertable define como será modificada la dirección por la mailertable. Lo importante aquí es que únicamente se reescribe el "sobre" (para obtener el correo en el sistema remoto). Reescribir cualquier otra cosa mas que el sobre es desaconsejable debido a la alta probabilidad de arruinar la configuración del correo.

! Un signo final de exclamación elimina el nombre del nodo receptor antes de redirigirlo al gestor de correo. Esto se puede usar cuando lo que se desea, esencialmente, es forzar al correo a entrar en un sistema remoto mal configurado.

, Una coma no cambia la dirección en modo alguno. El mensaje simplemente es redirigido vía el gestor de correo especificado al nodo o sistema de reenvío especificado.

: Dos puntos eliminan el nombre del sistema receptor si hay sistemas intermedios entre usted y el destino. Así, foo!bar!joe eliminara foo, mientras que xyzzy!janet permanecerá sin cambios.

Es común que el correo dirigido a sistemas con nombres de dominio plenamente cualificados se entregue vía formato Internet (SMTP) utilizando un servidor de DNS, o mediante un sistema de reenvío. El archivo uucpxtable fuerza la entrega mediante encaminamiento UUCP, al convertir el nombre de formato dominio a un nombre de nodo con estilo UUCP sin formato de dominio.

Esto se utiliza frecuentemente cuando se es un "repetidor"3 de correo para un sistema o dominio, o cuando se desea enviar el correo a través de un enlace UUCP directo y seguro en lugar de arriesgarse a pasar potencialmente por muchos "saltos"4 si hacemos uso del gestor de correo por omisión y cualesquiera de los sistemas intermedios y redes.

Los sistemas UUCP que se comunican con sus vecinos UUCP, que utilizan cabeceras de correo dominizadas, podrían utilizar este archivo para forzar la entrega del correo, a través del enlace directo UUCP punto a punto entre los dos sistemas, en lugar de emplear la ruta menos directa a través del RELAY_MAILER y el RELAY_HOST o a través del DEFAULT_MAILER.

Los sistemas Internet que no empleen UUCP probablemente no utilicen el archivo uucpxtable.

_____________________________________________
3 Un análogo de lo que se entiende por "repetidor" en telecomunicaciones.
4 N. del T. Como hop o salto se entiende cada vez que atravesamos un sistema intermedio.

Supongamos que usted proporciona servicio de reenvío de correo a un sistema llamado sesame.com en DNS y sesame en los mapas UUCP. Necesitaría la siguiente línea en uucpxtable para forzar el direccionamiento del correo para ellos a través de nuestra conexión UUCP directa.

El archivo pathtable se utiliza para definir el encaminamiento explícito a sistemas o redes remotas. El archivo pathtable debe escribirse en orden alfabético con una sintaxis similar al estilo de pathalias. Los dos campos de cada línea deben estar separados por un TAB real; si no es así dbm podría "protestar".

La mayor parte de los sistemas no precisaran ninguna línea en pathtable.

El archivo domaintable se utiliza generalmente para forzar cierto comportamiento tras una búsqueda DNS. Permite al administrador hacer disponible una lista de abreviaturas de los nombres disponibles para sistemas o dominios a los que hagamos referencia con asiduidad, reemplazando la abreviatura con el nombre apropiado automáticamente. También puede ser utilizado para sustituir los nombres de un nodo o dominio incorrectos con la información correcta.

La mayor parte de los sistemas no necesitan líneas en domaintable.

El siguiente ejemplo muestra como reemplazar una dirección personal errónea, intentándose enviar con la correcta:

Los alias posibilitan lo siguiente:

o Permiten que una abreviatura o termino fácil de recordar actúe como una dirección de correo, que remite lo recibido a una o varias personas.
o Invocan a un programa que tomará como entrada el mensaje.
o Envían correo a un archivo.

Todos los sistemas precisan alias para el Postmaster y el MAILER-DAEMON a fin de cumplir con el RFC.

Se debe ser extremadamente cuidadoso con respecto a la seguridad cuando se definan alias que invoquen a programas o escriban a programas ya que el sendmail generalmente se ejecuta con los permisos setuid-root.

Los cambios al archivo de aliases no tienen efecto hasta que el comando

se ejecuta para construir las tablas dbm necesarias. Esto también puede hacerse ejecutando el comando newaliases, normalmente mediante el comando cron.

Para mas detalles concernientes a los alias de correo, se puede encontrar mas información en la página man aliases(5).

Las siguientes tablas están disponibles, pero se utilizan muy rara vez. Consulte la documentación que viene con el código fuente de sendmail+IDA para mas detalles.

uucprelays
El archivo uucprelays se utiliza para "corto-circuitar" la trayectoria del UUCP a sistemas especialmente bien conocidos en vez de utilizar una trayectoria multi-salto o insegura generada por el procesamiento de los mapas UUCP con pathalias.

genericfrom y xaliases
El archivo genericfrom oculta los nombres y direcciones de los usuarios locales del mundo exterior convirtiendo automáticamente los nombres de usuarios locales a direcciones genéricas de envío no coincidentes con los nombres internos de usuarios.

La utilidad asociada xalparse automatiza la generación de genericfrom y el archivo aliases de tal forma que las traducciones de los nombres del usuario de entrada y salida tengan lugar desde el archivo maestro xaliases.

decnetxtable
El archivo decnetxtable reescribe las direcciones con formato dominio a direcciones estilo DECnet muy similares al archivo domaintable, que se utiliza para reescribir direcciones sin dominizar a direcciones estilo SMTP con formato dominizado.

En esta sección se verá como instalar una distribución ejecutable típica de sendmail+IDA y un recorrido por lo necesario para personalizarla y hacerla funcionar.

La distribución binaria actual de sendmail+IDA para Linux puede obtenerse de sunsite.unc.edu en /pub/Linux/system/Mail. Incluso si se tiene una versión anterior de sendmail es muy recomendable utilizar la versión sendmail5.67b+IDA1.5 ya que todos los parches específicos para Linux están en fuentes poco revisados, y varios e importantes agujeros de seguridad han sido enmendados (algunos de ellos datan del primero de diciembre de 1993).

Si se esta compilando sendmail desde el código fuente, se deben seguir las instrucciones que están en los archivos README que están incluidos en la distribución de los fuentes.

El código fuente actual de sendmail+IDA esta disponible en vixen.cso.uiuc.edu. Para construir sendmail+IDA en Linux, también se necesitan los archivos de configuración especiales para Linux newspak-2.2.tar.gz que están en sunsite.unc.edu en el directorio /pub/Linux/system/Mail.

Si tenia instalado anteriormente smail u otro gestor de entrega de correo, probablemente quiera borrar o renombrar todos los ficheros pertenecientes a smail para mayor seguridad.

Lo primero es desempaquetar el archivo comprimido en algún lugar seguro:

Si se tiene un tar "moderno", por ejemplo de una distribución de Slackware reciente, probablemente baste con un tar -zxvf fichero .tgz y se obtendrán los mismos resultados.

Al desempaquetar el archivo se genera un directorio llamado sendmail5.65b+IDA1.5+mailx5.3b. En este directorio encontrará la instalación completa de sendmail+IDA mas un programa binario del agente para usuario mailx. Todos los directorios donde se encuentran los archivos reflejan la ubicación donde deben ser instalados estos, así que es mas seguro utilizar la aplicación tar para moverlos a otra parte:

Para elaborar un fichero sendmail.cf personalizado para su sistema, se ha de escribir un fichero sendmail.m4, y procesarlo posteriormente con m4.

En /usr/local/lib/mail/CF puede encontrar un archivo de ejemplo llamado sample.m4. Cópielo a nombredesusistema .m4, y edítelo a fin de que refleje la situación de su sistema.

El fichero de ejemplo esta configurado para un sistema solo UUCP con cabeceras dominizadas y que se comunica con un sistema inteligente. Los sistemas como éste precisan de pocas variaciones.

En esta sección se señalaran las macros a cambiar. Si quiere tener una descripción completa de lo que hacen, diríjase a la sección anterior, "Discusión del fichero sendmail.m4 ".

LOCAL_MAILER_DEF
Define el fichero que especifica los agentes de correo para gestión local. Vea la sección previa "Definición del gestor local de correo" para saber de que va.

PSEUDONYMS
Especifica todos los nombres por los que es conocido su sistema.

DEFAULT_HOST
Escriba su nomenclatura de dominio plenamente cualificado. Este nombre aparecerá como su nombre de sistema en todo el correo saliente.

UUCPNAME
Ponga su nombre de sistema sin cualificar.

RELAY_HOST y RELAY_MAILER
Si se comunica mediante UUCP con un sistema inteligente, defina RE-

LAY_HOST
como el nombre UUCP del "repetidor inteligente" de su vecino UUCP. Haga uso del gestor de correo UUCP-A si desea que las cabeceras de sus mensajes contengan su dominio.

DEFAULT_MAILER
Si esta conectado a Internet y se comunica mediante DNS, debería definir esto como TCP-A. Esto le dice a sendmail que emplee TCP-A como gestor de correo, que entregara el correo vía SMTP haciendo uso del estilo RFC normal en las direcciones de los receptores de correo. Los sistemas conectados permanentemente a Internet probablemente no precisen definir RELAY_HOST o RELAY_MAILER.

Para crear el fichero sendmail.cf, ejecutar la orden

Esto procesa el fichero nombredesusistema y crea el fichero nombredesusistema .cf a partir de él.

Lo próximo será comprobar si el fichero que acaba de crear hace lo que se espera de él o no. Esto se explica en las próximas dos secciones.

Una vez se esta contento con su comportamiento, cópielo en su sitio con el comando:

Llegados a este punto, su sistema sendmail esta listo para funcionar. Escriba la siguiente línea en el fichero de arranque adecuado (generalmente /etc/rc.inet2 ). Puede ejecutarlo "a mano" para que empiece a funcionar en este momento.

Para hacer que sendmail funcione en modo 'test', ha de ejecutarlo con la opción -bt. La configuración por defecto es el fichero sendmail.cf que este instalado en el sistema. Puede probar un fichero de configuración alternativo mediante la opción -Cfichero_alternativo.

En los siguientes ejemplos, probamos vstout.cf, el fichero de configuración generado a partir del fichero vstout.m4 que puede ser examinado en la figura 15.2.

Las siguientes comprobaciones aseguran que sendmail es capaz de gestionar el correo de todos los usuarios del sistema. En todos los casos, el resultado de la comprobación deberá ser el mismo, y apuntar al nombre del sistema local como el gestor de correo en LOCAL.

Comprobemos primero como se gestionaría el envío a un usuario local:

El resultado muestra como sendmail procesa las direcciones internamente. Esto es llevado a cabo por varias rulesets que las analizan, llaman a otras involucradas, y descomponen la dirección en sus componentes.

En nuestro ejemplo, le pasamos la dirección me a las rulesets 3 y 0 (esto es lo que significa el termino 3,0 introducido antes de la dirección).

La última línea muestra la dirección interpretada tal y como la devuelve la ruleset 0, que contiene el gestor de correo al que se le encomendaría el mensaje, y la máquina y usuario proporcionados al mismo.

A continuación, comprobaremos el envío de correo a un usuario de nuestro sistema con sintaxis UUCP.

A continuación, comprobamos el correo dirigido a un usuario de nuestro sistema con sintaxis Internet, a nuestro nombre de sistema plenamente cualificado (FQDN)

Debería repetir los anteriores dos pasos con cada uno de los nombres especificados como parámetros PSEUDONYMS y DEFAULT_NAME del fichero sendmail.m4.

Por último, comprobar que puede enviar correo a su nodo de reenvío.

Llegados a este punto, ya ha verificado que el sistema de correo tendrá el comportamiento por defecto deseado, y que será capaz tanto de enviar como de recibir correo con dirección valida. Para terminar la instalación, puede ser necesario crear las tablas dbm apropiadas para conseguir finalmente los resultados deseados.

Tras crear las tablas necesarias para su sistema, deberá procesarlas a través de dbm mediante la ejecución de la orden make en el directorio que contenga las tablas.

Si su sistema es solo UUCP, no necesita crear ninguna de las tablas mencionadas en el fichero README.linux. Solo tendrá que modificar los ficheros de tal modo que funcione el Makefile.

Si su sistema es solo UUCP y "habla" con mas sistemas además de su nodo de reenvío inteligente, necesitara añadir entradas uucpxtable para cada uno (o el correo destinado a ellos se encaminara también a través del nodo inteligente) y ejecutar dbm sobre el recién modificado fichero uucpxtable.

Para empezar, necesita asegurarse de que el correo que ha de pasar por su RELAY_HOST se envía mediante el RELAY_MAILER.

Si tiene mas vecinos UUCP, además de su RELAY_HOST, necesita asegurarse de que el correo para ellos experimenta un procesamiento adecuado. El correo con direcciones de sintaxis tipo UUCP dirigido a otro sistema con el que se comunique también mediante UUCP, ira a ellos directamente (a menos de que lo impida explícitamente mediante una entrada domaintable). Asumimos que el sistema swim es un vecino UUCP directo para nosotros. Pasar a sendmail un mensaje swim!fred deberá producir el siguiente resultado:

Si tiene entradas uucpxtable para forzar la gestión de correo UUCP a ciertos vecinos UUCP que envían su correo con cabeceras dominizadas tipo Internet, también tiene que verificarlo.

Ahora que ya se ha discutido la teoría sobre configuración, instalación y comprobación de un sistema sendmail+IDA, dediquemos unos instantes al análisis de las cosas que suceden rutinariamente en la vida de un administrador de correo.

Los sistemas remotos fallan a veces. Los módems o líneas telefónicas fallan o las definiciones DNS son elaboradas incorrectamente debido a un error humano. En estos casos, los administradores de correo han de saber como reaccionar de forma rápida, efectiva y segura para mantener el trafico del correo a través de rutas alternativas hasta que los sistemas remotos o los proveedores de acceso puedan restablecer sus servicios habituales.

El resto de este capítulo pretende proporcionarle soluciones para las "emergencias con el correo electrónico" mas frecuentes.

Para redirigir el correo para un sistema o dominio particular hacia el sistema de reenvío inteligente designado, se empleara normalmente el fichero mailertable.

Por ejemplo, para redirigir el correo para backwood.org a su sistema de pasarela UUCP backdoor, tendrá que poner la siguiente entrada en mailertable:

Los sistemas Internet tendrán frecuentemente problemas a la hora de hacer entrar el correo en sistemas mal configurados. Existen varios casos, pero el síntoma general es que el correo es devuelto por el sistema remoto o que nunca lo alcanza.

Estos problemas pueden colocar al administrador local del sistema en una situación critica, ya que sus usuarios generalmente no tienen en cuenta que usted no administra todos los sistemas a lo largo y ancho del mundo (o que usted no sepa como hacer que el administrador remoto solucione el problema). Ellos tan solo sabrán que su correo no llegó al destinatario deseado en el otro extremo, y usted será la persona mas cercana a la que pedir responsabilidades.

La configuración de un sistema remoto es problema de sus administradores, no de usted. En cualquier caso, asegúrese de no estropear la configuración de su sistema a fin de comunicarse con un sistema remoto mal configurado. Si no puede ponerse en contacto con el administrador (Postmaster) del sistema remoto a fin de que arreglen su configuración lo antes posible, tiene dos opciones:

o Generalmente es posible forzar el correo hacia el interior del sistema remoto con éxito, aunque el sistema remoto este mal configurado; las respuestas provenientes del otro extremo posiblemente no funcionen. . . pero ese es problema del administrador remoto.

Puede corregir las cabeceras erróneas de sus destinatarios de correo saliente simplemente usando una entrada domaintable para su sistema/dominio, lo que redundará en que la información no válida sea corregida en el correo originado desde su sistema:

o Los sistemas mal configurados devuelven con frecuencia el correo al sistema que lo origino, argumentando que "este correo no es para este sistema" ya que no tienen debidamente configurado su PSEUDONYMNS o equivalente. Es posible quitar toda información relativa al nombre y dominio del sistema en los destinatarios de correo saliente de nuestro sistema hacia ellos.

El ! de la siguiente mailertable gestiona el correo hacia su sistema remoto

No obstante, y aunque se consiga que el correo entre en su sistema, no hay garantías de que ellos puedan responder a nuestros mensajes (su sistema esta mal configurado, recuérdelo...) pero para entonces sus usuarios estarán quejándose a sus administradores, que es mejor que los suyos se enfaden con usted.

En un mundo ideal (desde la perspectiva Internet), todas las máquinas tendrán registro en el Servicio de Nombres de Dominio (DNS) y envían su correo con nombres de dominio plenamente cualificados.

Si se da la circunstancia de que se comunica vía UUCP con un sistema de estas características, puede forzar el correo a ser enviado directamente a través de la conexión punto-a-punto UUCP en lugar de hacerlo a través de su gestor de correo habitual, esencialmente "desdominizando" su nombre de sistema mediante el fichero uucpxtable.

Para forzar el envío de correo a la máquina sesame.com, deberá poner lo siguiente en el fichero uucpxtable:

El resultado es que sendmail determinara entonces (a través de UUCPNODES del fichero sendmail.m4 ) que se esta conectado directamente al sistema remoto, y encolara el correo saliente para ser enviado vía UUCP.

La condición contraria también se da. Con frecuencia, los sistemas tienen cierto número de conexiones UUCP que rara vez se emplean o que no siempre son tan fiables, o que no están tan disponibles como el gestor de correo por defecto o el sistema de reenvío.

Por ejemplo, en el área de Seattle hay varios sistemas que intercambian las distintas distribuciones Linux vía UUCP anónimo conforme se van liberando las distribuciones. Estos sistemas se comunican mediante UUCP solo cuando es necesario, por lo que es generalmente más rápido y fiable enviar el correo a través de múltiples saltos muy fiables y nodos de reenvío (que siempre están disponibles).

Se puede evitar fácilmente el envío directo de correo a una máquina a la que se esta directamente conectado. Si el sistema remoto posee un nombre de dominio plenamente cualificado, se puede añadir una entrada como ésta en el fichero domaintable:

Esto reemplazará cualquier aparición del nombre UUCP con el nombre FQDN, impidiendo por tanto cualquier concordancia con la línea UUCPNODES del fichero sendmail.m4. El resultado es, generalmente, que el correo se enviará vía RELAY_MAILER y RELAY_HOST (o DEFAULT_MAILER).

Para procesar los mensajes de la cola de correo saliente inmediatamente, no hay más que teclear '/usr/lib/runq'5. Esto llamara a sendmail con las opciones apropiadas para hacer que procese inmediatamente la cola de procesos pendientes en lugar de esperar al próximo procesamiento programado.

Muchos administradores de sistema (y las personas para las que trabajan) están interesados en el volumen de correo que es enviado, recibido o que pasa a través de nuestro sistema.

Hay varios métodos de cuantificar el trafico de correo.

o El paquete sendmail incorpora una utilidad llamada mailstats que lee un fichero llamado /usr/local/lib/mail/sendmail.st 6 e informa sobre el número de mensajes y bytes transferidos por cada uno de los gestores de correo que se empleen y que aparezcan en el fichero sendmail.st. Este fichero debe ser creado manualmente por el administrador local para que el registro tenga lugar por parte de sendmail. Los totales se reinicializan borrando y volviendo a crear el fichero sendmail.st. Un método para hacer esto es el siguiente;

o Probablemente la mejor forma de obtener informes de calidad acerca de quien usa el correo y la cantidad de volumen que pasa hacia, por, y a través del sistema local sea activar el depurado de correo (debugging) mediante el uso de syslogd(8). Esto generalmente conlleva el tener que arrancar el demonio syslogd desde su fichero de inicialización del sistema (de todos modos lo debería estar haciendo), y añadir una línea al fichero /etc/syslog.conf(5) que tiene el siguiente aspecto:

_____________________________________________
5 La llamada a sendmail con el parámetro '-q' tiene idénticos efectos ('sendmail -q')
6 N. del T.: En ciertas distribuciones actuales, como por ejemplo RedHat, la localización es /var/log/sendmail.st; esto dependerá de la filosofía de la distribución que emplee; el LFS (Linux Filesystem Standards, anterior FSSTND) al ser un fichero de log o de registro, recomienda el directorio /var/log

Si emplea mail.debug, y recibe un volumen de correo medio/alto, el resultado proporcionado por syslog puede hacerse bastante grande. Los ficheros de registro generados por syslogd necesitan generalmente ser purgados rutinariamente por crond(8).

Existen cierto número de utilidades disponibles comúnmente que pueden resumir el resultado del registro de correo procedente de syslogd. Una de las mas conocidas es syslog-stat.pl, un script en Perl que se distribuye con los fuentes de sendmail+IDA.

A pesar de que el Estándar de Sistema de Ficheros de Linux esta en desarrollo, todavía no esta ni terminado ni aceptado universalmente. Mi intención aquí es mostrar que todavía no somos7 un estándar, y proporcionar una idea de cuales son los lugares donde aparecen problemas con mayor frecuencia

No existe ninguna configuración auténticamente estándar del transporte de correo electrónico y sus agentes, así como no hay una "única estructura de directorios."

De acuerdo con esto, es necesario asegurarse de que todas las distintas partes del sistema (USENET news, mail, TCP/IP) están de acuerdo con la localización del gestor de correo local (lmail, deliver, etc.), el gestor de correo remoto (rmail), y el programa de transporte de correo (sendmail o smail ). Estas suposiciones generalmente no están documentadas; no obstante, el uso del comando strings puede ayudarnos a determinar que ficheros y directorios son los esperados. A continuación vienen algunos problemas que hemos observado en el pasado con algunas de las distribuciones ejecutables y fuentes disponibles comúnmente para Linux.

o Algunas versiones de la distribución de NET-2 de TCP/IP tienen servicios definidos para un programa llamado umail en lugar de para sendmail.

o Existen varios portes de elm y mailx que buscan al gestor de correo (envío) /usr/bin/smail en lugar de a sendmail.

o Sendmail+IDA tiene un gestor de correo local interno para deliver, pero espera que este en /bin en lugar de la localización mas típica en Linux /usr/bin.

En lugar de pasar por la trabajosa tarea de compilar todos los clientes de correo a partir de sus fuentes, generalmente los engañaremos con los enlaces simbólicos apropiados.

_____________________________________________
7 N. del T.: Esto ha cambiado desde que esta guía fue escrita, el LFS (Linux Filesystem Standards) o anterior FSSTND está en vías de ser aceptado, si es que no lo está ya.

Existen muchos lugares donde buscar mas información sobre sendmail. Si se quiere un listado completo, vea el "Linux MAIL Howto", que se envía regularmente a comp.answers.

También esta disponible por FTP en rtfm.mit.edu. De todos modos, el lugar definitivo son los fuentes de sendmail+IDA. Busque en el directorio ida/cf que cuelga del directorio de los fuentes, los ficheros DBM-GUIDE, OPTIONS, y Sendmail.mc.