7.3.5.2.3. fetchmail/getmail (MRA)

Como MRA estudiaremos dos de los más usandos en Linux:

• El veterano fetchmail.

• El más moderno getmail, que es quizás más recomendable.

7.3.5.2.3.1. fetchmail

Ya se ha introducido el programa fetchmail como un software que permite descargar a través de POP3 o IMAP los mensajes almacenados en buzones remotos[1]. La ventaja de usarlo es que puede programarse para que, en segundo plano, vaya descargando el correo periodicamente. Si la presencia de nuevo correo se combina con un aviso visual o sonoro mediante otro programa, podemos estar siempre informados de la llegada de nuevo correo[2].

La instalación es sencilla a través del paquete homónimo:

# apt-get install fetchmail

Hay dos modos de arrancar fetchmail:

1. Como servicio de systemd con una configuración centralizada en /etc/fetchmailrc.

2. Como programa que ejecuta un usuario interesado según su configuración incluida en ~/.fetchmailrc.

Comencemos primero por analizar un fichero de configuración típico:

set daemon 300

defaults
   pass8bits
   keep
   #mda "procmail -t"

# Cuenta en GMAIL.
poll pop.gmail.com
   proto POP3
   user 'xxx@gmail.com'
   pass secreta
   ssl
   sslcertck
to usuario_local

# Lo mismo por IMAP
skip imap.gmail.com  # skip salta la definición (ya usamos POP3, ¿no?)
   proto IMAP
   user 'xxx@gmail.com'
   pass secreta
   ssl
   sslcertck
   folder INBOX
to usuario_local

# Otras posibles cuentas remotas.

• set daemon establece que el programa correrá como demonio e intentará la descarga de correo cada 5 minutos (300 segundos). Si no existe, esta sentencia; fetchmail se ejecuta sólo una vez y acaba[3].

  Advertencia

  Si optáramos por ejecutarlo periódicamente con cron deberíamos prescindir de esta línea.

• Hay un primer bloque introducido con defaults que establece la configuración predeterminada para todos los servidores.

• Una opción muy interesante en ese bloque es keep que no borrará los mensajes del servidor. Con la capacidad que tienen los buzones de los modernos servidores, arriesgarse a perder un mensaje entra de lleno dentro de la cicatería más injustificable. Que los mensajes permanezcan en el servidor, no implica que la próxima vez, se vuelvan a descargar: sólo se descargarán los nuevos[4].

• Es posible también incluir la opcion mda que establece cuál es el MDA al que se pasarán los mensajes para que este haga la entrega efectiva al usuario. Si no especificamos ninguno, se entregarán al MTA local y será éste el que se encargue de la entrega (quizás a su vez usando un MDA externo, todo depende de cómo hallamos decidido configurarlo). Véase el epígrafe dedicado a procmail para conocer la configuración de uno.

• Para cada servidor los bloques se introducen con poll o skip. Estos segundos son bloques que fetchmail se salta, por lo que pueden servir para hacer una definición, pero que temporalmente no usaremos por alguna razón.

• El fichero presenta una configuración con POP3 y otra con IMAP aprovechando que gmail.com permite descargar por cualquiera de los dos protocolos. Eso sí, una la hemos deshabilitado para no revisar estúpidamente dos veces.

• Los bloques dedicados a cada servidor son bastante sencillos de entender, pero apuntemos algunos particularidades:

  • Usamos protocolo seguro (ssl) y, además, comprobamos la autenticidad del certificado del servidor (sslcertck). Obviamente, si el servidor IMAP lo hubiéramos montado nosotros y usáramos certificados autofirmados, la comprobación fallaría y fetchmail se negaría a proseguir la autenticación.

  • El protocolo IMAP se caracteriza porque permite al usuario tener organizados sus mensajes en distintos buzones dentro del servidor. Por tanto, cuando los descargamos debemos especificar de qué buzón queremos hacerlo. Lo habitual es que los correos entrantes acaben en un buzón que se llama INBOX, aunque esto depende de cómo se haya configurado el MDA en el servidor. Por esa razón, el bloque que ilustra una conexión IMAP incluye la línea:

    folder INBOX
    

    Si quiéramos descargar de varios buzones no habría más que añadir sus nombres[5]:

    folder INBOX
           INBOX.trabajo
           INBOX.cooperativa
    

    Como en POP3 no hay más que un buzón por usuario, esta direciva carece de sentido.

  • El bloque acaba especificando a qué usuario local deben entregarse los mensajes descargados del servidor en cuestión. Esto es necesario cuando tenemos una configuración centralizada y ejecutamos fetchmail como servicio de systemd. En cambio, si cada usuario lo ejecuta por su cuenta, podemos prescindir de esta línea, ya que fetchmail lo entregará al usuario local que lo ejecute.

Nota

Para probar la configuración podemos hacer:

$ fetchmail -v -d0

que irá mostrando los comandos que se ejecutan y evitará la ejecución como demonio (el set daemon incluido en el fichero), pòr lo que después de haber revisado todos los servidores y descagados los mensajes pendientes, fetchmail acabará.

Así, pues, éste es un fichero de configuración válido tanto para la gestión centralizada (en /etc/fetchmailrc) como para la gestión distribuida (en ~/.fetchmailrc). Ahora, si se desea centralizadamente demonizar en el arranque fetchmail, es necesario, además, que /etc/default/fetchmail contenga la línea:

START_DAEMON=yes

En cambio, si nuestra intención es hacer configuraciones particulares de usuario, existe un problema: dado que no tenemos un servicio asociado que ejecute fetchmail al arrancar el sistema, cada usuario deberia arrancarlo explícitamente tras iniciar sesión. Eso… o ser un poco más inteligente:

1. Podemos eliminar la directiva que lo transforma en un demonio (set daemon) y hacer que se ejecute periódicamente editando el contrab del usuario. Esta alternativa es trivial si se conoce cron y es precisamente la que se utiliza al configurar más adelante getmail.

2. Manipular PAM para que el arranque de fetchmail se haga como parte el proceso de autenticación. Y eso haremos, porque el script es bastante sencillo: basta con comprobar si ~/.fetchmailrc existe y, si es así, lanzar fetchmail que quedará en memoria como demonio si así lo hemos dispuesto:

   #!/bin/sh
   #
   # Script que para el usuario arranca fetchmail
   # ...
   #
   #   session  optional                    pam_exec.so /usr/local/bin/pam_fetchmail.sh
   
   FETCHMAIL="/usr/bin/fetchmail"
   
   check_service() {
      echo "$start_if" | grep -qw "$PAM_SERVICE"
   }
   
   get_home() {
      getent passwd "$1" | cut -d: -f6
   }
   
   last_session() {
      w | grep -qw "$PAM_USER"
      [ $? -eq 1 ]
   }
   
   while [ $# -gt 0 ]; do
      eval $1
      shift
   done
   [ -n "$start_if" ] || start_if="login,slim,lightdm,xdm,gdm,kdm"
   if [ -n "$rc" ]; then
      [ "${rc##/*}" != "" ] && rc="$(get_home "$PAM_USER")/$rc"
   else
      rc="$(get_home "$PAM_USER")/.fetchmailrc"
   fi
   
   case $PAM_TYPE in
      open_session)
         check_service || exit 0
         pgrep -cu "$PAM_USER" fetchmail >/dev/null || runuser -u "$PAM_USER" -- $FETCHMAIL -f "$rc"
         ;;
      close_session)
         check_service || exit 0
         last_session || exit 0
         [ -f "$rc" ] && runuser -u "$PAM_USER" -- $FETCHMAIL --quit 2>/dev/null
         ;;
      *)
         exit 0
   esac
   

   Hecho lo cual, deberíamos hacer que PAM lo ejecutase. Lo más elegante es crear un fichero de configuración en /user/share/pam-configs para pam-auth-update con el siguiente contenido:

   Name: Arranca para cada usuario fetchmail como demonio
   Default: yes
   Priority: 0
   Session-Interactive-Only: yes
   Session-Type: Additional
   Session:
   	optional	pam_exec.so  /usr/local/bin/pam_fetchmail.sh
   

7.3.5.2.3.2. getmail

getmail y más concretamente la versión 6 de getmail es un MRA escrito en Python3. Con este software parece no ser posible centralizar la configuración, sino que cada usuario debe hacer la configuración de sus cuentas de correo. Además, no puede demonizarse con lo que forzosamente debe echarse mano de cron para obtener regularmente los mensajes del servidor.

Empecemos, no obstante, por explicar dónde colocar los archivos de configuración. Hay tres posibles localizaciones[6]:

• ~/.getmail/getmailrc.

• $XDG_CONFIG_HOME/getmail/getmailrc[7].

• $XDG_CONFIG_HOME/getmail/*, donde «*» es cualquier nombre de archivo que generalmente se hace coincidir con la dirección de la cuenta que se configura (p.e. pericodelospalotes@gmail.com), porque es importante tener presente que un archivo sólo puede contener la información sobre un buzón.

Advertencia

La tercera de las posibles localizaciones originariamente no era predeterminada y en la versión incluida en bullseye no se lee, por lo que habría que recurrir a la opción -r (véase getmail(1)).

Cada archivo de configuración tendrá un aspecto semejante a este:

#
# ~/.config/getmail/xxx@gmail.com
#

[retriever]
type = SimplePOP3SSLRetriever
server = pop.gmail.com
username = xxx@gmail.com
port = 995
password = secreta

[options]
read_all = false
delete = false
message_log = ~/.cache/getmail.log

[destination]
type = MDA_external
path = /usr/bin/procmail
arguments = ("-f", "%(sender)")

en el que hay tres secciones:

[retreiver]

que contiene la información de autenticación. En el ejemplo, se usa el protocolo POP3s para obtener los mensajes del buzón.

[options]

que define algunas particularidades de la obtención. En el ejemplo, sólo se descargan mensajes nuevos, no se borran del buzón los mensajes y se define un archivo para almacenar los registros.

[destination]

que define cómo se entregan los mensajes al usuario destinatario. En el ejemplo, se ceden los mensajes a un MDA externo (procmail), aunque se podrían:

1. haber dejado en una archivo (formato mailbox)

   [destination]
   type = Mboxrd
   path = ~/inbox
   

   aunque el archivo inbox debe preexistir. Bastará con crear un archivo vacío:

   $ touch ~/inbox
   

2. en un directorio (formato maildir):

   [destination]
   type = Maildir
   path = ~/Mail/
   

   aunque el directorio debe existir previamente:

   $ mkdir -p ~/Mail/{new,cur,tmp}
   

3. haberse cedido a un MTA local (que es como se configuró fetchmail):

   [destination]
   type = MDA_qmaillocal
   

Nota

Pueden crearse también secciones para filtrado de mensajes utilizando etiquetas [filter-loquesea], pero no las abordaremos ya que hemos optado por usar procmail para ese trabajo.

Ver también

Para más información, puede consultarse la página oficial de la documentación.

Notas al pie

[1]

Como también se ha dicho que esta función a veces la incopora el propio MUA.

[2]

Por supuesto también puede haber MUAs que se puedan dejar residir en memoria y hacer toda esta labor de manera integrada.

[3]

A menos que se use la opción -d segundos que equivale a set daemon en la configuración de fichero.

[4]

Si se quieren descargar todos los mensajes de un servidor, incluso los descargados anteriormente, se puede añadir la opción fetchall.

[5]

El ejemplo ilustra dos buzones más llamados INBOX.trabajo e INBOX.cooperativa. Los nombres son absolutamente arbitrarios y no tendrían porquñé haber empezado con INBOX.

[6]

Para otras ubicaciones, aún es posible utilizar la opción -r (incluso repetidamente) al ejecutar getmail.

[7]

Ubicación que, si no se define lo contrario, es ~/.config/getmail/getmailrc.