5. Gestión de Correo de Internet.

A continuación describiré dos métodos para gestionar el correo en el caso que nos ocupa, una máquina aislada, con conexiones esporádicas a su Servidor de Acceso a Internet. El método B es desde luego, poco ortodoxo y se puede mejorar mucho, por lo que una colaboración en lo que a configuraciones ``ideales'' de red de este tipo de máquinas será harto agradecida.

5.1 Método ``A'' o fácil y güindosero ;-).

Instalar, usar y configurar Netscape, Mosaic u otro navegador con capacidad de gestionar correo, news, etc.

Como me consta que la inmensa mayoría de los que empiezan a usar Linux o bien no poseen una cantidad desmesurada de RAM, ni les sobra disco duro como para sacrificar más de 6 megas en el Netscape, y además desean aprender a usar métodos más *nixeros y eficaces de gestión de correo, propongo el siguiente (más fácil de configurar incluso que el netscape) método:

5.2 Método ``B''.

Requisitos

1. Popclient. Se precisa instalar el paquete Popclient. En caso de que la versión de éste use perl, se deberá instalar este último también.
2. popclient se ha quedado desfasado últimamente, siendo fetchmail el que más se emplea ahora por ser más seguro.
3. Sendmail+IDA. No, no os asustéis ;-) El sendmail+IDA, que viene en la inmensa mayoría de las distribuciones, lo tendremos configurado con editar dos líneas.

Configuración del sistema.

1. Crear una cuenta en la máquina con el mismo identificativo que se tenga en el Proveedor. Por ejemplo, mi identificativo o login en mi ISP es pacopepe, cosa fácilmente deducible debido a mi dirección de correo email; por tanto, creo una cuenta en el sistema con login pacopepe, con el comando adduser: (por supuesto, hay que hacerlo como root). Supongamos el login ``probancio'':

    /home/linuxdoc-sgml-1.5/working]# adduser probancio
   
   Looking for first available UID... 502
   Looking for first available GID... 502
   
   Adding login: probancio...done.
   Creating home directory: /home/probancio...done.
   Creating mailbox: /var/spool/mail/probancio...done.
   
   Don't forget to set the password.
   

   ahora, le asignamos un password:

    /home/linuxdoc-sgml-1.5/working]# passwd probancio
   Changing password for probancio
   Enter an empty password to quit.
   New password (? for help):
   New password (again):
   Password changed for probancio
   

   y tenemos creada su cuenta.

popclient

1. Ahora creamos el siguiente script, que será el que ejecutemos para recoger el correo, al que llamamos, por ejemplo,
   /usr/local/bin/getmail

   #!/bin/sh
   #
   # getmail, para bajarnos el correo...
   #
   PATH=/bin:/usr/bin:/usr/local/bin
   echo Bajando el correo.....
   popclient -3 -u <nombre_usuario> -p <password_del_ISP> -o /var/spool/mail/login <servidor_POP>
   

   Dado que este fichero contiene datos delicados como las passwords del ISP, lo protegeremos dándole los permisos adecuados (700 es lo recomendable). Donde en:

   <nombre_usuario>

   pondremos nuestro identificativo, en mi caso, pacopepe.

   <password_del_ISP>

   Pues exactamente eso, la clave con la que accede a su servidor.

   <...login>

   Como se observará tras crear la cuenta que describimos anteriormente, en /var/spool/mail/ se creará un fichero de igual nombre que el login de dicho usuario; en el caso supuesto anterior, probancio, este fichero sería /var/spool/mail/probancio.

   <servidor_POP>

   Aquí ha de ponerse la dirección de vuestro servidor POP; en mi caso (y suele ser común) pop03.insflug.org.

   Nota: Al elaborar el script prescindiremos de los signos ``<'' y ``>''; en el ejemplo están simplemente para resaltar los parámetros a completar. Juan Manuel Villar Navarro juanma@gaps.ssr.upm.es apunta que en las versiones 3.xx del popclient no se puede dar por línea de comandos la contraseña del ISP, (con -p) para ello ha de usarse el fichero ~/.poprc, en el que podemos definir otros parámetros de comportamiento, como el que mantenga los mensajes en el servidor (keep) en caso de que estemos de pruebas, o por cualquier otra razón. Iñigo González nexus@adv.es recomienda usar versiones del popclient superiores a la 3.0b6, además de sugerir el uso de un programa filtrador de correo como procmail, para lo que deberemos añadir al comando getmail el parámetro -m procmail.

fetchmail

En caso de usar fetchmail, un cliente muy potente y cuya documentación es bastante clara y precisa, la configuración personal se almacena en el fichero del directorio personal del usuario, ~/.fetchmailrc.

Un ejemplo del mismo:

poll host-servidor-pop proto pop3 user usuario password pass_usuario is usuario here;

donde

host-servidor-pop

sería el nombre del la máquina servidora de correo vía pop del proveedor que utilicemos;

pop3

sería el protocolo a emplear, ya que fetchmail soporta otros también, como pop2 (obsoleto) imap2bis imap4 y apop y kpop.

seguidamente, le otorgaremos permisos de lectura/escritura únicamente para el propietario, hecho muy importante, ya que de lo contrario podrían ser accesibles las contraseñas, e incluso el programa se negaría a funcionar:

chmod 600 .fetchmailrc

fetchmail ofrece una serie de prestaciones adicionales, como temporización, reenvío, funcionamiento en modo daemon etc... Es un cliente muy potente y recomendable en cuanto a seguridad se refiere.

En caso de emplearlo, no haría falta el script getmail, bastaría con invocar a fetchmail a secas.

sendmail

1. Modificación de la llamada al demonio sendmail, hecha normalmente en el arranque desde el script /etc/rc.d/init.d/sendmail.init, (RedHat) o /etc/rc.d/rc.M (Slackware) buscar la línea que dice algo así como daemon sendmail .... en RedHat, o /usr/sbin/sendmail -bd -q 15m en Slackware, y modificarla, editándola para que quede:

   [...]
           .... sendmail -bd -q2d
   [...]
   

   Esto lo que hace es que sendmail no intente continuamente mandar el correo que haya en la cola para salir, o en spool, ya que lo haremos nosotros manualmente. Si no hacemos esto veremos que al enviar un email estando desconectados, el programa donde estemos (el pine, por ejemplo) se quedará ``congelado'' un buen rato, debido a que sendmail intentará enviar inmediatamente el email, y no encontrará el destino, hasta que finalmente se produzca un timeout.
2. Modificación de /etc/sendmail.cf. Aquí buscaremos una línea que comienza por DS:

   # "Smart" relay host (may be null)
   # DS
   

   y la modificaremos para que quede reflejado nuestro servidor SMTP o de correo saliente: (en mi caso, smtp.insflug.org):

   # "Smart" relay host (may be null)
   DSsmtp.insflug.org
   

   ahora buscaremos otra que comienza por DM:

   # who I masquerade as (null for no masquerading)
   # DM
   

   y la modificamos para que refleje el dominio de nuestra dirección de correo, en mi caso insflug.org:

   # who I masquerade as (null for no masquerading)
   DMinsflug.org
   

   Con esto, lo que hemos hecho es básicamente, "enmascarar" nuestra dirección en la máquina propia; supongamos que nuestra máquina se llama beastie.insflug.org y enviamos un mensaje sin la modificación anterior; el mensaje llegará correctamente a su destino, pero no podrá ser respondido, ya que la dirección de retorno no existirá, al figurar la de nuestra propia máquina, que en nuestro caso ficticio sería probancio@beastie.insflug.org, en lugar de la de la cuenta de nuestro ISP, que es probancio@insflug.org. Realmente, lo único que enmascaramos es el dominio, de ahí la necesidad de crear una cuenta en nuestra máquina con el mismo login que en nuestro ISP (probancio en este caso); la línea DS... hace que sendmail rute todos los mensajes salientes hacia internet a través de nuestro servidor SMTP, que hace de servidor de relevo hacia internet. Podríamos no decirle nada, y dejar que se encargara de contactar y enviar directamente con el servidor de correo entrante de cada dirección, pero eso haría más lento el envío de los correo, además de que es mucho más rápida la transferencia con nuestro ISP, al no tener que salir a internet siquiera. DM... cambia los from de nuestros mensajes por nuestra verdadera dirección en el ISP.

Cómo escribir

Para responder o escribir nuestro correo podremos usar cualquier programa escritor de correo, los simples como mail o mailx, un poco más completos como el facilísimo elm, o pine, el modo de correo del versátil emacs, etc... recordando siempre hacer uso de estos programas desde la cuenta que creamos para tal fin (la de probancio en nuestro caso ficticio).

Procedimiento.

1. Establecer la conexión PPP con nuestro servidor, con cualquiera de los métodos descritos en las secciones Conexiones sin mediar Infovía o Conexiones a través de Infovía. Esto se hará normalmente como root.
2. Ejecutar el script getmail en caso de que queramos recoger el correo; en caso de querer mandar el correo pendiente por salir, teclear la orden:

   sendmail -q
   

   que ordenará a sendmail a enviar el correo. (el parámetro -q viene de queue o la ``cola'' de correo pendiente por salir).

Por supuesto, los procedimientos para establecer la conexión y recoger/mandar correo se pueden automatizar escribiendo scripts sencillos, pero eso lo dejo ya al gusto y según las circunstancias de cada uno. Estaré encantado de recibirlos, a fin de incluirlos en la próxima versión de este COMO.

5.3 Método ``C''.

Empleando clientes de correo capaces de enmascarar al usuario/dominio, podemos prescindir de la fase de configuración del enmascaramiento de dominio del sendmail. El cliente de correo (MUA Mail User Application, aplicación de gestión de correo a nivel usuario) mutt, puede hacer esto, a nivel tanto de dominio como de usuario, entre otras muchas prestaciones que harán las delicias de los amantes del modo texto: gestión pgp integrada, threads, color... Un cliente muy recomendable. Su servidor de ftp primario es:

ftp://ftp.cs.hmc.edu/pub/me/mutt

Es posible también prescindir de la ``chapucilla'' de tener que emplear el mismo usuario que en el proveedor empleando un MTA Mail Tranfer Agent, Agente de Gestión de transferencia de Correo de configuración más flexible y cómoda que sendmail, como el prometedor qmail, fácilmente obtenible en Internet, que además ofrece muchas otras prestaciones, sin la fragilidad en cuanto a seguridad de sendmail, y menos exigente en cuanto a recursos, lo que le hace ideal para listas de correo..