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.
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.
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:
Otorgan un nombre corto o bien conocido para el correo que será dirigido hacia una o más personas.
Pueden invocar a un programa con el mensaje de correo como entrada hacia dicho programa.
Pueden mandar el correo a un fichero.
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.
Ejemplo 18-4. Ejemplo del fichero aliases
#
# Los siguientes dos alias deben estar presentes para cumplir con el RFC.
# Es importante resolverlos en 'una persona' que lea su correo con regularidad.
#
postmaster: root # línea indispensable
MAILER-DAEMON: postmaster # línea indispensable
#
#
# demuestra los tipos más comunes de alias
#
usenet: janet # alias para una persona
admin: joe,janet # alias para varias personas
newspak-users: :include:/usr/lib/lists/newspak # lee a los destinatarios desde un fichero
changefeed: |/usr/local/lib/gup # alias que invoca a un programa
complaints: /var/log/complaints # alias que escribe el correo a un fichero
# |
Cada vez que actualice el fichero /etc/aliases, se debe asegurar de ejecutar el programa:
# /usr/bin/newaliases |
# /usr/lib/sendmail -bi |
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') |
¿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.
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.
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') |
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:
Aceptar el mensaje.
Aceptar los mensajes para este anfitrión o usuario aún si no provienen de nuestro anfitrión; esto es, aceptar que los mensajes sean reenviados hacia otros anfitriones desde este anfitrión.
Rechazar el correo con un mensaje genérico.
Descartar el mensaje utilizando la propiedad $#discard del sistema de correo.
Contestar con un mensaje de error utilizando ### como código de error (el cual deberá cumplir con el RFC-821) y “cualquier texto” será el mensaje.
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.
Si tiene usuarios o procesos automatizados que envían correo pero nunca necesitan recibirlo, es a veces útil no aceptar el correo destinado a ellos. Esto salva espacio de disco malgastado en almacenar correo que nunca será leído. la característica blacklist_recipients cuando se usa en combinación con la característica access_db le permite desactivar la recepción de correo para usuarios locales.
Para activar la característica, agregue las siguientes líneas al fichero sendmail.mc, si no están ya allí:
FEATURE(access_db)
FEATURE(blacklist_recipients) |
Para desactivar la recepción de correo de un usuario local, simplemente añada sus datos a la base de datos de acceso. Normalmente podría usar el estilo de entrada ### que devolvería un mensaje de error con significado al remitente para que así sepa por qué el correo no se ha entregado. Esta característica se aplica igualmente bien a usuarios en dominios de correo virtuales, y debe incluir el dominio virtual de correo en la especificación de la base de datos de acceso. Algunas entradas de /etc/mail/access podrían semejarse a esto:
daemon 550 El demonio no acepta ni lee correo.
flacco 550 El correo de este usuario ha sido desactivado administrativamente.
grump@dairy.org 550 Correo desactivado para este destinatario. |
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í.
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.
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 |
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.
| [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 |