18.8. Algunas configuraciones �tiles para Sendmail

Hay una mir�ada de posibles configuraciones de sendmail. En este espacio se ilustrar�n s�lo unos cuantos tipos de configuraci�n de importancia que ser�n muy �tiles para muchas instalaciones de sendmail.

18.8.1. Confiar en los usuarios para que pongan el campo From:

En ocasiones es �til sobreescribir el campo From: de un mensaje de correo que va hacia afuera. Supongamos que se tiene un programa basado en web que genera correo electr�nico. Normalmente el mensaje de correo aparecer� como proviniente del usuario que es el due�o del proceso del servidor de web. Pero se quiere especificar alguna otra direcci�n remitente de tal forma que el correo parezca ser originado por otro usuario o direcci�n en esa m�quina. Sendmail permite especificar en qu� usuarios del sistema se puede confiar para que tengan la habilidad de hacer esto.

La opci�n use_ct_file habilita la posibilidad de especificar y dar un fichero que liste los nombres de los usuarios de confianza. Por omisi�n, un peque�o n�mero de usuarios del sistema son de confianza de sendmail, por ejemplo root. El nombre del fichero por omisi�n para esta opci�n es /etc/mail/trusted-users en los sistemas en los que el directorio de configuraci�n es /etc/mail y en /etc/senmdail.ct en donde es el otro tipo de configuraci�n. Se puede especificar el nombre y lugar del fichero sobreescribiendo la definici�n confCT_FILE.

Escriba FEATURE(use_ct_file) en el fichero sendmail.mc para habilitar esta opci�n.

18.8.2. Managing Mail Aliases

Los alias de correo son una poderosa opci�n que permite que el correo sea dirigido a otros apartados postales que son nombres alternativos de usuarios o procesos en un servidor destinatario. Por ejemplo, es una pr�ctica com�n tener retroalimentaci�n o comentarios con respecto a un servidor de Web y que est�n dirigidos a “webmaster.” Con frecuencia no hay un usuario llamado “webmaster.” en el servidor, en vez de ello, hay un alias a otro usuario del sistema. Otro uso com�n para los alias de correo es utilizarlos por los programas de gesti�n de listas de correo en los cuales un alias dirige todos los mensajes que ingresan al programa de gesti�n de la lista para que sea interpretado.

El fichero /etc/aliases es el lugar en donde los alias se almacenan. El programa sendmail consulta este fichero cuando est� determinando c�mo manejar un mensaje que ingresa. Si encuentra una l�nea en este fichero que coincide con el usuario a quien va dirigido el mensaje, lo redirige al lugar que indica dicha l�nea.

De forma espec�fica, hay tres cosas que los alias permiten:

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

Se debe ser especialmente cuidadoso con la seguridad cuando se definan alias que invoquen o escriban a programas, ya que sendmail por lo general se ejecuta con los permisos de root.

Se pueden encontrar m�s detalles con respecto a los alias de correo en la p�gina de manual aliases(5). Una ejemplo del fichero aliases se muestra en Ejemplo 18-4.

Cada vez que actualice el fichero /etc/aliases, se debe asegurar de ejecutar el programa:
    # /usr/bin/newaliases
para reconstruir la base de datos que sendmail utiliza internamente. La orden /usr/bin/newaliases es un v�nculo simb�lico al ejecutable de sendmail y, cuando se invoca de esta forma, se comporta exactamente como si hubiese sido invocado as�:
    # /usr/lib/sendmail -bi
La orden newaliases es una forma alternativa y m�s adecuada para hacer esto.

18.8.3. C�mo usar un anfitri�n inteligente

Algunas veces un anfitri�n encuentra correo que no puede entregar directamente a un sitio remoto. Con frecuencia es conveniente tener un �nico sitio en una red que tenga el papel de gestionar la transmision del correo a sitios remotos que son dif�ciles de alcanzar, en vez de que cada sitio local intente hacer esto por s� mismo.

Hay algunas buenas razones para que se tenga un solo sitio encargado de la gesti�n del correo. Se simplifica la gesti�n al tener s�lo un sitio con una configuraci�n cuidadosa del correo que sepa c�mo manejar todos los tipos de transporte de correo, tales como UUCP, Usenet, etc. Todos los otros sitios lo �nico que necesitan es un solo protocolo de transporte para enviar su correo a este anfitri�n central. Los sitios que cumplen este papel de encaminadores centrales y reenviadores se llaman anfitriones inteligentes. Si se tiene un anfitri�n inteligente que acepte correo de usted, se puede enviar correo de cualquier tipo y �l se encargar� de gestionar el encaminamiento y la transmisi�n de ese correo a todos los sitios remotos deseados.

Otra buena aplicaci�n para la configuraci�n de anfitriones remotos es gestionar la transmisi�n del correo a trav�s de un cortafuegos privado. Una organizaci�n puede elegir instalar una red IP privada y utilizar sus propias direcciones IP no registradas. La red privada se puede conectar a Internet mediante un cortafuegos. El enviar el correo desde y hacia los diversos anfitriones dentro de la red privada hacia el mundo exterior utilizando SMTP no ser� posible en una configuraci�n convencional debido a que los sitios locales no pueden establecer una conexi�n directa de red a los sitios que est�n en Internet. En cambio, la organizaci�n puede optar por que el cortafuegos tenga la funci�n de anfitri�n inteligente. El anfitri�n inteligente que se ejecute en el cortafuegos ser� capaz de establecer conexiones directas de red con los sitios que se encuentran tanto en el interior de la red privada como en el exterior de ella. El anfitri�n inteligente puede aceptar correo de ambos anfitriones, de los que est�n en la red privada y de los que est�n en Internet, el correo se guarda en un almacenamiento local y luego se gestiona la retransmisi�n de ese correo directamente al sitio adecuado.

Los anfitriones inteligentes se utilizan en general cuando todos los otros m�todos de entrega han fallado. En el caso de una organizaci�n con una red privada, es perfectamente razonable que los anfitriones primero intenten entregar el correo directamente, y si eso falla, entonces los env�an al anfitri�n inteligente. Esto descarga mucho el tr�fico que va hacia el anfitri�n inteligente debido a que los otros anfitriones pueden enviar correo directamente a otros anfitriones dentro de la red privada.

sendmail provee de un m�todo simple para configurar un anfitri�n inteligente utilizando la opci�n SMART_HOST; para implementarlo en la configuraci�n de la Cervecera Virtual, se hace exactamente esto. Las porciones relevantes de nuestra configuraci�n que definen al anfitri�n inteligente son:
    define(`SMART_HOST', `uucp-new:moria')
    LOCAL_NET_CONFIG
    # Esta regla asegura que todo el correo local se entrega utilizando
    # el transporte smtp, todo lo dem�s se va a trav�s del anfitri�n inteligente.
    R$* < @ $* .$m. > $*	$#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3

La macro SMART_HOST permite que se especifique el anfitri�n que reenviar� todo el correo de salida que no se pueda entregar directamente y el protocolo de transporte de correo que se debe utilizar para ello.

En nuestra configuraci�n se est� usando el transporte uucp-new hacia el sitio UUCP moria. Si se quisiera configurar sendmail para que utilice un anfitri�n inteligente con SMTP, se deber�a escribir algo como lo siguiente:
    
    define(`SMART_HOST', `mail.isp.net')
No se necesita especificar que el transporte es SMTP, ya que est� dicho por omisi�n.

�Puede adivinar lo que la macro LOCAL_NET_CONFIG y la regla de reescritura podr�a estar haciendo?

La macro LOCAL_NET_CONFIG permite agregar reglas de reescritura directamente a la configuraci�n de sendmail que definir� qu� correo se deber� quedar dentro del sistema local. En nuestro ejemplo, se ha utilizado una regla en la que cualquier correo electr�nico cuyo dominio coincida con el dominio de nuestro anfitri�n (.$m.) se reescribe para ser enviado directamente usando el transporte SMTP. Esto asegura que cualquier mensaje enviado hacia un anfitri�n dentro de nuestro dominio local ser� redirigido inmediatamente al transporte SMTP y enviado directamente a ese anfitri�n en vez de pasar a trav�s de nuestro anfitri�n inteligente, que es el tratamiento por omisi�n.

18.8.4. Gestionando correo no deseado o no solicitado (Spam)

Si se ha suscrito a una lista de correo, publicado su direcci�n de correo electr�nico en un sitio web, o enviado un art�culo a UseNet, lo m�s probable es que comience a recibir correo electr�nico no solicitado con anuncios. Son los lugares comunes en donde la gente que ronda por la red busca las direcciones de correo para agregarlas a listas de correo que luego venden a compa��as que buscan anunciar sus productos. A este tipo de correo masivo se le conoce como spam.

El diccionario gratuito de la computaci�n en l�nea ofrece una definici�n con respecto al correo de spam que dice: [1]

2. (En un sentido m�s estricto que 1, arriba) El env�o indiscriminado de grandes cantidades de correo electr�nico no solicitado para promocionar un producto o un servicio. El spam, en este sentido, es una especie equivalente electr�nico de el correo basura enviado al "inquilino."

En los a�os 90, con el crecimiento del inter�s comercial en la red, hay algunas personas sin escr�pulos[2] que ofrecen el uso del spam como un "servicio" a las compa��as que quieren anunciarse en la red. Ello lo consiguen al enviar mensajes a grandes colecciones de direcciones de correo, foros de noticias de Usenet o listas de correo. Dichas pr�cticas han causado furia y reacci�n agresiva de muchos usuarios de la red en contra de dichos individuos.

Por fortuna, sendmail tiene algunos mecanismos que pueden ayudar a tratar al correo no solicitado.

18.8.4.1. Las Listas Negras en Tiempo Real (RBL)

Las listas de exclusi�n [3] en tiempo real (RBL, Real-time Blackhole List) es una lista p�blica que ayuda a reducir el volumen de anuncios no solicitados con los que se tiene que tratar. Algunas fuentes de correo electr�nico est�n en listadas en una base de datos consultable a trav�s de Internet. Ellos han sido incluidos all� por la gente que recibe anuncios no solicitados de alguna direcci�n de correo. Los grandes dominios, en ocasiones est�n en dicha lista debido a alg�n resbal�n que les impidi� detener el spam. Mientras que alguna gente se queja de alguna selecci�n en particular hecha por los mantenedores de la lista, a�n sigue siendo muy popular y los errores se arreglan con rapidez. Todos los detalles de la operaci�n de c�mo opera el servicio est�n en el sitio web del Sistema de Protecci�n contra el Abuso del Correo en http://maps.vix.com/rbl/.

Si se habilita esta opci�n de sendmail, se buscar� la direcci�n de origen de cada mensaje que llegue en la base de datos de la Lista Negra en tiempo real para determinar si se acepta o no el mensaje. Si se tiene un gran sitio con muchos usuarios, esta opci�n podr�a ahorrarles una gran cantidad de espacio en disco. Esta opci�n acepta como par�metro especificar el nombre del servidor que se va a utilizar. El servidor principal por omisi�n es rbl.maps.vix.com.

Para configurar la opci�n de "listas negras en tiempo real", se debe agregar la siguiente declaraci�n de macro en el fichero sendmail.mc:
    FEATURE(rbl)

Si se quiere especificar otro servidor de RBL, la declaraci�n que se debe escribir debe ser como la siguiente:
    FEATURE(rbl,`rbl.host.net')

18.8.4.2. La base de datos de acceso

Un sistema alternativo que tiene gran flexibilidad para el control a cambio del costo que implica una configuraci�n manual es la opci�n access_db. La base de datos de acceso permite configurar qu� anfitriones o usuarios ser�n aceptables para enviar correo y qui�nes pueden utilizarlo como puente.

Gestionar a qui�nes se les permitir� reenviar el correo es muy importante ya que el reenv�o es una t�cnica de uso com�n para mandar correo basura a los anfitriones que tienen sistemas como el RBL del que se coment� anteriormente para evitar la basura. En vez de enviar el correo directamente, los 'spammers' utilizar�n el reenv�o a trav�s de un anfitri�n que, ingenuamente, lo permita. La conexi�n entrante de SMTP no provendr� del anfitri�n conocido por enviar basura, sino de quien lo reenvi�. Para garantizar que nuestro anfitri�n no sea utilizado de esta forma, s�lo se debe reenviar el correo de los sitios autorizados. Las versiones de sendmail que son 8.9.0 o posteriores, tienen el reenv�o deshabilitado por omisi�n, as� que para ellos ser� necesario utilizar la base de datos de acceso para habilitar a los sitios locales para que puedan reenviar sus mensajes.

La idea general es muy sencilla. Cuando se recibe una conexi�n de entrada por SMTP, sendmail toma la informaci�n del encabezado de entrada y luego consulta la base de datos de acceso para ver si aceptar� el contenido del mensaje.

La base de datos de acceso es una colecci�n de reglas que describen qu� acciones se deben tomar para los mensajes recibidos de los anfitriones nombrados. El fichero de control de acceso por omisi�n se llama /etc/mail/access. La tabla tiene un formato muy simple. Cada l�nea de la tabla contiene una regla de acceso. El lado izquierdo de cada regla es un patr�n utilizado para comparar con el remitente de un mensaje de correo de entrada. Puede ser una direcci�n de correo completa, un nombre de anfitri�n o una direcci�n IP. El lado derecho es la acci�n que se deber� tomar. Hay cinco tipos de acciones que se pueden seleccionar y son:

Como ejemplo, el fichero /etc/mail/access podr�a ser como este:
    friends@cybermail.com   REJECT
    aol.com                 REJECT
    207.46.131.30           REJECT
    postmaster@aol.com      OK
    linux.org.au            RELAY

Este ejemplo rechazar� cualquier correo que se reciba desde friends@cybermail.com, cualquier anfitri�n en el dominio aol.com y el anfitri�n 207.46.131.30. La siguiente regla aceptar� correo electr�nico desde postmaster@aol.com a pesar del hecho de que el dominio en s� mismo tiene una regla de rechazo. Y la �ltima regla permite el reenv�o de correo de cualquier anfitri�n en el dominio linux.org.au.

Para habilitar la opci�n de la base de datos de acceso, se debe utilizar la siguiente declaraci�n en su fichero sendmail.mc:
    FEATURE(access_db)

La definici�n por omisi�n construye la base de datos con hash -o /etc/mail/access, lo que genera una base de datos con formato hash a partir de un fichero de texto simple. Esto es perfectamente adecuado en la mayor parte de las instalaciones. Hay otras opciones que se deben considerar si se intenta tener una gran base de datos de acceso. Consulte el libro de sendmail u otra documentaci�n de sendmail para m�s detalles.

18.8.5. Configurando el Hospedaje Virtual de Correo

El hospedaje virtual de correo proporciona a un anfitri�n la capacidad de aceptar y entregar correo en nombre de varios dominios diferentes aunque est�n en varios hospedajes de correo separados. Normalmente son los Proveedores de Aplicaci�n de Internet los que explotan el hospedaje virtual en combinaci�n con hospedaje virtual de webs, pero es sencillo de configurar y nunca se sabr� cuando tendr� la necesidad de hospedar virtualmente una lista de correo para su proyecto favorito de GNU/Linux, as� que lo describiremos aqu�.

18.8.5.1. Aceptar correo para otros dominios

Cuando sendmail recibe un mensaje de correo electr�nico, compara el anfitri�n de destino en las cabeceras del mensaje con el nombre del anfitri�n local. Si coinciden, sendmail acepta el mensaje para entrega local; si difieren, sendmail puede decidir aceptar el mensaje e intentar reenviarlo al destino final (Vea Secci�n 18.8.4.2 m�s tarde en este cap�tulo para detalles sobre c�mo configurar sendmail para aceptar correo para reenv�o ).

Si dese�semos configurar hospedeaje virtual de correo, la primera cosa que necesitamos hacer es convencer a sendmail de que deba aceptar tambi�n correo para los dominios que estamos hospedando. Afortunadamente, esto es muy sencillo de hacer.

La caracter�stica de sendmail use_cw_file nos permite especificar el nombre de un fichero donde almacenamos nombres de dominio para los que sendmail acepta correo. Para configurar la caracter�stica, a�ada la declaraci�n de la caracter�stica a su fichero sendmail.mc:
    FEATURE(use_cw_file)

El nombre predeterminado del fichero ser� /etc/mail/local-host-names para distribuciones que usen el directorio de configuraci�n /etc/mail/ o /etc/sendmail.cw para aquellas que no. Alternativamente, puede especificar el nombre y la localizaci�n del fichero anulando la macro confCW_FILE utilizando una variacion en:
    define(`confCW_FILE',`/etc/virtualnames')

Para seguir con el nombre del fichero predeterminado, si dese�semos ofrecer hospedaje virtual a los dominios bovine.net, dairy.org, y artist.org, crear�amos un fichero /etc/mail/local-host-names semejante a:
    bovine.net
    dairy.org
    artist.org

Cuando esto est� hecho, y asumiendo que los registros DNS apropiados existen y apuntan �stos nombres de dominio a nuestro anfitri�n, sendmail aceptar� los mensajes de correo para estos dominios como si estuviesen dirigidos a nuestro propio nombre de dominio real.

18.8.5.2. Reenv�o de correo hospedado virtualmente a otros destinos

La caracter�stica de sendmail virtusertable configura el soporte para la tabla de usuarios virtuales, donde configuramos el hospedaje de correo virtual. Las tablas de usuarios virtuales mapean el correo entrante destinado a algunos usuarios@anfitri�n a algunos otro_usuario@otro_anfitri�n. Puede pensar en esto como una caracter�stica de alias avanzada; una que opera usando no s�lo el usuario de destino, sino tambi�n el dominio de destino.

Para configurar la caracter�stica virtusertable, a�ada la caracter�stica a su configuraci�n sendmail.mc como se muestra:
    FEATURE(virtusertable)

Por omisi�n, el fichero conteniendo las reglas para efectuar las traducciones ser� /etc/mail/virtusertable. Puede anular �ste mediante el suministro de un argumento a la definici�n de la macro; consulte una referencia detallada de sendmail para aprender acerca de qu� opciones est�n disponibles.

El formato de la tabla de usuarios virtuales es muy sencillo. En el lado izquierdo de cada l�nea hay un patr�n representando el la direcci�n de destino original; al lado derecho, un patr�n representando la direcci�n de correo a la que la se mapear� la direcci�n virtual hospedada.

El siguiente ejemplo muestra tres posibles tipos de entradas:
    samiam@bovine.net     colin
    sunny@bovine.net      darkhorse@mystery.net
    @dairy.org            mail@jhm.org
    @artist.org           $1@red.firefly.com
En este ejemplo, estamos hospedando virtualmente tres dominios: bovine.net, dairy.org, y artist.org.

La primera entrada reenv�a el correo dirigido a un usuario en el dominio virtual bovine.net a un usuario local en la m�quina. La segunda entrada reenv�a el correo a un usuario en el mismo dominio virtual a un usuario en otro dominio. El tercer ejemplo reenv�a todo el correo dirigido a cualquier usuario dentro del dominio virtual dairly.org a una sola direcci�n de correo remota. Finalmente, la �ltima entrada reenv�a cualquier correo a un usuario en el dominio virtual artist.org al mismo usuario en otro dominio; por ejemplo, julie@artists.org ser�a reenviado a julie@red.firefly.com.

Notas

[1]

El diccionario gratuito de la computaci�n en l�nea puede ser encontrado empaquetado en muchas distribuciones de GNU/Linux, o en l�nea en su p�gina web en http://wombat.doc.ic.ac.uk/foldoc/.

[2]

N. del T:literalmente "scumbags" o sacos de mierda

[3]

N. del T: Del ingl�s "black hole", agujero negro