G A C E T A   D E   L I N U X
...haciendo a Linux un poco más divertido!

Configurando el subsistema de correo en Linux
Por Ben Okopnik
Traducción al español por Julio César Mejía Terán
el día 18 de Agosto 2003, para La Gaceta de Linux

El sistema de correo es - o puede ser - una de las partes más complejas del rompecabezas Linux. Ciertamente, para mucha de nuestra gente, no es del todo complejo: instalan Netscape, introducen el nombre de su servidor POP/SMTP, nombre de usuario, y contraseña, y salen... a no ser que, desde luego, quieran usar algo más que el sistema de correo - algo como hacer un script que le envíe por correo un reporte cuando el sistema de archivos está casi lleno, o decidiendo que quisieran un lector de noticias Usenet diferente, o incluso tratar de enviar un mensaje de correo en un reporte de fallas usando las utilidades "bug" o "bashbug". Oooops...

En Unix, el correo está íntimamente integrado con el SO mismo, y no tener este trabajando bien es como conducir un auto con una llanta desinflada. Las cosas funcionan de tipo aceptable, mientras no vaya a mas de 5mph, o mueva su peso al lado malo - o incluso deje a su novia que se meta para dar un paso. Tan pronto como lo haga, cosechará problemas por docenas. Un sistema de correo funcionando - con una conexión a la red - es una de las suposiciones básicas en cualquier OS de tipo Unix. Lo que me gustaría hacer aquí es mostrarle por lo menos un ejemplo de un sistema de correo funcionando, el cual pueda ajustar o intercalar a su propia configuración; la parte importante es estar consciente de las piezas que necesita para funcionar con el fin de que esto ocurra.
 

LAS PIEZAS QUE HACEN EL TODO

El sistema de correo consiste de tres piezas algo más o menos definidas: el MUA (Mail User Agent) Agente de Correo del Usuario, es el software que usa para leer y escribir su correo, el MTA (Mail Transfer Agent) Agente de correo para la transferencia, usualmente un servidor SMTP, aunque algunos programas directamente invocados son también usados, y un programa de recuperación de correo (Algunos servidores SMTP también tienen el servicio POP, pero un programa independiente es más común). El MUA puede ser muchas otras cosas más que usted quiera: es solo un front end, esto significa que usted puede usar el que prefiera una vez estén funcionando las otras dos piezas. Usted puede incluso quedarse con Netscape si le gusta; para los otros dos en este ejemplo, voy a usar Exim - un MTA conocidicimo, y "fetchmail" de Eric S. Raymond, probablemente la utilidad de recuperación de correo más comúnmente usada en el mundo.
 

CONSEGUIR SU MATERIAL

No hay mucha complejidad en configurar "fetchmail". a lo mucho todo lo que necesita es crear un archivo llamado ".fetchmailrc" en su directorio de usuario y especificar la información sobre su POP. Como un ejemplo, aquí está como se ve el mio:


# I want to log all retrievals to "/var/log/mail.*"
set syslog

# Set stuff that's the same for everybody
defaults       protocol pop3,
               timeout 300,
               nokeep,
               fetchall,
               mda "procmail -f-"

# Get mail from my ISP
poll "pop.happybruin.com",
    user "fuzzybear"
    password "wouldnt_you_like_to_know";

# Grab it from my other account
poll "pop3.bearsden.com", 
    user "ben-fuzzybear",
    password "shhh_its_a_secret";

Apenas una mirada rápida a lo de arriba - esto está muy bien cubierto en las páginas man de "fetchamil": Estoy recuperando correo desde dos cuentas diferentes. Desde que tengo una conexión a la red algo flaky (un modem wireless), tengo ajustado "fetchmail" para terminar cualquier conexión después de 5 minutos (300 segundos). Tengo también dicho que borre todos los mensajes en el servidor una vez los haya recuperado ("nokeep"), para que ignore la bandera "ya leido" y tome todos los mensajes que están esperando ("fetchall"), y para usar "procmail" para hacer algún procesado de las cabeceras por mi ("mda ..."). La última no es necesaria para todo el mundo, pero algunos servidores SMTP malos "olvidan" incluir el encabezado llamado "Envelope-from", y esto lo arregla. con excepción de estos, pienso que todo lo demás se explica por si mismo.

Generalmente hay dos maneras en las que fetchmail es ejecutado. puede ser iniciado como uno de los scripts de "init" (esto es útil si tiene una conexión permanente), o desde su script "/etc/ppp/ip-up.d" (más común para conexiones dial-up). Generalmente, tiene que escoger esto durante la configuración de "fetchmail". Cada usuario puede también iniciarlo manualmente, como una ejecución de una sola vez (escribiendo simplemente "fetchmail" en la linea de ordenes) o como un demonio que consultará las casillas de correo a intervalos fijos (Me gusta hacerlo de esta forma, con un "fetchmail -d 600" que consulta a intervalos de 10 minutos. Esto también puede ser definido en ".fetchmailrc").

"fetchmail" es mucho más flexible y poderoso que este simple ejemplo mostrado. Es suficiente con decir que este puede hacer casi cualquier tipo de recuperación de correo, con cualquier protocolo de correo válido; a menos que usted tenga alguna invención realmente complicada - y si la tienen, usted tendría que saber sobre fetchmail - este funcionará para usted. Por supuesto, si tiene su propio agente preferido de recuperación de correo, está bien también.
 

VIENDO LA IMAGEN COMPLETA

Configurar su servidor SMTP no tiene que ser necesariamente mucho más complejo que lo anterior - pero definitivamente debería tomarle mucha reflexión. Lo primero que hay que considerar es, ¿dónde está usted en la Red? Para esos como usted que nunca ha tenido que pensar sobre si mismo sin límites de escala, usted es otra pieza del rompecabezas: la realidad es que la mayor parte de la Red está formada por pequeñas piezas - como la computadora que tiene en frente ahora mismo. Su ISP es otro nodo de la Red; cierto, está conectado a través de sus enrutadores, pero una vez está conectado, usted es más parte de la Red de lo que su ISP lo es - y consecuentemente, responsable de asegurarse que su pequeña pieza funciona en armonía con el resto.

(Un de los RFCs relacionados con seguridad que leí recientemente- no recuerdo exactamente cual - mencionaba que probablemente más del 50% de los servidores de correo conectados a la Red están en algún grado mal configurados. Muy espeluznante estadística... pero también una total evidencia de la confiabilidad y la flexibilidad de los sistemas de correo de la Red. Todo esto apunta a la necesidad de que todos nosotros contribuyamos al lado bueno de la Fuerza - haciendo nuestra parte).

Para muchos de nosotros, esta situación es muy simple: una maquina de escritorio, un ISP simple, y no necesitamos hacer nuestro propio SMTP - al menos lo más que necesitamos es remitir todo nuestro correo al servidor SMTP del ISP. En este caso, más o menos cualquier MTA lo hará - y ya está casi sin necesidad de modificar, excepto para reescribir la dirección. Solo contestando las preguntas que le haya preguntado al momento de configurar, y - bingo, ya está listo y funcionando. Sin embargo, esta parte del sistema es un poquito más "delicada" cuando tenemos otro escenario: si usted usa más de un ISP, o quiere hacer algo más incluso ligeramente diferente a lo esencial, va a tomar una pequeña configuración... y es aquí donde la mayoría de la gente pone a funcionar una problemática bestia de correo.


  los archivos de configuración de "sendmail" se ven como si alguien hubiera
  golpeado su cabeza contra el teclado. Y después de verlo... Entiendo porqué!
   -- Anónimo

"sendmail.cf" ha sido responsable de que más de un administrador de sistemas sea sacado atado a una camilla mientras echa espuma por la boca. Es una criatura espantosa... y el archivo de configuración desde el cual es creado no es ninguna lindura. he detallado un poco de su funcionamiento antes en LG#58 (Configurando Sendmail en RedHat 6.2, o Mi Aventura en el Corazón de la Jungla); hasta aquí, tengo los ataques en su mayoría bajo control, y los doctores me han dicho que puedo dejar de tomar esas pequeñas píldoras en otro año o algo así...

Seriamente, este es un punto determinante. Si la conexión de red de su sistema va a cambiar en forma trascendental (ISP, nombre del equipo, de equipo con dial-up a uno permanentemente en Internet), más de una vez o dos, debería considerar hacer su propio SMTP. Por ejemplo, Yo hice el mio porque viajo para vivir, y uso muchos ISPs diferentes (dial-up, wireless, cable modem en cuartos de hotel, etc.), con muchas configuraciones de sistema diferentes. Haciéndolo de esta manera no tengo que preocuparme nunca por como es cualquiera de las configuraciones de correo de alguien más, o tener que configurar alguna cosa cuando me muevo de un sistema a otro - algo muy conveniente. En otras palabras, hacer el suyo no es algo muy difícil de implementar, pero es una decisión crítica que debe ser tomada en base a sus propias necesidades. Para mi el criterio "hagalo-usted-mismo" es mucho más flexible, potente, y libre de problemas en todos los caso donde el entorno es cualquier otra cosa más que estático.
 

OPCIONES DE CONFIGURACIÓN DEL SMTP

Así que, hasta aquí, hemos definido dos configuraciones típicas del SMTP:

1) Delegar todo excepto la reescritura de dirección (esta tiene que ser hecha localmente). Los servidores SMTP de los ISPs (el "smarthost", desde nuestra perspectiva) cuidan todo el enrutado. Ésta es una buena manera de hacerlo cuando tiene una configuración estática que probablemente no cambie, especialmente a través de un gran ISP con un historial de buena confiabilidad (bien, podemos soñar, ¿no podemos?)

2) Hacer todo nosotros. Ésto tiene una cantidad de beneficios, incluyendo evitar el servicio de correo de un ISP poco confiable y la capacidad para ver instantáneamente si su correo ha sido realmente entregado al servidor en el otro extremo (hace algunos años, mi ISP mantuvo algunos de mis correos por más de una semana, y descartó un lote de ellos sin notificarme. Eso fue el porque inicialmente empecé a hacer esto...)

Generalmente, ésta es una decisión que se toma al momento de instalar el MTA (Agente de Correo para la Transferencia). No hay mucho para esto; en el caso de Exim, se le dan 5 opciones, de las cuales solo las primeras dos se aplican aquí realmente (el programa "eximconfig" se ejecuta durante la instalación, o puede ser ejecutado manualmente en cualquier momento):


You must choose one of the options below:

 (1) Internet site; mail is sent and received directly using SMTP. If your
     needs don't fit neatly into any category, you probably want to start
     with this one and then edit the config file by hand.

 (2) Internet site using smarthost: You receive Internet mail on this 
     machine, either directly by SMTP or by running a utility such as 
     fetchmail. Outgoing mail is sent using a smarthost. optionally with
     addresses rewritten. This is probably what you want for a dialup
     system.
  
         ...

Note que estas dos alternativas se adecuan a las anteriores dos opciones: el comportamiento "hacer todo nosotros" ensambla en la #1, y la versión "smarthost" es la #2. "eximconfig" entonces le guía a través de algunas preguntas más, una de las cuales es


...

Which user account(s) should system administrator mail go to?
Enter one or more usernames separated by spaces or commas.  Enter
`none' if you want to leave this mail in `root's mailbox - NB this
is strongly discouraged.  Also, note that usernames should be lowercase!

Dado que usted es quien configura el sistema, voy a suponer que también será usted quien lo administre, así que debería direccionar ésto a su propio nombre de usuario. si usted toma el enrutado "smarthost", se le preguntará por el nombre del smarthost; asegúrese de introducir el nombre del servidor SMTP de su ISP correctamente.
 

LA PANZA DE LA BESTIA

Una vez eso está hecho - y nosotros trataremos lo que se necesita hacer en los dos casos diferentes - necesitamos configurar la reescritura de dirección. Después de todo, su dirección de correo como la ve el sistema es "nombre-usuario@host", y a no ser que tenga su propio dominio, ésta no será un dirección valida en Internet. Afortunadamente, con Exim, esto no es un problema.

Primero, editaremos "/etc/exim/exim.conf", y agregaremos lo siguiente a la sexta sección ("REWRITE CONFIGURATION"):


*@localhost       ${lookup{$1}lsearch{/etc/email-addresses}\
                                                {$value}fail} Ffsr

Ésto buscará a través del archivo donde las reglas de reescritura están especificadas, y cambia la dirección a necesidad. Note que en algunos casos, "exim.conf" ya tendrá una línea como ésta; solo asegúrese que todo, particularmente la bandera "Ffsr" (que reescribe las cabeceras "Envelope-from", "From:", "Sender:", y "Reply-to:"), está correcto. A continuación, editaremos - sorpresa! - "/etc/email-addresses" e insertamos los registros para todos nuestros usuarios.

# Root shouldn't be emailing anyone outside, but just in case...
root: happybear@bruins.com
ben: happybear@bruins.com
rivka: sweetie@here.com
linda: babe@westcoast.org
jen: saucy@wench.net

Eso es. A diferencia de "sendmail", no hay bases de datos que construir; el archivo es leído "al vuelo". Una de las razones por las que me gusta Exim es porque su archivo de configuración está ampliamente documentado con comentarios. También, "/usr/share/doc/exim/spec.txt.gz" es un manual completo (y muy largo), que desglosa cada pedacito de la configuración y la detalla muy bien.
 

LOS DIFERENTES COMPORTAMIENTOS

Si usted está usando la opción "smarthost", hasta aquí ya lo hizo. Salte hasta la sección "PROBANDO". Si usted es un hagalo-usted-mimos como yo, aunque haya solo unas poquitas cosas más que escribir: dado que somos ahora responsables de llevar el correo a donde este esté yendo, tenemos también que tratar con la situación cuando la entrega falla (ej., el servidor que recibe o un enrutador intermedio no está funcionando, perdemos la conexión a la red por un momento, etc.). La mayoría de estos comportamientos está ya bien definido, como en cualquier MTA decente, pero encontré una cosa que disminuye los "correos problemáticos" de Exim (el cual le enviará estos a usted como el administrador) a casi cero: en la primera sección de "/etc/exim/exim.conf", debería agregar lo siguiente:


auto_thaw = 5m

En el momento en que un mensaje sea marcado como "congelado" ["frozen"] (que no se puede enviar) por Exim, esto lo "descongela" ["thaw"](intenta enviarlo de nuevo), después de cinco minutos. Dado que la mayoría de las fallas son temporales, ésta configuración se las ingenia para "enviar" el correo casi el cien por ciento de las veces, tanto como el usuario y el dominio sean validos.

Ah, de ésta forma. Ahora que es un Administrador de correo de tiempo completo... :) qué significa ésto, exactamente, ¿que se supone que tiene que hacer?. No mucho, realmente. Decidir que hacer con los mensajes problemáticos (si Exim le notifica que algo está en la cola, ejecute "mailq" para ver que es y vea su archivo de log con "exim -Mvl <id_del_mensaje>"), agregar usuarios nuevos a "/etc/email-addresses", y responder a cualquier notificación de problemas o de spam hecha por alguna persona. Lea la página man de "exim", solo para familiarizarse con esta bestia. Más o menos es eso. Administradores experimentados en sistemas grandes de correo pueden irse espantados y hacer señales de peligro que apunten hacia mi, pero para una maquina simple o una LAN pequeña, lo anterior es más o menos todo lo que necesita. Una vez configurado correctamente, un sistema de correo es una clase de criatura notablemente libre de problemas y en la mayoría de los casos auto correctiva.
 

PROBANDO

Exim tiene una serie de modos de prueba integrados, algunos de los cuales son muy convenientes. Lo principal que tenemos que probar es si nuestra regla de reescritura funciona - y eso es fácil:


Baldur:~$ exim -brw ben
  sender: happybear@bruins.com
    from: happybear@bruins.com
      to: ben@localhost
      cc: ben@localhost
     bcc: ben@localhost
reply-to: happybear@bruins.com
env-from: happybear@bruins.com
  env-to: ben@localhost

Pruebe con un nombre de usuario simple, "usuario@localhost", y usuario@su_nombre_del_equipo; todos estos deberían ser adecuadamente reescritos. También, pruebe con una dirección de correo cualquiera válida en Internet para estar seguro que ésta no es modificada.

Una vez todo lo anterior funciona bien, su sistema de correo debería estar al fin razonablemente configurado (la gente que configura las diversas distros hacen un muy buen trabajo en lo elemental, en cada caso he tenido que discernir un poco más). Pruebelo afuera enviando a usted mismo algún correo, y mirando las cabeceras; "From:" y "Reply-to:" (si alguna está definida) debería ser igual a su dirección válida de red, no solo a su nombre de usuario nada más, Aquí hay un ejemplo (las direcciones/IPs reales han sido cambiadas, como en el resto de éste artículo, para frustrar a los spambots. Alimentar con direcciones falsas, enfanjar-spammer!):
En el menú de redacción de Mutt:


    From: "Benjamin A. Okopnik" <ben@localhost>
      To: Benjamin Okopnik <happybear@bruins.com>
      Cc:                                            
     Bcc:
 Subject: Rewrite test
Reply-To:
     Fcc: =Sentmail
     Mix: <no chain defined>
     PGP: Clear



Note que en el cliente local, la dirección en "From:" es una local. Podría también - ahora que tiene un sistema de correo real - hacerlo desde la línea de ordenes con algo tan simple como


mail -s "Rewrite test" happybear@bruins.com


De cualquier manera - ahora, lo enviamos por completo, y cuando lo recibamos de vuelta - presto!


Date: Tue, 30 Apr 2002 03:47:19 -0400
From: "Benjamin A. Okopnik" <happybear@bruins.com>
To: Benjamin Okopnik <happybear@bruins.com>
Subject: Rewrite test

WARNING: Deep Magic in progress.

Ben Okopnik
-=-=-=-=-=-

Si vemos en los encabezados reales (en Mutt, presione la tecla "h"), veremos lo siguiente:


From ben Tue Apr 30 03:48:15 2002
Return-Path: <happybear@bruins.com>
Received: from Baldur (pzw-199-999-99-999.sunbridge.com [199.999.99.999]))
        by bruins.com (9.10.3/9.10.3) with ESMTP id g3U7lR45008674
        for <happybear@bruins.com> Tue, 30 Apr 2002 00:47:32 -0700 (PDT)
Received: from ben by Baldur with local (Exim 3.35 #1 (Debian))
        id 172SM7-0004nd-00                                    
        for <happybear@bruins.com> Tue, 30 Apr 2002 03:47:23 -0400
Date: Tue, 30 Apr 2002 03:47:19 -0400
From: "Benjamin A. Okopnik" <happybear@bruins.com>
To: Benjamin Okopnik <happybear@bruins.com>
Subject: Rewrite test
Message-ID: <20020430074718.GA18398@Baldur>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
Status: U  
X-UIDL: 27862

WARNING: Deep Magic in progress.

Ben Okopnik
-=-=-=-=-=-

Leyendo la información de enrutado de abajo para arriba, Exim obtuvo el mensaje de mi, reescribió la cabeza, y bruins.com lo obtuvo de Exim, así que todo fue hecho correctamente - significa que lo que mi MTA dice es reconocido adecuadamente por otros. Si el mensaje hubiera desaparecido, revisaría mi "/var/log/exim/mainlog" para ver que pasó con él exactamente, y a lo mejor mi cola para ver si está encolado. Sin embargo, es como todo lo que viene de tu hada madrina es bueno, y todo está funcionando.
 

CONCLUSIÓN

Si usted siguió todos estos pasos y los realizo... felicitaciones. Usted es ahora mucho más que un Cibernauta participante, es un amigo que contribuyó un poco de tiempo y esfuerzo para hacer que la Red funcione un poquito mejor - y yo estoy feliz de compartir el espacio-IP con los de su tipo.

Esté bien, y a linuxear feliz!

Ben Okopnik
-=-=-=-=-=-

 

Ben es un Editor Contribuyente de la Gaceta de Linux y un miembro de La Pandilla de las Respuestas (The Answer Gang).

picture Ben nació en Moscu, Rusia en 1962. Él se interesó en la electricidad a la edad de seis años--demostrándolo prontamente colocando un tenedor dentro de un enchufe e iniciando un incendio--y ha caído en un pozo de extracción tecnológico para siempre desde entonces. Él trabaja con computadoras desde los días de Elder, cuando estas tenían que ser construidas soldando partes en una tarjeta de circuito impreso y los programas tenían que caber en 4k de memoria. Él gustosamente le pagaría un buen dinero a cualquier psicólogo que pueda curarle de las pesadillas resultantes.

La experiencia subsiguiente de Ben incluye la creación de software en aproximadamente una docena de idiomas, mantenimiento de redes y bases de datos durante la aproximación de un huracán, y escribir artículos para publicar en desde revistas de navegación hasta publicaciones tecnológicas. Habiendo terminado recientemente el séptimo año del crucero Atlántico/Caribe en un barco de vela, él está actualmente atracado en Baltimore, MD, donde trabaja como instructor técnico para Sun Microsystems.

Ben viene trabajando con Linux desde 1997, y acredita a éste el perder por completo el interés en emprender la guerra nuclear en partes del noroeste pacífico


Copyright © 2003, Ben Okopnik. Copying license http://www.linuxgazette.com/copying.html
Publicado en el Número 92 de Linux Gazette, Julio 2003