Servidor de correo con Postfix, Cyrus y MySQL administrado desde OpenMailAdmin

(Postfix, SASL, Cyrus IMAP, MySQL, Amavis, Postgrey, SpamAssassin, ClamAV, Squirrelmail, Mailman, Mailgraph y OpenMailAdmin)

Índice

  1. Introducción
  2. Instalación de paquetes
  3. Configuración de PAM
  4. Configuración de MySQL
  5. Configuración de Apache y OpenMailAdmin
  6. Configuración de saslauthd
  7. Configuración de Postfix
  8. Configuración de Cyrus IMAP
  9. Cifrado del canal (TLS/SSL)
  10. SpamAssassin
  11. Clam AntiVirus
  12. Amavisd-new
  13. Medidas antispam (anti-UCE) en Postfix
  14. Postgrey
  15. Mailman
  16. SquirrelMail y plug-ins
  17. Mailgraph
  18. Perspectiva general, conceptos y administración del servidor Cyrus IMAP
  19. Puertos en un cortafuegos
  20. Request For Comments (RFC)
  21. Preguntas frecuentes
  22. Bibliografía
  23. Historial de revisiones

Introducción

El propósito de este tutorial es instalar y configurar un servidor de correo electrónico totalmente funcional y de alto rendimiento con buzones locales (del inglés, local mailboxes), dominios virtuales (del inglés, virtual domains) y alias virtuales (del inglés, virtual aliases). Será útil si se trabaja con un montón de dominios en propiedad y se reciben emails en todos ellos pero sólo se envía desde uno. Este tutorial, una evolución de mi anterior artículo Configuración de un completo servidor de correo seguro con Postfix y Cyrus, de lectura recomendada pues es más detallado que éste, no está pensado para implementar una solución del estilo ISP (del inglés, Internet Service Provider), con buzones de correo virtuales (del inglés, virtual mailboxes). En este manual se utilizan las más modernas tecnologías y protocolos (a excepción de LMTP) que permiten obtener un sistema eficiente, robusto, flexible y seguro. Asimismo, se proporcionan muchas facilidades de gestión gracias a la interfaz web OpenMailAdmin.

Este artículo está basado en Debian Etch. Debian es un sistema operativo (SO) libre para ordenadores. El sistema operativo es el conjunto de programas básicos y utilidades que hacen que funcione el ordenador. Debian utiliza el núcleo Linux (el corazón del sistema operativo), pero la mayor parte de las herramientas básicas vienen del Proyecto GNU; de ahí el nombre GNU/Linux. Debian GNU/Linux ofrece más que un SO puro; viene con miles de paquetes, programas precompilados distribuidos en un formato que hace más fácil la instalación en su ordenador.

Al final del artículo conseguiremos tener un sistema de correo con las siguientes características:

Instalación de paquetes

Las siguientes instrucciones toman como punto de partida un sistema Debian Etch funcional con un kernel compilado a medida o con el que viene por defecto con el instalador y con una única interfaz de red con dirección IP pública pero, por supuesto, puede servir como base para que el lector las adapte a sus necesidades. Todas las sentencias deben ejecutarse como usuario root o con permisos de root.

Antes de comenzar a instalar paquetes es conveniente verificar que nuestro fichero de configuración /etc/apt/sources.list contiene las siguientes entradas:

deb http://ftp.es.debian.org/debian/ etch main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free
deb http://volatile.debian.org/debian-volatile etch/volatile main contrib non-free

Las líneas de fuentes deb-src se han omitido, pues no son necesarias, pero no afectan al artículo si constan en el fichero. Actualizamos la lista de paquetes y comenzamos la instalación:

apt-get update
apt-get install postfix postfix-doc postfix-mysql postfix-pcre openssl ca-certificates
apt-get install libsasl2 libsasl2-modules sasl2-bin
apt-get install cyrus-admin-2.2 cyrus-clients-2.2 cyrus-common-2.2 cyrus-doc-2.2 cyrus-imapd-2.2 libcyrus-imap-perl22
apt-get install mysql-server-5.0 mysql-client-5.0 libpam-mysql
apt-get install apache2-mpm-prefork libapache2-mod-php5 php5 php5-cli php5-mysql libphp-adodb php-pear php-db php-log php5-idn libidn11
apt-get install apache2-utils nmap ntpdate ccze less wget bzip2

Configuración de PAM

Acerca de PAM

Desde los inicios de UNIX, la autenticación del usuario se ha llevado a cabo mediante la solicitud de una contraseña que el sistema compara con la contraseña cifrada equivalente en el fichero /etc/passwd. La idea es que el usuario es quien dice ser si, y sólo si, es capaz de introducir su contraseña secreta.

Eso fueron los inicios. Desde entonces, un gran número de formas de autenticación han ido apareciendo, incluyendo sustitutos más sofisticados para el fichero /etc/passwd y dispositivos de hardware como Smart Cards, etc. El problema es que, cada vez que se desarrolla un nuevo mecanismo de autenticación, es necesario que todos los programas (login, ftpd, etc) se reescriban para soportarlo.

PAM (del inglés, Pluggable Authentication Modules) proporciona una manera de desarrollar programas que son independientes del esquema de autenticación. Estos programas necesitan cargar módulos de autenticación en tiempo de ejecución para poder funcionar. Qué módulo de autenticación se cargue depende de la configuración del sistema local y queda a discreción del administrador de sistemas.

Instalación y configuración

Editamos /etc/pam.d/imap para que contenga únicamente las directivas siguientes:

auth sufficient  pam_mysql.so user=postfix passwd=<my_passwd> host=localhost db=postfix table=user usercolumn=mbox \
                 passwdcolumn=password crypt=3 sqllog=0
account required pam_mysql.so user=postfix passwd=<my_passwd> host=localhost db=postfix table=user usercolumn=mbox \
                 passwdcolumn=password crypt=3 sqllog=0

Nota: deben eliminarse las barras invertidas, de modo que queden dos sentencias sin saltos de línea. En el artículo aparecen para evitar líneas tan largas que no quepan en la pantalla. Opcionalmente, se puede agregar verbose=1 para que se añada más información a los logs y ayudar a depurar la configuración. También opcionalmente, podemos crear la tabla log en la base de datos y agregar los siguientes parámetros al final de las dos líneas de configuración:

logtable=log logmsgcolumn=msg logusercolumn=user loghostcolumn=host logpidcolumn=pid logtimecolumn=time sqllog=1 verbose=1

Nota: verbose=1 basta que aparezca una única vez en cada línea. Con estas sentencias almacenaremos toda la información enviada y solicitada a PAM en nuestra base de datos MySQL. Deberemos añadir a la tabla los campos usados en la línea de código anterior, pero eso lo podremos hacer una vez la base de datos postfix exista (ver siguiente apartado). Establecemos ahora los permisos y enlaces adecuados en /etc/pam.d/:

chmod 600 /etc/pam.d/imap
rm --force /etc/pam.d/sieve /etc/pam.d/lmtp
ln --symbolic /etc/pam.d/imap /etc/pam.d/sieve
ln --symbolic /etc/pam.d/imap /etc/pam.d/lmtp
ln --symbolic /etc/pam.d/imap /etc/pam.d/smtp

La versión actual de libpam-mysql, la 0.6.2-1, no viene con soporte para MD5, por lo que deberemos recompilar los fuentes con soporte para SSL y MD5:

mkdir /usr/src/libpam-mysql
cd /usr/src/libpam-mysql
apt-get install dpkg-dev
apt-get source pam-mysql
apt-get build-dep pam-mysql
cd pam-mysql-0.6.2

Para poder bajar los fuentes de un paquete es preciso tener activas las directivas deb-src correspondientes en nuestro /etc/apt/sources.list. Modificamos la línea 51 del fichero debian/rules para que quede tal que:

./configure --prefix=/usr --with-openssl

Modificamos la línea 60 de este mismo fichero debian/rules para que quede tal que:

rm -f debian/libpam-mysql/lib/security/pam_mysql.la || true

Modificamos la línea 109 en el Makefile.in para que sea así:

DEFS = @DEFS@ -I. -I$(srcdir) -I. -DHAVE_OPENSSL

Modificamos la línea 6 del fichero debian/control para que quede así:

Build-Depends: libpam0g-dev, libmysqlclient15-dev, libssl-dev, debhelper (>= 4.0.0)

Y construimos el nuevo paquete:

apt-get install libssl-dev
dpkg-buildpackage
cd ..

Instalamos el nuevo paquete. Para arquitectura AMD64:

dpkg --install libpam-mysql_0.6.2-1_amd64.deb

Y para arquitectura i386:

dpkg --install libpam-mysql_0.6.2-1_i386.deb

Para que apt-get no nos sobreescriba nuestro paquete compilado a medida, podemos ponerlo on hold, de tal manera que un apt-get upgrade no lo toque. Así, si lo deseamos, cada cierto tiempo podemos ir viendo el changelog del paquete en la web de Debian hasta que veamos una situación que satisfaga nuestra instalación y buscar un backport para Etch. Para poner el paquete on hold:

echo libpam-mysql hold | dpkg --set-selections

Para quitar el estado on hold:

echo libpam-mysql install | dpkg --set-selections

Nota: este tutorial ha sido probado en las arquitecturas x86 y x86_64. En la primera la construcción del paquete no finalizó adecuadamente, y por ello tuvo que modificarse la línea 60 del fichero debian/rules, mientras que en la segunda sí finalizó satisfactoriamente sin necesidad de añadir el || true en dicha línea. En el caso de que la construcción del paquete Debian no finalice adecuadamente pero la compilación haya sido exitosa, los siguientes comandos nos procurarán una librería compartida con soporte para MD5:

mv /lib/security/pam_mysql.so /lib/security/pam_mysql.so.bak
cp /usr/src/libpam-mysql/pam-mysql-0.6.2/debian/libpam-mysql/usr/lib/security/pam_mysql.so /lib/security/
chmod 644 /lib/security/pam_mysql.so
chown root:root /lib/security/pam_mysql.so

Configuración de MySQL

Acerca de MySQL

MySQL es el servidor de bases de datos relacionales más popular del mundo, desarrollado y proporcionado por MySQL AB. MySQL AB es una empresa de segunda generación cuyo negocio consiste en proporcionar servicios en torno al servidor de bases de datos MySQL. Una de las razones para el rápido crecimiento de la popularidad de MySQL es que se trata de un producto de código abierto, y por lo tanto, va de la mano con este movimiento.

El software de bases de datos MySQL consiste de un sistema cliente/servidor que se compone de un servidor SQL multihilo, varios programas clientes y bibliotecas, herramientas administrativas, y una gran variedad de interfaces de programación (APIs). Se puede obtener también como una biblioteca multihilo que se puede enlazar dentro de otras aplicaciones para obtener un producto más pequeño, más rápido, y más fácil de manejar.

Instalación y configuración

Establecemos una contraseña para el usuario root:

mysqladmin --user=root password <my_root_passwd>

Creamos la base de datos postfix y el usuario postfix:

mysql --user=root --password mysql
Enter password:
mysql> CREATE DATABASE `postfix` ;
mysql> GRANT USAGE ON *.* TO 'postfix'@'localhost' IDENTIFIED BY '<my_passwd>' ;
mysql> GRANT ALL PRIVILEGES ON `postfix`.* TO 'postfix'@'localhost' WITH GRANT OPTION ;
mysql> FLUSH PRIVILEGES ;
mysql> quit

Configuración de saslauthd

Acerca de saslauthd

SASL son las siglas de Simple Authentication and Security Layer, un método para añadir soporte para la autenticación a protocolos basados en la conexión que ha sido estandarizado por la IETF (Internet Engineering Task Force). Se usa en servidores (en este caso Cyrus IMAP) para manejar las peticiones de autenticación de los clientes. Para ello, el protocolo incluye un comando para identificar y autenticar un usuario contra un servidor y para, opcionalmente, negociar la protección de las subsiguientes interacciones del protocolo. Si se negocia su uso, una capa de seguridad es añadida entre el protocolo y la conexión.

La librería SASL de Cyrus también usa la librería OpenSSL para cifrar los datos. El lector encontrará más información en la página web de Cyrus SASL.

Instalación y configuración

Editamos /etc/default/saslauthd para ordenar al sistema que arranque el daemon automáticamente:

START=yes
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -r -m /var/spool/postfix/var/run/saslauthd"

Opcionalmente, se puede añadir también el parámetro -d en la variable OPTIONS para conseguir un mayor nivel de información en los logs (modo depuración). Antes de arrancar el daemon deberemos crear la ruta donde escribir el socket y darle los permisos adecuados, usando dpkg-statoverride para asegurarnos de que futuras actualizaciones no los sobreescriban. También deberemos dejar un enlace débil en el lugar original de creación del socket de saslauthd para que Cyrus IMAP pueda conectarse con éste:

mkdir --parents --mode=755 /var/spool/postfix/var/run
dpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthd
ln --symbolic /var/spool/postfix/var/run/saslauthd /var/run/saslauthd

Finalmente, arrancamos el servicio:

/etc/init.d/saslauthd start

Y comprobamos la correcta aplicación del comando dpkg-statoverride:

# ls -l /var/spool/postfix/var/run/
total 0
drwx--x--- 2 root sasl 88 2007-07-02 12:21 saslauthd

Configuración de Cyrus IMAP

Acerca de Cyrus IMAP

Cyrus IMAP (Internet Message Access Protocol) es desarrollado y mantenido por el Andrew Systems Group de la Carnegie Mellon University.

A diferencia de otros servidores IMAP, Cyrus usa su propio método para almacenar el correo de los usuarios. Cada mensaje es almacenado en su propio fichero. El beneficio de usar ficheros separados es una mayor fiabilidad ya que sólo un mensaje se pierde en caso de error del sistema de ficheros. Los metadatos, tales como el estado de un mensaje (leído, etc.) se almacenan en una base de datos. Además, los mensajes son indexados para mejorar el rendimiento de Cyrus, especialmente con muchos usuarios e ingentes cantidades de mensajes. No hay nada tan rápido como el servidor IMAP Cyrus.

Otra característica muy importante es que no son necesarias cuentas locales de Linux para cada usuario. Todos los usuarios son autenticados por el servidor IMAP. Esto lo convierte en una magnífica solución cuando se tiene una gran cantidad de usuarios.

La administración es llevada a cabo mediante comandos especiales de IMAP. Esto le permite usar tanto la interfaz de línea de comandos como los interfaces web. Este método es mucho más seguro que un interfaz web para /etc/passwd.

Desde la versión 2.1 de Cyrus, se usa la versión 2 de la librería SASL para la autenticación. En la configuración descrita en este artículo se implementa una autenticación de tres capas. Cyrus se autentica con saslauthdaemon, quien redirige la petición al mecanismo que le hayamos definido, por ejemplo PAM, que buscará la información del usuario en la base de datos MySQL.

Instalación y configuración

Editamos el fichero de configuración /etc/cyrus.conf para comentar las líneas de los servicios POP3 y NNTP, pues sólo usaremos IMAP para acceder a los buzones. En este tutorial se configurará IMAP para que pueda ser accedido usando TLS por el puerto 143 y usando SSL por el puerto 993. Debido a que no he encontrado la manera de forzar a Cyrus IMAPd a cifrar el tráfico sobre el puerto 143 usando TLS, también se estarán permitiendo las conexiones no cifradas sobre ese puerto. Es por este motivo que quizás el lector quiera aprovechar la ocasión para limitar el servicio IMAP al localhost (para Squirrelmail y OpenMailAdmin) y permitir el acceso al servicio IMAP únicamente sobre SSL.

También aprovechamos la ocasión para activar squatter, un servicio que periódicamente recorrerá los buzones de correo y generará un nuevo índice SQUAT para agilizar futuras búsquedas de cadenas de texto en el asunto y el cuerpo de los mensajes almacenados. Debería quedarnos un fichero así (eliminados los comentarios para facilitar la lectura):

START {
    recover     cmd="/usr/sbin/ctl_cyrusdb -r"
    delprune    cmd="/usr/sbin/cyr_expire -E 3"
    tlsprune    cmd="/usr/sbin/tls_prune"
}
SERVICES {
    imap        cmd="imapd -U 30" listen="imap" prefork=0 maxchild=100
    imaps       cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=100
    lmtpunix    cmd="lmtpd" listen="/var/run/cyrus/socket/lmtp" prefork=0 maxchild=20
    sieve       cmd="timsieved" listen="localhost:sieve" prefork=0 maxchild=100
    notify      cmd="notifyd" listen="/var/run/cyrus/socket/notify" proto="udp" prefork=1
}
EVENTS {
    checkpoint  cmd="/usr/sbin/ctl_cyrusdb -c" period=30
    delprune    cmd="/usr/sbin/cyr_expire -E 3" at=0401
    tlsprune    cmd="/usr/sbin/tls_prune" at=0401
    squatter_1 cmd="/usr/bin/nice -n 19 /usr/sbin/squatter -s" period=120
    squatter_a cmd="/usr/sbin/squatter" at=0517
}

Para limitar IMAP en el puerto 143 al localhost, tan sólo hay que añadir localhost: antes de imap en el parámetro listen de la línea del servicio, tal que:

imap        cmd="imapd -U 30" listen="localhost:imap" prefork=0 maxchild=100

Luego editamos el fichero /etc/imapd.conf y añadimos o modificamos las siguientes directivas de configuración, dejando las demás con su valor por defecto:

admins: cyrus
sasl_pwcheck_method: saslauthd
unixhierarchysep: yes
allowusermoves: yes
servername: mail.dominio.com
postmaster: postmaster
duplicatesuppression: 0
sasl_mech_list: PLAIN LOGIN
sasl_minimum_layer: 0
umask: 027

El manual de Cyrus IMAP contiene información acerca de todas las directivas (man imapd.conf). La directiva unixhierarchysep se ha cambiado a yes para poder usar puntos en el nombre de usuario, tal que [email protected]. Se puede descomentar la línea siguiente en /etc/default/cyrus2.2 para aumentar el nivel de información enviada a los logs:

CYRUS_VERBOSE=1

Reiniciamos los servicios para activar la nueva configuración:

/etc/init.d/cyrus2.2 restart

A estas alturas ya deberíamos ser capaces de conectarnos al sevidor IMAP y administrarlo mediante la herramienta de consola cyradm. Usaremos el siguiente comando para acceder:

cyradm --user cyrus --auth login --server localhost

Para monitorizar los logs podemos usar los siguientes comandos:

tail -f /var/log/mail.log | ccze
tail -f /var/log/auth.log | ccze

Configuración de Apache y OpenMailAdmin

Acerca de OpenMailAdmin

OpenMailAdmin es una pequeña interfaz para la administración de cualquier servidor de correo IMAP. Soporta todas las características que IMAP proporciona y se ajusta a la mayoría de las configuraciones de los MTAs. Una característica clave es la jerarquía de administración, la cuál no sólo separa los usuarios normales de los usuarios administradores, sino que permite al administrador maestro del servidor crear instancias entre ellos. Así, será posible permitir que otros usuarios puedan crear sus propios subusuarios y, de esa manera, compartir un único servidor de correo entre diferentes organizaciones o proyectos. Sobresale gracias a las características de expresiones regulares y a la gestión de las ACLs (del inglés, Access Control Lists) sobre carpetas.

Instalación y configuración

Bajamos y descomprimimos OpenMailAdmin y establecemos los permisos adecuados:

mkdir --mode=755 /var/www
cd /var/www
wget http://static.ossdl.de/openmailadmin/downloads/openmailadmin-1.0.0.tbz2
tar -xjf openmailadmin-1.0.0.tbz2
mv openmailadmin-1.0.0 openmailadmin
chown --recursive www-data:root /var/www/openmailadmin
chmod 6770 /var/www/openmailadmin
find /var/www/openmailadmin/ -type d -exec chmod 6770 '{}' ';'
find /var/www/openmailadmin/ -type f -exec chmod 660 '{}' ';'

Ordenamos a Apache que escuche en el puerto 443 a partir de ahora. Para ello añadimos la directiva NameVirtualHost *:443 al fichero /etc/apache2/sites-available/default y también la directiva Listen 443 al fichero /etc/apache2/ports.conf. Editamos luego el dominio virtual que vayamos a usar para acceder a la administración por web sobre SSL (en este tutorial se usará el dominio fictício mail.dominio.com, por lo que crearemos el fichero /etc/apache2/sites-available/mail.dominio.com):

<VirtualHost *:443>
        ServerAdmin [email protected]
        ServerName mail.dominio.com
        SSLEngine on
        SSLCertificateFile "/etc/ssl/certs/mail.dominio.com_newcert.pem"
        SSLCertificateKeyFile "/etc/ssl/private/mail.dominio.com_newkey.pem"
        ErrorLog /var/log/apache2/error_mail.dominio.com.log
        CustomLog /var/log/apache2/access_mail.dominio.com.log combined

        Alias /openmailadmin /var/www/openmailadmin
        <Directory /var/www/openmailadmin/>
                AllowOverride All
                Order Deny,Allow
                Deny From All
                Allow From 127.0.0.1
                Allow From x.y.z.t
                <IfModule mod_php5.c>
                        php_flag file_uploads 0
                        php_flag ignore_repeated_errors 1
                        php_flag ignore_repeated_source 1
                        php_flag display_errors 0
                        php_flag log_errors 1
                </IfModule>
        </Directory>
</VirtualHost>

Donde x.y.z.t es la IP pública de la máquina desde la que accederemos al servidor (nuestro PC). A continuación creamos el certificado:

openssl req -new -nodes -out /etc/ssl/certs/mail.dominio.com_newreq.pem -keyout /etc/ssl/private/mail.dominio.com_newkey.pem

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:mail.dominio.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

La ejecución de éste comando nos genera dos ficheros:

  1. La petición de nuevo certificado, que una autoridad certificadora (CA) tendrá que firmar, en /etc/ssl/certs/mail.dominio.com_newreq.pem.
  2. La clave privada del certificado en /etc/ssl/private/mail.dominio.com_newkey.pem.

Podemos usar CAcert.org para firmar la petición de certificado. Debido a que CAcert.org tan sólo puede verificar la información contenida en el Common Name, da igual lo que introduzcamos en los otros campos (el resto lo descarta). El certificado resultante lo dejaremos en el fichero /etc/ssl/certs/mail.dominio.com_newcert.pem con permisos 644 para el usuario y grupo root. La clave privada ya se encuentra en /etc/ssl/private/mail.dominio.com_newkey.pem con permisos 640 para el usuario root, pero debemos cambiarle el grupo a ssl-cert:

chgrp ssl-cert /etc/ssl/private/mail.dominio.com_newkey.pem

Para utilizar los servicios de CACert.org debemos realizar los siguientes pasos:

  1. Darnos de alta en su web.
  2. Una vez validados en su sistema, dar de alta nuestro dominio mail.dominio.com.
  3. Una vez verificado nuestro dominio, procederemos a realizar la solicitud del certificado usando el contenido del fichero /etc/ssl/certs/mail.dominio.com_newreq.pem.

Nota: si somos propietarios del dominio dominio.com y ya lo tenemos añadido y verificado a la lista de dominios de CACert.org, no será necesario añadir el dominio mail.dominio.com a la lista de dominios, sino que, directamente, podremos proceder a solicitar el certificado. Si únicamente tenemos control sobre el subdominio mail.dominio.com, entonces deberemos esperar a tener configurado nuestro servidor de correo para poder verificar el dominio en CACert.org.

Nota: el certificado raíz de CACert.org ya está incluido dentro del paquete Debian ca-certificates que hemos instalado al principio del artículo.

La siguiente acción es activar el nuevo dominio virtual. Primero editamos el fichero /etc/default/apache2 y modificamos el valor de la variable NO_START para que sea 0:

NO_START=0

Finalmente activamos el módulo SSL, nuestro nuevo dominio virtual y arrancamos Apache:

a2enmod ssl
a2ensite mail.dominio.com
/etc/init.d/apache2 start

Nota: para que Apache cargara correctamente la extensión idn de PHP, tuve que añadirla manualmente al fichero /etc/php5/apache2/php.ini, tal que:

extension=idn.so

Ahora ya podemos comenzar con la configuración de OpenMailAdmin. Para ello cargamos la dirección siguiente en nuestro navegador favorito:

https://mail.dominio.com/openmailadmin/setup.php

Instalación de OpenMailAdmin

Comprobamos que la configuración del sistema sea la requerida por el software y, de ser así, pasamos al paso siguiente, donde necesitaremos rellenar los siguientes datos:

db connection settings
----------------------
DSN: mysql://postfix:<my_passwd>@localhost/postfix
tablenames' prefix:

hashed with: MD5

IMAP connection settings
------------------------
type: Cyrus imapd
host: localhost
port: 143
imap admin: cyrus
... password: <my_passwd>

first superuser
---------------
mailbox of superuser: postmaster
... password: <my_passwd>

Si pretendemos usar las capacidades multiservidor de OpenMailAdmin, además de leernos la documentación, será conveniente añadir un prefijo para las tablas mediante la opción tablenames' prefix. El proceso de instalación creará el fichero /var/www/openmailadmin/inc/config.local.inc.php con la configuración de acceso a la base de datos y las cinco tablas siguientes en la base de datos postfix:

A partir de este momento ya podemos acceder al sistema mediante la cuenta postmaster y la clave my_passwd. En adelante, accederemos a esta interfaz de gestión mediante la URL siguiente:

https://mail.dominio.com/openmailadmin/

Antes de dar por terminada la instalación y configuración de OpenMailAdmin, moveremos el fichero /var/www/openmailadmin/samples/oma_mail.daimon.php al DocumentRoot de OpenMailAdmin y borraremos el subdirectorio samples, tal y como se detalla en el documento INSTALL:

mv /var/www/openmailadmin/samples/oma_mail.daimon.php /var/www/openmailadmin/
rm --recursive --force /var/www/openmailadmin/samples/

Téngase en cuenta que en este tutorial se está restringiendo el acceso a OpenMailAdmin por dirección IP. Si no fuera así, por ejemplo para poder acceder a él desde cualquier lado, el script oma_mail.daimon.php deberá moverse fuera del DocumentRoot, de modo que no sea accesible desde el exterior sino únicamente desde el cron. El script de cron que se programará más adelante en este tutorial deberá adaptarse según convenga, por ejemplo cambiando la ruta por /root en el caso de que se haya movido a ese subdirectorio.

Configuración de Postfix

Acerca de Postfix

El MTA (Mail Transportation Agent) Postfix pretende ser rápido, fácil de administrar y seguro, a la vez que suficientemente compatible con Sendmail como para que los usuarios existentes no se asusten. Por lo tanto, externamente mantiene el estilo de Sendmail, mientras que internamente es completamente diferente.

A diferencia de Sendmail, Postfix no es un programa monolítico, sino una combinación de pequeños programas, cada uno de los cuales lleva a cabo una función especializada. En este documento, el lector encontrará la información necesaria para tener el sistema funcionando junto a otros componentes que completan la instalación de un sistema de correo electrónico. Puede encontrarse más información sobre Postfix en la documentación online de su website.

Arquitectura de Postfix

Instalación y configuración

Empezamos configurando en los ficheros /etc/mailname y /etc/hostname nuestro nombre de dominio:

echo "mail.dominio.com" > /etc/mailname
hostname mail.dominio.com

Deberemos modificar también los ficheros /etc/resolv.conf y /etc/hosts de acuerdo a nuestras necesidades. Acto seguido indicaremos a Postfix como consultar la base de datos MySQL para obtener la información que necesita. Creamos el fichero /etc/postfix/canonical.mysql:

hosts = 127.0.0.1
user = postfix
password = <my_passwd>
dbname = postfix
table = user
select_field = canonical
where_field = mbox
additional_conditions = and active = '1' limit 1

Creamos el fichero /etc/postfix/mydestination.mysql:

hosts = 127.0.0.1
user = postfix
password = <my_passwd>
dbname = postfix
table = domains
select_field = domain
where_field = domain

Creamos el fichero /etc/postfix/virtual.mysql:

hosts = 127.0.0.1
user = postfix
password = <my_passwd>
dbname = postfix
table = virtual
select_field = dest
where_field = address
additional_conditions = and active = '1'

Establecemos los permisos adecuados en los ficheros que hemos creado:

chown root:postfix /etc/postfix/canonical.mysql /etc/postfix/mydestination.mysql /etc/postfix/virtual.mysql
chmod 640 /etc/postfix/canonical.mysql /etc/postfix/mydestination.mysql /etc/postfix/virtual.mysql

Editamos el fichero principal de configuración de Postfix /etc/postfix/main.cf:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
delay_warning_time = 4h

myhostname = mail.dominio.com
mydomain = $myhostname
myorigin = $mydomain
mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8, x.y.z.t

alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mailbox_size_limit = 0
recipient_delimiter = +
unknown_local_recipient_reject_code = 550

mailbox_transport = cyrus
virtual_alias_domains = mysql:/etc/postfix/mydestination.mysql
virtual_alias_maps = mysql:/etc/postfix/virtual.mysql
sender_canonical_maps = mysql:/etc/postfix/canonical.mysql

smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
broken_sasl_auth_clients = yes

Donde x.y.z.t es la IP pública de la máquina. Si el servidor tuviera una IP privada, también deberíamos añadirla a la lista. Si el servidor estuviera conectado a una red local y quisiéramos que cualquier PC en ella mandara correos libremente, podríamos añadir la red con el formato a.b.c.0/24. Editamos ahora el fichero /etc/postfix/master.cf y añadimos la siguiente línea al final:

cyrus     unix  -       n       n       -       -       pipe
  flags= user=cyrus argv=/usr/sbin/cyrdeliver -r ${sender} -m ${extension} ${user}

Como puede apreciarse, usaremos el programa cyrdeliver para depositar los correos en el buzón en lugar de LMTP. Se puede añadir la opción -v al final de la línea siguiente para aumentar el nivel de información enviada a los logs:

smtp      inet  n       -       -       -       -       smtpd -v

Creamos /etc/postfix/sasl/smtpd.conf con permisos 644 (root:postfix) con el siguiente contenido:

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN
log_level: 0

Puede darse al parámetro log_level un valor de 7 para aumentar la cantidad de información que se añade a los logs y facilitar así la depuración de errores. Añadimos el usuario postfix al grupo sasl para que pueda leer el socket de saslauthd:

adduser postfix sasl

Añadimos etc/postfix/sasl/smtpd.conf a la variable FILES del script /etc/init.d/postfix para que se copie el fichero a la jaula de Postfix cada vez que se reinicie el servicio.

El siguiente paso es añadir soporte a Postfix para las expresiones regulares de OpenMailAdmin. Editamos /var/www/openmailadmin/oma_mail.daimon.php y cambiamos la primera línea para que apunte correctamente al intérprete y el script se ejecute adecuadamente:

#!/usr/bin/env php

Luego modificamos las siguientes variables para que queden así:

$MTA['virtual'] = '/etc/postfix/virtual';
$MTA['regexp']  = '/etc/postfix/virtual.regex';
$MTA['domains'] = '/etc/postfix/domains';
$PASSWD_CACHE   = NULL;
$DB = array(
    'DSN'       => 'mysql://postfix:<my_passwd>@localhost/postfix',
    'PREFIX'    => '',
);

Establecemos los permisos correctos en el fichero:

chmod 770 /var/www/openmailadmin/oma_mail.daimon.php

Editar el crontab de root con crontab -e y añadimos la siguiente línea:

0 */2 * * * /var/www/openmailadmin/oma_mail.daimon.php

Alternativamente, podemos crear /etc/cron.d/oma_mail.daimon con el siguiente contenido:

0 */2 * * * root /var/www/openmailadmin/oma_mail.daimon.php

Y solicitamos al daemon que recargue la configuración con el comando siguiente:

/etc/init.d/cron reload

Esta configuración hará que el script se ejecute cada media hora, con lo cual habrá que tener en cuenta que, si añadimos una nueva expresión regular para algún buzón, o bien deberemos ejecutar manualmente el script desde la consola, o bien esperar unos minutos. El script nos generará un fichero llamado virtual.regexp en /etc/postfix que contendrá un volcado de la tabla virtual_regexp. Configuraremos Postfix para que interprete ese fichero y podamos usar así el soporte para expresiones regulares de OpenMailAdmin (muy útil cuando tenemos muchos dominios). Editamos /etc/postfix/main.cf:

virtual_alias_maps = mysql:/etc/postfix/virtual.mysql, regexp:/etc/postfix/virtual.regex

OpenMailAdmin regular expressions management

Finalmente, reiniciamos Postfix para que actualice su configuración con las modificaciones realizadas con el comando siguiente:

/etc/init.d/postfix restart

Podemos comprobar el funcionamiento de Postfix mediante una conexión por telnet al puerto 25 (en negrita los comandos que tecleamos nosotros):

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.dominio.com ESMTP Postfix (Debian/GNU)
HELO localhost
250 mail.dominio.com
MAIL FROM: <postmaster>
250 Ok
RCPT TO: <postmaster>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Este es un mensaje de pruebas enviado a traves de telnet.
.
250 Ok: queued as 5F496BEE9
QUIT
221 Bye
Connection closed by foreign host.

En estos momentos podemos ver que el correo ha sido enviado al buzón postmaster ejecutando el comando:

# ls -l /var/spool/cyrus/mail/j/user/jsabater/
total 20
-rw-r----- 1 cyrus mail 616 2007-07-03 15:24 1.
-rw-r----- 1 cyrus mail 632 2007-07-03 15:24 cyrus.cache
-rw-r----- 1 cyrus mail 156 2007-07-02 17:54 cyrus.header
-rw-r----- 1 cyrus mail 136 2007-07-03 15:24 cyrus.index
-rw------- 1 cyrus mail 112 2007-07-03 10:06 cyrus.squat
drwxr-x--- 2 cyrus mail  79 2007-07-03 10:06 Trash
drwxr-x--- 2 cyrus mail  79 2007-07-03 10:06 UMS

El fichero llamado 1. es el correo:

# cat /var/spool/cyrus/mail/p/user/postmaster/1.
Return-Path: <[email protected]>
Received: from murder ([unix socket])
         by mail.dominio.com (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA;
         Tue, 03 Jul 2007 15:24:14 +0200
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost [127.0.0.1])
        by mail.dominio.com (Postfix) with SMTP id 8DD0BC000220
        for <postmaster>; Tue,  3 Jul 2007 15:24:05 +0200 (CEST)
Message-Id: <[email protected]>
Date: Tue,  3 Jul 2007 15:24:05 +0200 (CEST)
From: [email protected]
To: undisclosed-recipients:;

Este es un mensaje de pruebas enviado a traves de telnet.

Hay que tener en cuenta que lo más probable es que en el fichero /etc/aliases tengamos un alias definido para postmaster apuntando a root, lo que hará que el correo no llegue al buzón. Si es así, antes de realizar las pruebas deberemos comentar dicha línea y actualizar la base de datos de alias con el siguiente comando:

/usr/bin/newaliases

Cifrado del canal (TLS/SSL)

Acerca de TLS/SSL

Por defecto, toda comunicación en Internet se hace sin ningún tipo de cifrado y sin una autenticación fiable. Esto significa que cualquiera con acceso físico a la línea de datos por la que viaja un paquete puede espiar dicha comunicación. Aún peor, es posible redirigir o alterar esa comunicación para que la información que se desea mandar se pierda y nadie se dé cuenta.

De cara a solventar estos problemas de seguridad, Netscape, Inc. introdujo el protocolo SSL (Secure Sockets Layer), que ha ido evolucionando en el protocolo estandarizado TLS (Transportation Layer Security). Ofrece tanto cifrado de la comunicación (frenando las escuchas) como autenticación fuerte (asegurando que ambas partes de una comunicación son correctamente identificadas y que la comunicación no puede ser alterada).

Postfix/TLS no implementa el protocolo TLS por sí mismo, sino que usa el paquete OpenSSL para esta tarea. En el website de OpenSSL pueden encontrarse enlaces a documentación que profundiza en el protocolo y sus características.

Instalación y configuración

En estos momentos tenemos envío por SMTP en el puerto 25 y recepción por IMAP en el puerto 143 y por IMAP sobre SSL en el puerto 993, suficiente para comprobar el buen funcionamiento de la instalación. Vamos a añadir cifrado del canal mediante TLS y SSL para proteger tanto las contraseñas como el contenido de los mensajes de correo. Utilizaremos el mismo certificado que hemos usado anteriormente en Apache.

Añadimos el usuario cyrus al grupo ssl-cert para que pueda acceder a la clave privada del certificado:

adduser cyrus ssl-cert

Editamos ahora el fichero de configuración /etc/imapd.conf y modificamos las siguientes directivas:

sasl_minimum_layer: 128
tls_cert_file: /etc/ssl/certs/mail.dominio.com_newcert.pem
tls_key_file: /etc/ssl/private/mail.dominio.com_newkey.pem
tls_ca_file: /usr/share/ca-certificates/cacert.org/root.crt

El paquete ca-certificates ya incluye el certificado raíz de CACert.org. Reinciamos Cyrus IMAP para que se activen los cambios (recargar la configuración en este caso no basta pues no se vería que hemos añadido el usuario cyrus al grupo ssl-cert):

/etc/init.d/cyrus2.2 restart

Con estos cambios ya tenemos soporte de SSL para IMAP en el puerto 993 y acceso al 143 únicamente por el localhost (para SquirrelMail). Mediante la utilidad imtest podremos comprobar la correctitud de los cambios:

# imtest -a postmaster -w <passwd> -m login -s localhost
TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits)
S: * OK mail.dominio.com Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME \
     UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE \
     AUTH=LOGIN AUTH=PLAIN SASL-IR
S: C01 OK Completed
C: L01 LOGIN postmaster {8}
S: + go ahead
C: <omitted>
S: L01 OK User logged in
Authenticated.
Security strength factor: 256

Con Ctrl+C abandonaremos el programa. Las barras invertidas no aparecerán, pues han sido añadidas en este tutorial para indicar un salto de línea inexistente. Ahora nos falta activar el TLS en Postfix. Para ello editamos el fichero /etc/postfix/main.cf:

smtpd_use_tls = yes
smtpd_tls_auth_only = no
smtpd_tls_key_file = /etc/ssl/private/mail.dominio.com_newkey.pem
smtpd_tls_cert_file = /etc/ssl/certs/mail.dominio.com_newcert.pem
smtpd_tls_CAfile = /usr/share/ca-certificates/cacert.org/root.crt
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

Una vez tengamos el servidor en producción, será conveniente cambiar la directiva smtpd_tls_auth_only a yes para que acepte únicamente conexiones sobre TLS. Mientra tanto, dejar este parámetro con el valor no nos puede ayudar a depurar errores. También será conveniente cambiar la directiva smtpd_tls_loglevel y ponerle valor 0 para evitar guardar información innecesaria en los logs.

Reiniciaremos Postfix para que los cambios surjan efecto:

/etc/init.d/postfix restart

Ahora podemos pasar a comprobar el buen funcionamiento de la autenticación SASL a través de TLS. Primero tendremos que generar la cadena alfanumérica que nos autenticará durante el proceso de comunicación. Para ello necesitaremos soporte para Perl y nuestro nombre de usuario y contraseña definidos en la base de datos. Ejecutamos entonces:

/usr/bin/perl -MMIME::Base64 -e 'print encode_base64("username\0username\0password");'

sustituyendo username por postmaster en las dos ocasiones y password por nuestra contraseña <passwd>. En la línea siguiente aparecerá una cadena alfanumérica que usaremos en seguida, del estilo anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI=. A continuación se muestra la comprobación usando autenticación PLAIN y la cadena obtenida como ejemplo (en negrita lo que nosotros tecleamos):

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.dominio.com ESMTP Postfix (Debian/GNU)
EHLO localhost
250-mail.dominio.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI
235 2.0.0 Authentication successful
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Esta autenticación sólo la podremos realizar si tenemos la directiva smtpd_tls_auth_only = no en /etc/postfix/main.cf. Si la tenemos a yes tan sólo podremos verificar que podemos iniciar correctamente el protocolo TLS:

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.dominio.com ESMTP Postfix (Debian/GNU)
EHLO localhost
250-mail.dominio.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
STARTTLS
220 2.0.0 Ready to start TLS
QUIT
QUIT
Connection closed by foreign host.

En estos momentos contamos ya con un servidor de correo funcional y podemos probarlo mediante un cliente de correo con soporte SMTP con TLS e IMAP sobre SSL. Los siguientes apartados únicamente pretenden mejorar la configuración llevada a cabo hasta el momento. Antes de pasar al siguiente apartado se presenta un resumen de los datos de conexión:

Autenticación y autorización.

La autenticación es el mecanismo por el cual los sistemas pueden identificar con seguridad a los usuarios. Los sistemas de autenticación proporcionan respuestas a las siguientes preguntas:

Un método de autenticación puede ser tan sencillo (e inseguro) como una contraseña en texto plano (servidores de FTP antiguos) o tan complicados como el sistema Kerberos. En cualquier caso, sin embargo, los sistemas de autenticación dependen de alguna pequeña porción de información conocida (o disponible) sólo por el individuo que está autenticándose y el sistema de autenticación (un secreto compartido). Esa información puede ser la clásica contraseña, algún tipo de propiedad física del individuo (huellas dactilares, patrón de retina, etc), o algunos datos derivados (como es el caso de los llamados sistemas de tarjeta inteligente - smartcard). De modo que pueda verificarse la identidad de un usuario, el sistema de autenticación típicamente solicita al usuario que proporcione esa información única (su contraseña, sus huellas, etc.) y, si el sistema de autenticación puede verificar que ese secreto compartido se ha presentado correctamente, entonces el usuario se considera autenticado.

La autorización, en contraste, es el mecanismo por el cual un sistema determina qué nivel de acceso un usuario particular que ya se ha autenticado debería tener sobre los recursos controlados por el sistema. Por ejemplo, un sistema de gestión de bases de datos puede estar diseñado para proporcionar a ciertos individuos la capacidad de recuperar información de la base de datos pero no la capacidad de cambiar los datos almacenados, mientras que podría dar a otros individuos esa capacidad. Los sistemas de autorización responden a las siguientes preguntas:

SpamAssassin

Acerca de SpamAssassin

SpamAssassin es un filtro de correo que trata de identificar el spam mediante el análisis del texto y el uso en tiempo real de algunas listas negras a través de Internet. A partir de su base de datos de reglas, utiliza un amplio abanico de pruebas heurísticas en las cabeceras y el cuerpo de los correos para identificar el spam, también conocido como correo electrónico comercial no solicitado. Una vez identificado, el correo puede ser opcionalmente marcado como spam o más tarde filtrado usando el cliente de correo del usuario.

SpamAssassin normalmente identifica acertadamente entre un 95 y un 99% del spam, dependiendo del tipo de correo que se reciba. También incluye soporte para informar de mensajes de spam, automática o manualmente, a bases de datos como Vipul's Razor.

Instalación y configuración

Más sencillo, imposible:

apt-get install spamassassin spamc libmail-spf-query-perl

Es aconsejable crear un job en el cron que ejecute periódicamente el script /usr/bin/sa-update. Este script descargará la última versión de las reglas de detección de correo basura distribuidas por el equipo de desarrollo de SpamAssassin.

Clam AntiVirus

Acerca de ClamAV

ClamAV es una herramienta antivirus GPL para UNIX. El propósito principal de este software es la integración con los servidores de correo (escaneo de datos adjuntos). El paquete proporciona un servicio multihilo flexible y escalable, un analizador de línea de comandos y una utilidad para la actualización automática via Internet. Los programas están basados en una librería distribuida con el paquete Clam AntiVirus, la cual puede ser usada por su propio software. Y lo más importante, la base de datos se mantiene actualizada constantemente.

Otras características destacables son el soporte de firmas digitales en la actualización de la base de datos, el análisis durante el acceso bajo Linux y FreeBSD, la detección de más de 20000 virus, gusanos y troyanos, el soporte integrado para archivos comprimidos con Rar, Zip, Gzip y Bzip2 y formatos de correo Mbox, Maildir y ficheros crudos de correo.

Instalación y configuración

Casi tan sencillo como SpamAssassin. Primero instalamos los paquetes necesarios:

apt-get install rar unrar lha arj unzoo zip unzip bzip2 gzip cpio file lzop nomarch cabextract pax zoo tnef
apt-get install clamav clamav-daemon clamav-freshclam clamav-docs

Luego nos aseguramos de que la directiva AllowSupplementaryGroups existe en el fichero /etc/clamav/clamd.conf.

Amavisd-new

Acerca de Amavisd-new

Amavisd-new es un interfaz de alto rendimiento y fiabilidad entre el MTA y uno o más filtros de contenidos: antivirus o el módulo Mail::SpamAssassin de Perl. Está escrito en Perl, asegurando alta fiabilidad, portabilidad y facilidad de mantenimiento. Se comunica con el MTA via (E)SMTP o LMTP, o mediante el uso de otros programas. No existen problemas de sincronización en su diseño que pudieran causar pérdidas de correos.

Normalmente se posiciona dentro o cerca del gestor de correo principal, no necesariamente donde se ubiquen las cuentas de correo de los usuarios (donde tiene lugar el envío final). Si se está buscando una solución que soporte configuración por usuario y ratios de mensajes pequeñas que se ubique al final del proceso de envío (p.e. llamado desde procmail o en sustitución de un agente local de envío), posiblemente puedan encontrarse otras soluciones más apropiadas.

Cuando está habilitado el uso de Mail::SpamAssassin (SA), se llama a SA una sola vez por mensaje (independientemente del número de destinatarios). Amavisd-new se beneficia del uso del módulo de Perl Net::Server, el cuál ofrece un rápido entorno multihilo. Amavisd-new ofrece un servidor SMTP que cumple con el RFC 2821, un servidor LMTP que cumple con el RFC 2033, un cliente SMTP y genera notificaciones de estado de envío (o no) que cumplen los RFC 1892 y 1894. Esto lo hace adecuado para múltiples analizadores de virus y de correo publicitario en plataformas de correo donde la fiabilidad y el cumplimiento de los estándares son importantes.

Instalación y configuración

En primer lugar, instalaremos el paquete amavisd-new:

apt-get install amavisd-new

Si nuestro /etc/hostname no es un FQDN, es decir, si es un nombre del estilo mail en lugar de mail.dominio.com, deberemos modificar el fichero /etc/amavis/conf.d/50-user, añadiendo mail.dominio.com para que Amavis tenga un valor adecuado de esa variable $myhostname.

$myhostname = "mail.dominio.com";

Activamos el uso del antivirus ClamAV y el filtro antispam SpamAssassin en la configuración de Amavis editando el fichero /etc/amavis/conf.d/15-content_filter_mode, donde descomentaremos las líneas:

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);

@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

De esta forma, dejaremos pasar los correos identificados como spam, aunque siguen siendo marcados como tales mediante cabeceras en el correo. De este modo, los destinatarios seguirán recibiendo toda su correspondencia pero podrán filtrarla fácilmente usando SIEVE y las cabeceras que amavisd-new habrá añadido al mensaje. Pero para que se produzca el comportamiento descrito, deberemos también editar el fichero /etc/amavis/conf.d/20-debian_defaults y asegurarnos que la variable final_spam_destiny tenga el valor D_PASS:

$final_spam_destiny = D_PASS;

A continuación se presenta una configuración recomendada, pero opcional, de adjuntos permitidos y no permitidos. Es preciso que se evalúe la red interna y las necesidades particulares de cada caso, pues la siguiente configuración es bastante restrictiva. La conseguimos descomentando las siguientes líneas en el fichero /etc/amavis/conf.d/20-debian_defaults:

qr'^application/x-msmetafile$'i,                      # Windows Metafile MIME type
qr'^\.wmf$',                                          # Windows Metafile file(1) type
qr'^message/partial$'i, qr'^message/external-body$'i, # rfc2046 MIME types
[ qr'^\.(Z|gz|bz2)$'           => 0 ],                # allow any in Unix-compressed
[ qr'^\.(rpm|cpio|tar)$'       => 0 ],                # allow any in Unix-type archives
[ qr'^\.(zip|rar|arc|arj|zoo)$'=> 0 ],                # allow any within such archives

qr'.\.(ade|adp|app|bas|bat|chm|cmd|com|cpl|crt|emf|exe|fxp|grp|hlp|hta|
inf|ins|isp|js|jse|lnk|mda|mdb|mde|mdw|mdt|mdz|msc|msi|msp|mst|
ops|pcd|pif|prg|reg|scr|sct|shb|shs|vb|vbe|vbs|
wmf|wsc|wsf|wsh)$'ix,                                 # banned ext - long

qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i,                # banned extension - WinZip vulnerab.

qr'^\.(exe|lha|tnef|cab|dll)$',                       # banned file(1) types

Esta configuración permite el paso de cualquier adjunto comprimido en formato gzip, bzip2, rpm, cpio, tar, zip, rar, arc, arj y zoo e impide el paso de todas las demás extensiones que aparecen (wmf, ade, adp, app, etc). Finalmente, de manera opcional también, podemos decirle a Amavis que modifique el asunto del correo y le añada ***SPAM*** cuando identifique un correo como spam (también en el fichero /etc/amavis/conf.d/20-debian_defaults):

$sa_spam_subject_tag = '***SPAM*** ';

Una vez hayamos configurado amavisd-new a nuestra medida añadimos el usuario clamav al grupo amavis y reiniciamos los servicios de Clam Antivirus:

adduser clamav amavis
/etc/init.d/clamav-daemon restart
/etc/init.d/clamav-freshclam restart

Finalmente reiniciamos el daemon de Amavis para que se active la nueva configuración:

/etc/init.d/amavis restart

Ahora que ya tenemos amavisd-new funcionando, vamos a decirle a Postfix que haga uso del nuevo filtro de contenidos. Para ello editaremos primero el fichero /etc/postfix/master.cf, al cuál añadiremos las dos siguientes directivas en su sección Interfaces to non-Postfix software:

smtp-amavis unix -      -       y     -       2  smtp
    -o smtp_data_done_timeout=1200
    -o smtp_send_xforward_command=yes
    -o disable_dns_lookups=yes
    -o max_use=20

127.0.0.1:10025 inet n  -       y     -       -  smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Por último, en el fichero /etc/postfix/main.cf, indicaremos a Postfix que utilice un nuevo filtro de contenidos. Postfix redirigirá el tráfico al puerto 10024 de la interfaz loopback. Una vez amavisd-new haya finalizado su trabajo, devolverá el mensaje a Postfix a través del puerto 10025, donde hemos habilitado un smtpd.

content_filter=smtp-amavis:[127.0.0.1]:10024

Ahora tan sólo queda reiniciar el servidor Postfix mediante el comando:

/etc/init.d/postfix restart

Comprobación del funcionamiento

Para comprobar que Amavis está funcionando correctamente, podemos simular el envío de un correo electrónico al servicio amavisd-new y ver si termina siendo entregado a su destinatario a través de Postfix. Empezaremos con un sencillo mensaje de texto. Luego enviaremos un mensaje con el patrón EICAR de comprobación de virus que debería de ser reconocido fácilmente por Clam AntiVirus. Finalmente, enviaremos un mensaje con spam:

# telnet 127.0.0.1 10024
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready
MAIL FROM: <postmaster>
250 2.1.0 Sender postmaster OK
RCPT TO: <postmaster>
250 2.1.5 Recipient postmaster OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Amavis test
Este es un mensaje de pruebas enviado a traves de telnet.
.
250 2.6.0 Ok, id=03559-03, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as D5DB9C000740

MAIL FROM: <postmaster>
250 2.1.0 Sender postmaster OK
RCPT TO: <postmaster>
250 2.1.5 Recipient postmaster OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Amavis test (EICAR)
Este es un mensaje de pruebas enviado a traves de telnet con un patrón de virus EICAR.
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
.
250 2.6.0 Ok, id=03559-03-2, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 97D44C000740
QUIT
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel
Connection closed by foreign host.

El mensaje que nos devuelve el sistema tras el test de EICAR puede ser diferente no hemos configurado Amavis de la forma descrita en el artículo, pero sólo puede tener un formato parecido a uno de los siguientes (dependiendo del valor de la variable $final_virus_destiny y de la configuración de los virus_lovers):

550 5.7.1 Message content rejected, id=16968-01 - VIRUS: EICAR-AV-Test
250 2.5.0 Ok, but 1 BOUNCE
250 2.7.1 Ok, discarded, id=16984-01 - VIRUS: EICAR-AV-Test
250 2.6.0 Ok, id=17041-01, from MTA: 250 Ok: queued as 3F1841A5F5

Por ejemplo, con el valor D_REJECT de la variable $final_virus_destiny, se recibe:

554 5.7.1 Rejected, id=03902-03 - VIRUS: Eicar-Test-Signature

Para comprobar el funcionamiento de SpamAssassin deberemos de enviar un correo electrónico desde una cuenta de correo o dirección IP externa al sistema (que no forme parte la directiva mynetworks en /etc/postfix/main.cf). Para realizar esta prueba deberemos de asegurarnos de que la directiva smtpd_tls_auth_only en /etc/postfix/main.cf tenga el valor no, según lo explicado en el apartado de configuración de TLS/SSL, y que tenemos a mano la cadena de texto generada en ese mismo apartado usando Perl:

# /usr/bin/perl -MMIME::Base64 -e 'print encode_base64("username\0username\0password");'
anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI=
# telnet mail.dominio.com 25
Trying x.y.z.t...
Connected to mail.dominio.com.
Escape character is '^]'.
220 mail.dominio.com ESMTP Postfix (Debian/GNU)
EHLO dominio.com
250-mail.dominio.com
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
AUTH PLAIN anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI
235 2.0.0 Authentication successful
MAIL FROM: <postmaster>
250 2.1.0 Sender postmaster OK
RCPT TO: <postmaster>
250 2.1.5 Recipient postmaster OK
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Test spam mail (GTUBE)
Precedence: junk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
.
250 2.0.0 Ok: queued as D4107C00FD29
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

El mensaje que contiene el test antispam GTUBE (Generic Test for Unsolicited Bulk Email) debería de llegar a nuestra bandeja de entrada marcado con el prefijo ***SPAM*** y, entre otras, las siguientes cabeceras:

X-Virus-Scanned: Debian amavisd-new at mail.dominio.com
X-Spam-Flag: YES
X-Spam-Score: 1007.457
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=1007.457 tagged_above=2 required=6.31
        tests=[DNS_FROM_AHBL_RHSBL=0.306, DNS_FROM_RFC_ABUSE=0.479,
        DNS_FROM_RFC_DSN=2.872, DNS_FROM_RFC_POST=1.44, GTUBE=1000,
        MSGID_FROM_MTA_ID=0.927, NO_REAL_NAME=0.55, UNDISC_RECIPS=0.883]

Una vez que tenemos nuestra instalación de Amavis funcionando correctamente, podemos reducir la cantidad de información que se escribe en los logs de debug a info, tal y como se sugiere en el propio fichero /etc/amavis/conf.d/20-debian_defaults:

$syslog_priority = 'info';

Medidas antispam (anti-UCE) en Postfix

Las medidas anti-UCE (del inglés, Unsolicited Commercial Email) son una serie de mecanismos que se habilitarán en Postfix para filtrar el uso abusivo de nuestro servidor y tratar de denegar la entrada de una buena parte del correo no solicitado en él. En primer lugar, añadimos las siguientes líneas al fichero /etc/postfix/main.cf:

smtpd_helo_required = yes
disable_vrfy_command = yes
strict_rfc821_envelopes = yes

smtpd_recipient_restrictions =
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
        check_helo_access hash:/etc/postfix/helo_checks,
        check_helo_access pcre:/etc/postfix/helo_checks.pcre,
        reject_rbl_client relays.ordb.org,
        reject_rbl_client sbl.spamhaus.org,
#       check_policy_service inet:127.0.0.1:60000,
        permit

smtpd_data_restrictions =
        reject_unauth_pipelining,
        permit

Nota: la línea check_policy_service inet:127.0.0.1:60000, que indica a Postfix que haga uso del servidor de políticas del puerto 60000, está comentada porque Postgrey se instalará en el apartado siguiente.

De este modo, a falta de especificar los ficheros referenciados, establecemos el siguiente flujo en las restricciones aplicadas al smtp_recipient_restrictions (nótese que el orden es relevante):

  1. Las primeras sentencias nos aseguran que el proceso de HELO/EHLO y el envoltorio del mensaje son correctos. Y en la última deshabilitamos las verificaciones de direcciones de correo.
  2. Deshabilitamos la concatenación (del inglés, pipelining) de comandos (generalmente sólo los spammers tratan de concatenarlos, particularmente durante ataques de diccionario).
  3. Permitimos cualquier cosa que pase las restricciones de más arriba y que pertenezca a mynetworks (el destino no importa).
  4. Permitimos a los clientes que se han autenticado por SASL.
  5. Rechazamos clientes sin autenticar.
  6. Comprobamos ciertas direcciones de destinatarios antes de aplicar cualquier lista negra local o de DNS.
  7. Comprobamos las listas negras locales, las listas blancas locales y las listas negras y blancas combinadas (comnprobación de HELO/EHLO, remitente (origen en el envoltorio) y cliente (servidor que envía)).
  8. Comprobamos las listas negras de DNS y de hosts que permiten relay abiertamente.
  9. Comprobamos las listas grises de Postgrey (desactivado hasta el punto siguiente del artículo).

Sólo aparecen los dos servidores de listas negras de DNS y RHS que utilizo. El primero es el que, particularmente, considero mejor, pues es una base de datos de servidores que tienen relay abierto o activado (técnicamente es una respuesta de sí o no con criterios totalmente objetivos). Queda a merced del lector aplicar más o menos listas negras, pero, en cualquier caso, es muy recomendable pasarse primero por sus respectivas webs y tener bien claro qué criterios siguen para considerar a un servidor de correo como digno de aparecer en sus listas negras.

Mediante la directiva check_recipient_access aplicamos sobre el destinatario del mensaje las comprobaciones detalladas en el fichero /etc/postfix/recipient_checks.pcre, que se resumen en revisar la sintaxis de las direcciones:

# This file requires PCRE support built into Postfix
/^\@/           550 Invalid address format.
/[!%\@].*\@/    550 This server disallows weird address syntax.
/^postmaster\@/ OK
/^hostmaster\@/ OK
/^abuse\@/      OK

Nótese que para poder referenciar ficheros con expresiones regulares, por ejemplo en el /etc/postfix/main.cf la línea pcre:/etc/postfix/recipient_checks.pcre, es necesario tener instalado el paquete postfix-pcre. Por otra parte, las referencias del tipo dbm:/etc/postfix/helo_checks requieren de la ejecución del comando postmap <fichero> para que se cree el fichero en formato Berkeley Database con extensión .db.

En la directiva check_helo_access se lleva a cabo una comprobación muy sencilla pero muy eficiente a la hora de evitar el spam. El contenido de /etc/postfix/helo_checks es el que sigue:

# This file must be "compiled" with "postmap"
dominio.com              REJECT You are not in dominio.com
mail.dominio.com         REJECT You are not mail.dominio.com
x.y.z.t                  REJECT You are not x.y.z.t
localhost                REJECT You are not me

Aunque parezcan algo triviales, estas comprobaciones son enormemente efectivas y sencillas. Simplemente se verifica que el comando HELO/EHLO enviado por el host que se conecta a nuestro servidor no use ni nuestro dominio, ni nuestra IP pública o privada, ni localhost. Otra comprobación que podría hacerse sobre el comando HELO/EHLO sería la de la sintaxis del host, que debe cumplir el estándar del RFC. Editamos el fichero /etc/postfix/helo_checks.pcre y le añadimos el siguiente contenido:

# This file requires PCRE support built into Postfix
/^[0-9]+(\.[0-9]+){3}$/      REJECT Invalid hostname

Con la directiva check_sender_access podemos realizar comprobaciones sobre el remitente del mensaje. En mi caso particular, este fichero únicamente contiene el comentario inicial, pues no le doy uso alguno, pero puede que el lector quiera darle algún tipo de uso parecido al que se propone a continuación para /etc/postfix/sender_checks:

# This file must be "compiled" with "postmap"
spammers.com                 554 Spam not tolerated here
[email protected]    OK
morespammers.com             REJECT

Según este contenido, rechazaríamos todo el correo de los dominios spammers.com y morespammers.com excepto el del usuario [email protected].

Mediante la directiva check_client_access podemos realizar comprobaciones sobre el cliente que envía el mensaje. En el main.cf propuesto más arriba aparecen dos referencias a esta directiva, una usando una tabla de hashing y otra expresiones regulares. El autor del artículo tampoco las usa en estos momentos, y los ficheros no contienen más que la línea de comentario inicial pero, de todas maneras, a continuación se proponen posibles usos. Este sería un ejemplo de contenido para el fichero /etc/postfix/client_checks:

# This file must be "compiled" with "postmap"
spammers.com                 554 Spam not tolerated here
10                           554 Go away!
myfriendsdomain.com          OK
172.16                       OK

De este modo, pese a que el dominio myfriendsdomain.com y la IP 172.11.0.0/16 pertenezcan a listas negras, nosotros decidimos aceptar los accesos que venga de ellos. Asimismo, rechazamos todas las conexiones que provengan del dominio spammers.com y del rango de IPs 10.0.0.0/8. Con expresiones regulares podemos conseguir resultados más complejos, como los del fichero /etc/postfix/client_checks.pcre:

# This file requires PCRE support built into Postfix
/10\.9\.8\.7/            OK
/10\.9\.([89]|10)\.\d+/  554 Go away. We don't want any!

Esta expresión regular rechazaría las conexiones desde el rango 10.9.8.0 - 10.9.10.255 excepto la dirección 10.9.8.7.

Tras ejecutar los comandos postmap necesarios sobre los ficheros hash tan sólo nos queda reinicar Postfix con el comando:

/etc/init.d/postfix restart

Terminología y notas acerca de las restricciones y las listas de acceso

HELO/EHLO es lo que la máquina que envía le dice que es a nuestra máquina. Puede disfrazarse fácilmente y frecuentemente se configura de manera incorrecta. HELO/EHLO se comprueba a través de las restricciones en el helo y el hostname del smtpd.

Sender es el envoltorio de la dirección remitente (Mail From en la comunicación SMTP), no la dirección IP de la máquina cliente ni su hostname, ni tampoco el campo From: de las cabeceras (aunque el envoltorio del remitente perfectamente puede ser el mismo que el From: de las cabeceras). Sender se comprueba mediante las restricciones del remitente en el smtpd.

Client es la dirección IP de la máquina que realiza el envío, y posiblemente el hostname (si puede obtenerse alguno de la resolución inversa de la dirección IP). Client se comprueba con las restricciones del cliente en el smtpd.

Recipient hace referencia a la dirección de correo pasada en el comando RCPT TO durante la comunicación SMTP, no el To: ni el Ccc: u otros campos de las cabeceras. Recipient se comprueba mediante las restricciones del destinatario en el smtpd.

Si se sitúan las listas de acceso antes de las comprobaciones de listas negras de DNS, tal y como se muestra en la configuración del main.cf más arriba, pueden servir tanto como listas negras que como listas blancas. Pero es muy importante ser cauteloso a la hora de usar las listas blancas pues, por ejemplo, si se le da el OK a algo en la directiva smtpd_recipient_restrictions antes del reject_unauth_destination, podríamos dejar el servidor haciendo relay abierto para todo aquel que tenga el OK, o a los que sean falsificables.

Postgrey

Acerca de Postgrey

Postgrey (Postfix Greylisting Policy Server) es un servidor de políticas para Postfix que implementa listas grises (del inglés, greylisting) desarrollado por David Schweikert del ISG.EE. Cuando Postfix recibe una petición de envío de un correo electrónico via SMTP, éste construye el trío IP del cliente, remitente y destinatario. Si es la primera vez que se tiene constancia de esta combinación o si la primera vez que se vio fue hace menos de 5 minutos, entonces el correo es rechazado con un código de error temporal. Es de esperar que los servidores que envían correo no deseado o virus no reintentarán el envío, aunque es un requerimiento estándar según el RFC (del inglés, Request For Comments). El siguiente gráfico muestra la efectividad de Postgrey:

Efectividad de Postgrey

Instalación y configuración

La instalación y configuración de Postgrey es muy sencilla. En primer lugar instalamos el paquete postgrey, que ya nos deja una configuración satisfactoria para nuestras necesidades:

apt-get install postgrey

Y en segundo lugar, tal y como se comenta en el punto anterior de este tutorial, descomentamos la línea siguiente de la directiva smtpd_recipient_restrictions del fichero /etc/postfix/main.cf:

check_policy_service inet:127.0.0.1:60000

Finalmente, solicitamos al daemon de Postfix que recargue la configuración:

/etc/init.d/postfix reload

Mailman

Acerca de Mailman

Mailman es un software libre que permite gestionar listas de distribución, noticias y correo electrónicos. Mailman está integrado con la web, permitiendo a sus usuarios una fácil administración de sus cuentas, así como a sus propietarios administrar las listas. Mailman incluye soporte para crear archivos de correos, procesamiento automático de correo rechazado, filtrado de contenido, envío en modo compendio o resumen, filtros de spam, etc.

Instalación y configuración

A continuación se instalará y configurará Mailman para ser accedido a través de https y se integrará con Postfix. Aún así, tras la instalación del paquete, es conveniente leer la documentación disponible en /usr/share/doc/mailman , principalmente en /usr/share/doc/mailman/README.Debian.gz y en /usr/share/doc/mailman/README.POSTFIX.gz . En ella se detallan las modificaciones necesarias en Apache para el correcto funcionamiento de la interfaz web, así como la forma de integrar Postfix y Mailman. Acto seguido se va a configurar mailman, integrándolo con Postfix, para el dominio local.

Primero procederemos a instalar el paquete Debian de Mailman mediante el comando:

apt-get install mailman

Editaremos ahora el fichero del site de Apache que hemos venido configurando durante el tutorial, /etc/apache2/sites-available/mail.dominio.com y añadiremos las siguientes directivas:

ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/
Alias /pipermail/ /var/lib/mailman/archives/public/
Alias /images/mailman/ /usr/share/images/mailman/

Una solicitud de recarga de configuración a Apache bastará para activar los cambios:

/etc/init.d/apache2 reload

Luego pasaremos a modificar el fichero /etc/mailman/mm_cfg.py de Mailman, del cuál modificaremos las dos siguientes variables:

DEFAULT_URL_PATTERN = 'https://%s/mailman/'
MTA='Postfix'

Forzamos a Mailman que genere los alias mediante la ejecución del script genaliases:

/var/lib/mailman/bin/genaliases

Y pasamos a modificar la configuración de Postfix para integrar ambos programas. Añadiremos o modificaremos los siguientes parámetros en el fichero /etc/postfix/main.cf:

alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
mailman_destination_recipient_limit = 1
unknown_local_recipient_reject_code = 550
owner_request_special = no
recipient_delimiter = +

Solicitando a Postfix que recargue la configuración y regenerando los alias habremos terminado con Postfix:

/etc/init.d/postfix reload
newaliases

La instalación de Mailman nos avisa de que es necesario crear una site list llamada mailman y que hasta que no la creemos el daemon del Mailman no arrancará. Ahora es el momento de crearla y, para ello, ejecutamos el siguiente comando:

# newlist mailman
Enter the email of the person running the list: [email protected]
Initial mailman password:
Hit enter to notify mailman owner...

Nota: Es muy recomendable usar una contraseña temporal pues se manda por email. Más adelante podemos cambiarlo a uno definitivo y dejar la opción Send monthly reminders desactivada. Arrancamos el daemon:

/etc/init.d/mailman start

Y ya podemos cargar la página web de gestión de listas de Mailman:

https://mail.dominio.com/mailman/admin/mailman/

Nótese que las listas creadas lo serán sobre el dominio local mail.dominio.com. Si creamos la lista marketing, el email al cual deberemos mandar será [email protected]. Pero podemos usar OpenMailAdmin para establecer alias sobre la cuenta postmaster usando la pestaña Addresses, de modo que el correo a [email protected] se redirija a [email protected] y así hacer las cosas más fáciles para los usuarios.

SquirrelMail y plug-ins

Acerca de SquirrelMail

SquirrelMail es un paquete de correo por web basado en estándares y escrito en PHP 4. Incorpora soporte PHP para los protocolos IMAP y SMTP, y todas sus páginas se crean en puro HTML 4.0 (sin requerir el uso de JavaScript), de modo que se garantize la máxima compatibilidad entre navegadores. Tiene muy pocos requerimientos y es muy fácil de instalar y configurar. SquirrelMail tiene toda la funcionalidad que se espera de un cliente de correo electrónico, incluyendo soporte de MIME, agendas de contactos y gestión de carpetas.

Instalación y configuración

Si bien es, estrictamente hablando, suficiente con la instalación del paquete squirrelmail, es recomendable instalar los paquetes squirrelmail-locales (para el soporte multiidioma) y php5-recode (soporte para la recodificación de juegos de caracteres en PHP):

apt-get install squirrelmail squirrelmail-decode squirrelmail-locales php5-recode

Debemos cambiar algunos parámetros de configuración de SquirrelMail para adaptarlos a nuestra instalación. Ejecutamos el script de configuración de que viene con el paquete:

/usr/sbin/squirrelmail-configure

Y utilizamos el juego de valores predefinidos para Cyrus:

Set pre-defined settings for specific IMAP servers = cyrus

Si, y sólo si, se estableció la direciva unixhierarchysep: yes en /etc/imapd.conf, entonces será necesario realizar también los siguientes cambios:

Server Settings: Update IMAP Settings: Delimiter = /
Folder Defaults: Trash Folder = INBOX/Trash
Folder Defaults: Sent Folder = INBOX/Sent
Folder Defaults: Drafts Folder = INBOX/Drafts

Opcionalmente, podemos cambiar también:

Organization Preferences: Organization Name
Organization Preferences: Organization Logo
Organization Preferences: Organization Title
Message of the Day (MOTD): Edit the MOTD

Las imágenes usadas por Squirrelmail (p.e. el logo usado en Organization Preferences: Organization Logo) están guardadas en la ruta /usr/share/squirrelmail/images con permisos 0644 para el usuario root y grupo root, aunque también puede usarse una URL absoluta. El siguiente paso es modificar Apache para poder acceder a SquirrelMail a través suyo. Editamos /etc/apache2/sites-available/mail.dominio.com:

Alias /squirrelmail /usr/share/squirrelmail
<Directory /usr/share/squirrelmail>
    <IfModule mod_php5.c>
        php_flag register_globals off
    </IfModule>
    Options Indexes FollowSymLinks
    <IfModule mod_dir.c>
        DirectoryIndex index.php
    </IfModule>
    # access to configtest is limited by default to prevent information leak
    <Files configtest.php>
        Order Deny,Allow
        Deny From All
        Allow From 127.0.0.1
        Allow From x.y.z.t
    </Files>
</Directory>

Recargamos la configuración de Apache para que surjan efecto los cambios:

/etc/init.d/apache2 reload

Y ya podemos acceder a nuestro correo por interfaz web:

https://mail.dominio.com/squirrelmail/

Habitualmente, los usuarios preferirán un acceso tipo https://webmail.dominio.com/. Para ésto será necesario configurar la entrada pertinente en la zona de DNS (no incluida en el artículo, pues no es su propósito) y otro dominio virtual de Apache de similares características al que se usa en este artículo:

<VirtualHost *>
        ServerName webmail.dominio.com
        <IfModule mod_rewrite.c>
                RewriteEngine on
                RewriteCond %{HTTP_HOST} ^webmail\.dominio\.com$ [NC]
                RewriteRule ^(.*)$ https://mail.dominio.com/squirrelmail/$1 [R=301,L]
        </IfModule>
</VirtualHost>

Antes de solicitar a Apache que recargue la configuración deberemos asegurarnos de que mod_rewrite está instalado:

# a2enmod rewrite
Module rewrite installed; run /etc/init.d/apache2 force-reload to enable.
# /etc/init.d/apache2 force-reload
Forcing reload of web server (apache2)... waiting .

De este modo nos aseguramos un acceso siempre sobre canal cifrado y aprovechamos el certificado que hemos creado con anterioridad para el dominio mail.dominio.com.

Acerca de SIEVE

SIEVE es un lenguaje que puede usarse para crear filtros de correo electrónico en el momento de la entrega final del correo (en el lado del servidor). No está ligado a ningún sistema operativo o servidor de correo en particular. Requiere el uso de la especificación de mensajes del RFC 822. El lenguaje es suficientemente potente para ser útil, pero está limitado de modo que permita la creación de sistemas de filtrado seguros en el lado del servidor. El objetivo es no permitir a los usuarios hacer nada más complejo (y peligroso) que escribir sencillos filtros de correo, además de facilitar editores basados en interfaces gráficas de usuario. El lenguaje no permite definir bucles o funciones, ni tampoco proporciona variables.

Se supone que el uso del lenguaje tiene lugar al final de la entrega, cuando el mensaje se mueve a una cuenta accesible por el usuario. En aquellos sistemas donde el MTA (Mail Transport Agent) realiza la entrega final (como es tradicional en los sistemas UNIX), es razonable clasificar cuando el MTA deposita el correo en la cuenta del usuario. Sin embargo, los filtros Sieve pueden ser usados por varios "puntos finales de entrega" del sistema de correo: por el servidor SMTP, por un servidor IMAP o POP que archive una o más cuentas de usuario, o por un cliente de correo (MUA, Mail User Agent) que actúe como gestor de las entregas (por ejemplo, un cliente POP o IMAP sin conexión).

Avelsieve (SIEVE Mail Filters Plugin for SquirrelMail) es un plugin para SquirrelMail que permite crear scripts hechos con Sieve en un servidor Cyrus IMAP que tenga habilitado el soporte para dicho lenguaje (Tim's SIEVE daemon). Avelsieve es parte de Cyrusmaster, una herramienta de administración de Cyrus basada en web. Debería proporcionar una interfaz similar a la de los filtros de usuario a los administradores y personal de soporte técnico.

Instalación y configuración

Para gestionar los scripts de SIEVE podemos usar el plug-in de SquirrelMail Avelsieve - SIEVE Mail Filters'. Los siguientes comandos lo descargarán de su página web de descargas y lo instalarán en el directorio de SquirrelMail:

cd /usr/share/squirrelmail/plugins/
wget http://email.uoa.gr/download/squirrelmail/avelsieve/avelsieve-1.9.7.tar.gz
tar -xzf avelsieve-1.9.7.tar.gz
rm --force avelsieve-1.9.7.tar.gz
chown --recursive root.root avelsieve/
cp --archive avelsieve/config/config_sample.php avelsieve/config/config.php

Tan sólo nos queda activar el plug-in usando el script de configuración de SquirrelMail /etc/squirrelmail/conf.pl. En su sección Plugins: avelsieve. Asimismo, podemos editar el fichero de configuración /usr/share/squirrelmail/plugins/avelsieve/config/config.php y cambiar las opciones que deseemos.

Plugin de Squirrelmail para cambiar la contraseña

A fin de centralizar en un único punto las herramientas de gestión necesarias para el usuario final, vamos a instalar el plug-in Change SQL Password para Squirrelmail. Si bien es cierto que OpenMailAdmin permite a los usuarios creados validarse y cambiar su contraseña, considero preferible mantener el acceso a esta herramienta lo más restringido posible (sólo administradores). El plug-in Change SQL Password requiere a su vez la librería PEAR de PHP, ya instalada, y el plug-in Compatibility para Squirrelmail. Ambos plug-ins los instalaremos a la vez en los siguientes pasos:

cd /usr/share/squirrelmail/plugins/
wget http://www.squirrelmail.org/plugins/compatibility-2.0.9-1.0.tar.gz
tar -xzf compatibility-2.0.9-1.0.tar.gz
rm --force compatibility-2.0.9-1.0.tar.gz
chown --recursive root.root compatibility/
patch -s -p1 < compatibility/patches/compatibility_patch-1.4.9.diff

wget http://www.squirrelmail.org/plugins/change_sqlpass-3.3-1.2.tar.gz
tar -xzf change_sqlpass-3.3-1.2.tar.gz
rm --force change_sqlpass-3.3-1.2.tar.gz
chown --recursive root.root change_sqlpass/
cp --archive change_sqlpass/config.php.sample change_sqlpass/config.php

A continuación editamos el fichero change_sqlpass/config.php, modificando las siguientes directivas para ajustarlo a nuestra configuración:

$csp_dsn = 'mysql://postfix:<my_passwd>@127.0.0.1/postfix';
$lookup_password_query = 'SELECT count(*) FROM user WHERE mbox = "%2" AND password = %4';
$password_update_queries = array('UPDATE user SET password = %4 WHERE mbox = "%2"');
$password_encryption = 'MD5';
$csp_salt_static = 'LEFT(password, 2)';
$csp_secure_port = 443;

Opcionalmente, podemos ajustar a nuestro gusto el valor de los siguientes parámetros (se muestran los valores por defecto):

$min_password_length = 6;
$max_password_length = 0;
$include_digit_in_password = 0;
$include_uppercase_letter_in_password = 0;
$include_lowercase_letter_in_password = 0;
$include_nonalphanumeric_in_password = 0;

Respectivamente, representan la longitud mínima de una contraseña, la longitud máxima, la obligatoriedad de incluir al menos un dígito, una letra en mayúsculas, una letra en minúsculas y un caracter no alfanumérico. Las cuatro últimas se activan cambiando el valor 0 por 1. Finalmente, activamos el plug-in en la configuración de Squirrelmail mediante el script /etc/squirrelmail/conf.pl.

Mostrar la cuota de correo del usuario

Otro plug-in particularmente interesante es el plug-in Check Quota para Squirrelmail, que comprueba y muestra el estado de la cuota de usuario. Se muestra el uso actual y el máximo disponible en un formato gráfico fácil de interpretar. Opcionalmente, también se pueden mostrar avisos a usuarios que estén a punto de alcanzar el máximo disponible cuando se validen en el sistema (en el lugar donde se muestra el Mensaje del día). Este plug-in requiere también el plug-in Compatibility para Squirrelmail, instalado en el punto anterior junto con el plug-in Change SQL Password. Para instalar el plug-in seguiremos los siguientes pasos:

cd /usr/share/squirrelmail/plugins/
wget http://www.squirrelmail.org/plugins/check_quota-2.2-1.4.0.tar.gz
tar -xzf check_quota-2.2-1.4.0.tar.gz
rm --force check_quota-2.2-1.4.0.tar.gz
chown --recursive root.root check_quota/
cp --archive check_quota/config.sample.php check_quota/config.php

Editamos el fichero check_quota/config.php y modificamos la siguiente línea:

$settings['quota_type'] = 1;

Por defecto se usan tablas de HTML para mostrar la información, pero la presentación mejora muchísimo si usamos un gráfico. Para ello deberemos instalar la librería gráfica GD y modificar el valor de la variable $settings['graph_type']. Empezamos instalando el paquete php5-gd en el sistema:

apt-get install php5-gd

Y modificamos la siguiente línea en el fichero check_quota/config.php:

$settings['graph_type'] = 1;

Finalmente, tan sólo nos queda acceder al script de Perl de configuración de Squirrelmail /etc/squirrelmail/conf.pl y activar el plug-in.

Mailgraph

Acerca de Mailgraph

Mailgraph es un frontend muy sencillo de estadísticas de correo electrónico generadas con RRDtool para Postix y Sendmail que produce gráficos diarios, mensuales y anuales de todo el correo recibido, enviado, rechazado y rebotado.

Instalación y configuración

La instalación consta de dos pasos. El primero es la instalación del paquete:

apt-get install mailgraph

Respecto de las dos cuestiones que nos planteará el instalador, nos interesa que Mailgraph arranque como daemon al iniciarse el sistema y no nos interesa contar el correo entrante como saliente, pues estamos usando filtros de contenidos. Y el segundo paso será congigurar Apache para hacer accesible Mailgraph. Editamos el fichero de configuración de nuestro dominio, /etc/apache2/sites-available/mail.dominio.com, y añadimos la siguiente directiva:

ScriptAlias /mailgraph/ /usr/lib/cgi-bin/

Solicitamos a Apache que recargue la configuración:

/etc/init.d/apache2 reload

Y ya podemos acceder a las gráficas mediante la URL siguiente:

https://mail.dominio.com/mailgraph/mailgraph.cgi

La versión de Mailgraph que hay en el repositorio de Debian Etch es la 1.12-2.1. Debido a que la versión de Amavis es la 2.4.2-6.1 y el autor de Mailgraph, David Schweikert, mejoró el soporte para versiones de Amavis 2.4 y superiores en Mailgraph 1.13 (con correcciones en la 1.14), es conveniente actualizar la versión de Mailgraph a la actual, la 1.14 en el momento de escribir este artículo. Dada la sencillez de esta herramienta, con unos sencillos pasos conseguiremos este objetivo:

cd /root
wget http://mailgraph.schweikert.ch/pub/mailgraph-1.14.tar.gz
tar -xzf mailgraph-1.14.tar.gz
chown --recursive root:root mailgraph-1.14/
cp --archive mailgraph-1.14/mailgraph.cgi /usr/lib/cgi-bin/
cp --archive mailgraph-1.14/mailgraph.pl /usr/sbin/mailgraph
cp --archive mailgraph-1.14/mailgraph.css /usr/lib/cgi-bin/
cp --archive mailgraph-1.14/README /usr/share/doc/mailgraph/
rm --force --recursive mailgraph-1.14

Editamos el fichero /usr/lib/cgi-bin/mailgraph.cgi y modificamos los valores de las variables $rrd, $rrd_virus y $tmp_dir según sigue:

my $rrd = '/var/lib/mailgraph/mailgraph.rrd'; # path to where the RRD database is
my $rrd_virus = '/var/lib/mailgraph/mailgraph_virus.rrd'; # path to where the Virus RRD database is
my $tmp_dir = '/var/lib/mailgraph'; # temporary directory where to store the images

Editamos el fichero de configuración de Apache de nuestro dominio, /etc/apache2/sites-available/mail.dominio.com, y añadimos una nueva directiva en la sección para Mailgraph que habíamos editado anteriormente, de modo que quede como sigue:

Alias /mailgraph/mailgraph.css /usr/lib/cgi-bin/mailgraph.css
ScriptAlias /mailgraph/ /usr/lib/cgi-bin/

El orden es relevante. Finalmente, recargamos la configuración de Apache y reiniciamos el daemon de Mailgraph:

/etc/init.d/apache2 reload
/etc/init.d/mailgraph restart

Perspectiva general, conceptos y administración del servidor Cyrus IMAP

Debido a que usaremos OpenMailAdmin para gestionar los usuarios, buzones y permisos del servidor, no será necesario usar la consola a menos que necesitemos una configuración específica. Si ese fuera el caso, podremos acceder a la interfaz de comandos para la gestión del servidor Cyrus IMAP mediante una llamada a cyradm, tal que:

cyradm --user cyrus --server localhost --auth login
Password:
localhost>

En los siguientes puntos se introducirá al lector en los conceptos básicos de Cyrus IMAP y en el uso de la herramienta cyradm.

Espacio de nombres de los buzones de correo

El servidor Cyrus IMAP presenta los buzones de correo usando la convención netnews. Si bien en los nombres de los buzones no se hace distinción entre mayúsculas y minúsculas, se mantiene el formato en el cual se creó. Un nombre de buzón no puede comenzar o terminar con punto, ni tampoco puede contener dos puntos seguidos. Todos los buzones de correo del usuario jsabater comienzan con la cadena user.jsabater (o user/jsabater si se ha definido la directiva unixhierarchysep: yes en /etc/imapd.conf). Desde el punto de vista del usuario jsabater, el buzón user.jsabater es lo que se conoce como su inbox o buzón de entrada. Si la lista de control de acceso del buzón de correo user.jsabater permite a otros usuarios ver dicho buzón, aparecerá a esos otros usuarios como user.jsabater. En este documento se hace referencia al buzón de correo user.jsabater como el inbox de jsabater.

El administrador crea y borra usuarios al crear y borrar los inbox de esos usuarios. Si un usuario tiene inbox, entonces puede suscribirse a los buzones de correo. Sólo los usuarios sin puntos en su identificador de usuario poseen la capacidad de tener un inbox (un usuario con un punto en su identificador podría hacer login pero no sería capaz de recibir correo). Cuando un administrador borra el inbox de un usuario, todos los buzones de correo personales de ese usuario se borran también.

Con la notable excepción del inbox, todos los nombres de buzones de correo pertenecen al sistema, independientemente del sistema. Son las listas de control de acceso las que determinan qué usuarios tienen qué permisos sobre qué buzones.

Listas de control de acceso

El acceso a cada buzón de correo se controla desde la lista de control de acceso de cada buzón. Las ACLs (del inglés, Access Control List), proporcionan un poderoso mecanismo para especificar los usuarios o grupos de usuarios que tienen permisos para acceder a los buzones de correo.

Una ACL es una lista de cero o más entradas. Cada entrada tiene un identificador y una serie de permisos. El identificador especifica el usuario o grupo de usuarios para el cuál la se aplica la entrada. El conjunto de permisos está formado por una o más letras o digítos, cada uno de ellos otorgando un privilegio en particular. Desde la opción Folders de OpenMailAdmin podremos gestionar las ACLs de cada buzón.

Folders management from OpenMailAdmin

Los permisos definidos son:

El identificador es la parte en una ACL que especifica el usuario o grupo para el cuál se aplica. El significado del identificador habitualmente depende del mecanismo de autorización que se use. Con cualquiera que sea el mecanismo de autorización, existen siempre dos identificadores especiales. El identificador anonymous hace referencia al usuario anónimo, no autenticado. El identificador anyone hace referencia a cualquier usuario, incluyendo al usuario anónimo.

Independientemente de la ACL de un buzón, los usuarios administradores (es decir, los que aparecen en la opción admins del fichero /etc/imapd.conf) siempre tienen los permisos l y a sobre todos los buzones de manera implícita. Cuando se crea un buzón de correo, su ACL inicial es una copia de la ACL de su buzón padre. Cuando se crea un usuario, la ACL del inbox de ese usuario contiene una única entrada con todos los permisos garantizados para el propietario. Cuando se crea un buzón de correo no asociado a un usuario que no tiene padre, su ACL se inicializa a valor de la opción defaultacl del fichero /etc/imapd.conf.

Para crear un inbox para el usuario jsabater en el defaultdomain (dominio local):

cm user.jsabater

OpenMailAdmin permite gestionar los buzones de usuarios automáticamente, por lo que normalmente no será necesario usar el comando cm.

Cuotas de usuario

El servidor Cyrus IMAP soporta cuotas de almacenamiento, que también pueden gestionarse a través de OpenMailAdmin, definidas como el número de bytes de los mensajes RFC-822, en kilobytes. Cada mensaje se cuenta independientemente, incluso si el servidor es capaz de ahorrar espacio con el uso de enlaces duros a los ficheros de mensajes. El espacio adicional requerido para almacenar el índice del buzón y la caché de los ficheros no se tiene en cuenta para calcular la cuota.

Las cuotas se aplican a las cuotas raíz, que pueden estar en cualquier nivel de la jerarquía de buzones. Las cuotas raíz no es necesario que sean buzones. Las cuotas en una cuota raíz se aplican a la suma del uso de todo buzón que se encuentre al mismo nivel o por debajo en la jerarquía y que no esté bajo otra cuota raíz en la subjerarquía. Esto significa que cada buzón se ve limitado por una cuota raíz como máximo.

Por ejemplo, dados los buzones:

user.jsabater
user.jsabater.lists.bulmailing
user.jsabater.lists.postfix-users
user.jsabater.todo
user.jsabater.work
user.jsabater.work.customers
user.jsabater.work.suppliers

Y cuotas raíz en:

user.jsabater
user.jsabater.lists
user.jsabater.work

Entonces, la cuota raíz user.jsabater se aplicaría a los buzones user.jsabater y user.jsabater.todo, la cuota raíz user.jsabater.lists tendría efecto sobre los buzones user.jsabater.lists, user.jsabater.lists.bulmailing y user.jsabater.lists.postfix-users y la cuota raíz user.jsabater.work se aplicaría sobre los buzones user.jsabater.work, user.jsabater.work.customers y user.jsabater.work.suppliers.

Las cuotas raíz se crean mediante el comando setquota de la utilidad de consola cyradm. Las cuotas raíz no se pueden eliminar mediante comandos, sino que deben borrarse los ficheros pertinentes, tal y como se explica más adelante en este documento.

OpenMailAdmin mailboxes administration

Normalmente, para que un mensaje pueda insertarse en un buzón, la cuota raíz de ese buzón debe tener suficiente espacio sin usar para que la inserción de dicho mensaje no provoque que la cuota se sobrepase. Pero el envío de correo es un caso especial. Para que un mensaje pueda ser entregado en un buzón, el uso de la cuota raíz del buzón no debe superior a lo permitido. Si el uso no sobrepasa el límite, entonces un mensaje puede ser entregado independientemente de su tamaño. Esto provoca que el buzón sobrepase la cuota, causando que el usuario sea informado de dicho problema y dándole la oportunidad de que lo arregle. Si no se permitiera la entrega en estos casos, el usuario no tendría manera práctica de saber que hubo correo que no pudo ser entregado.

Si el uso está por encima del límite, entonces el envío del correo fallará, retornando un error temporal. Esto hará que el sistema de envío reintente la entrega durante un par de días (permitiendo al usuario darse cuenta del problema y corregirlo) y luego devolverá el correo al remitente.

Procesos de recuperación de las bases de datos

Reconstrucción de los directorios de buzones. La base de datos más grande del sistema Cyrus son los directorios de buzones. Cada directorio de un buzón contiene los siguientes ficheros.

El programa reconstruct (cyrreconstruct en Debian GNU/Linux) puede usarse para reconstruir estos ficheros en caso de que estén corruptos. Siempre que puedan encontrarse ficheros de índice y de encabezados, se intentará salvaguardar la información en ellos existente y que no sea deducible de los propios ficheros de mensajes. El programa reconstruct intenta preservar los nombres de los flags, el estado de esos flags y la fecha interna. El resto de información se obtiene de los ficheros de mensajes. Así pues, el administrador de sistemas puede recuperar los datos de un disco dañado con tan sólo restaurar los ficheros de mensajes de una copia de seguridad y ejecutando reconstruct para generar de nuevo los ficheros de control. Nótese que el programa reconstruct no ajusta el uso de la cuota en los ficheros de cuotas raíz. Tras ejecutar reconstruct, es aconsejable ejecutar quota -f (descrito más abajo) para ajustar la cuota a partir de los ficheros de cuota raíz.

Reconstrucción de las cuotas raíz. El subdirectorio quota del directorio de configuración (especificado en la directiva configdirectory) contiene un fichero por cuota raíz, con el nombre de fichero indicando el nombre de la cuota raíz. Estos ficheros almacenan el uso de la cuota y los límites de cada cuota raíz. El programa quota, al ser invocado con el parámetro -f, recalcula la cuota raíz de cada buzón y el uso de cada cuota raíz. Para eliminar una cuota raíz, basta borrar el fichero de la cuota raíz. Luego ejecútese quota -f para devolver la consistencia a los ficheros de cuotas.

El fichero de buzones

El fichero de buzones del directorio de configuración es el fichero más crítico de todo el sistema Cyrus IMAP. Contiene una lista ordenada con cada buzón del servidor, así como los buzones cuotas raíz y las ACL. Debido a que la ACL es información crítica de seguridad, no puede ser reconstruida a partir de la información guardada en cualquier otro lado. No hay ningún programa para reconstruir un fichero de buzones dañado.

Para proteger los contenidos de los buzones, es recomendable realizar una copia de seguridad frecuentemente, incluso cada pocas horas, a otra parte del disco (u otro disco).

Suscripciones

El subdirectorio user del directorio de configuración contiene las suscripciones de los usuarios. Existe un fichero por usuario, con un nombre de fichero formado por el identificador de usuario y la extensión .sub. Cada fichero contiene una lista ordenada de los buzones a los que está suscrito. No existe programa alguno para recuperar ficheros de suscripciones dañados. Un sistema puede recuperar los ficheros perdidos simplemente restaurándolos de las copias de seguridad.

Logging

El subdirectorio log bajo el directorio de configuración permite a los administradores mantener logs por usuario. Si existe un subdirectorio de log con el nombre de un usuario, entonces los servidores IMAP y POP3 mantendrán un log de las sesiones que se han autenticado como ese usuario. El log de telemetría se guarda en el subdirectorio con el nombre de fichero del identificador de proceso del servidor y empieza con el primer comando tras la autenticación.

El servidor IMAP Cyrus envía mensajes de log al syslog local. Los niveles de gravedad usados son:

El directorio proc

El subdirectorio proc dentro del directorio de configuración contiene un fichero por cada proceso activo del servidor. El nombre de fichero es la representación ASCII del identificador de proceso y cada fichero contiene los siguientes campos, separados por tabuladores:

Normalmente el subdirectorio proc es purgado al reiniciar el servidor.

Notas

Puertos en un cortafuegos

La configuración de un cortafuegos no implica dificultad alguna. A modo de resumen, acto seguido se listan todos los puertos que es necesario tener abiertos en las interfaces externas (se da por supuesto que la interfaz loopback no tiene restricción alguna):

Request For Comments (RFC)

Los RFC que definen todas las tecnologías usadas en el artículo están disponibles en diversos sitios web, como RFC Editor o Internet RFC/STD/FYI/BCP Archives. Las ideas iniciales y en desarrollo aparecen primero como borradores y son más tarde formalizadas como RFC. A continuación se listan algunos de los más relevantes que hacen referencia a los formatos y protocolos usados en este artículo:

Preguntas frecuentes

P: ¿Puede Postfix consultar directamente la base de datos MySQL?
R: No

P: ¿Por qué se usa libpam-mysql si saslauthd soporta SQL nativamente?
R: Porque saslauthd sólo soporta contraseñas no cifradas y se utiliza una base de datos en el sistema de autenticación. Esa es la razón por la que se combina con PAM. PAM, en cambio, puede usar cualquier cosa.

P: He leído que /etc/postfix/sasl/smtpd.conf debería contener pwcheck_method: pam.
R: Eso es cierto para versiones de SASL anteriores a la 2. Ahora hay que usar saslauthd.

P: ¿Por qué hay que ejecutar saslauthd con el parámetro -r?
R: Para que la ruta de retorno sea correcta y para que, en un futuro, cuando los usuarios se autentiquen como [email protected], no haya que modificarlo. Si tienes problemas, no te olvides de monitorizar /var/log/auth.log.

P: ¿Por qué se mueve el socket de saslauthd a /var/spool/postfix/var/run/saslauthd?
R: Porque el servicio smtp se ejecuta enjaulado (del inglés, chroot'ed).

P: ¿Por qué se ha añadido etc/postfix/sasl/smtpd.conf a la variable FILES?
R: Porque Postfix necesita acceder al fichero desde dentro de la jaula. El script en /etc/init.d copia la última versión de ese fichero dentro de la jaula cada vez que se reinicia el servicio.

P: ¿Cómo funciona la cadena de autenticación?
R: Postfix se conecta a saslauthd a través del socket, el cuál solicita a PAM que autentique el usuario, la cuál consulta la tabla adecuada de la base de datos de MySQL.

P: ¿Por qué se utiliza 127.0.0.1 en lugar de localhost en la configuración de Postfix?
R: Para que se use un socket de TCP en lugar de un socket UNIX. De este modo no tenemos que mover el socket de MySQL dentro de la jaula de Postfix.

Bibliografía

Historial de revisiones

Fecha Versión Cambios
2006/10/08 1.0 Documento inicial.
2006/11/08 1.1 Añadidos los apartados 18, 19 y 20.
2007/06/14 1.1.1 Añadido el paquete dpkg-dev en la instalación de libpam-mysql. Añadida la corrección en la línea 60 del fichero debian/rules durante la compilación de libpam-mysql para que no dé error de compilación en la arquitectura x86.
2007/10/26 1.2 Actualizado el artículo a las versiones finales de los paquetes en Debian Etch, a la versión 1.0 de OpenMailAdmin y a la versión 1.14 de Mailgraph. Añadida información básica de cómo utilizar los servicios de CACert.org en el apartado 5. Añadidos varios plug-ins de Squirrelmail.
2007/11/19 1.2.1 Añadido el fichero /etc/apt/sources.list usado al principio del documento, principalmente para que conste el uso del proyecto Debian Volatile.

Volver a la página de inicio