servidor de correo con postfix
TRANSCRIPT
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
Página 1 de 46
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:
Independencia entre los usuarios de sistema y las cuentas de correo electrónico. Información de las cuentas de correo almacenada en base de datos MySQL. Un dominio local donde se crean cuentas de correo. Múltiples alias de dominios virtuales con redirecciones a las cuentas del dominio principal. Autenticación a través de SASL (Simple Authentication and Security Layer), con métodos de
texto plano o login. Transporte seguro del tráfico mediante TLS. Acceso a los buzones por IMAP (Cyrus IMAP) sobre SSL y por webmail (SquirrelMail)
sobre SSL. Filtrado de correo en el servidor a través de SIEVE. Filtros antivirus (Clam AntiVirus) y antispam (SpamAssassin y Postgrey). Listas de correo con Mailman. Gestión del servidor a través de la interfaz web OpenMailAdmin.
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-freedeb-src http://ftp.es.debian.org/debian/ etch main contrib non-freedeb http://security.debian.org/ etch/updates main contrib non-freedeb 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 updateapt-get install postfix postfix-doc postfix-mysql postfix-pcre openssl ca-certificatesapt-get install libsasl2 libsasl2-modules sasl2-binapt-get install cyrus-admin-2.2 cyrus-clients-2.2 cyrus-common-2.2 cyrus-doc-2.2 cyrus-imapd-2.2 libcyrus-imap-perl22apt-get install mysql-server-5.0 mysql-client-5.0 libpam-mysqlapt-get install apache2-mpm-prefork libapache2-mod-php5 php5 php5-cli php5-mysql libphp-adodb php-pear php-db php-log php5-idn libidn11apt-get install apache2-utils nmap ntpdate ccze less wget bzip2
Configuración de PAM
Página 2 de 46
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=0account 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/imaprm --force /etc/pam.d/sieve /etc/pam.d/lmtpln --symbolic /etc/pam.d/imap /etc/pam.d/sieveln --symbolic /etc/pam.d/imap /etc/pam.d/lmtpln --symbolic /etc/pam.d/imap /etc/pam.d/smtp
Página 3 de 46
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-mysqlcd /usr/src/libpam-mysqlapt-get install dpkg-devapt-get source pam-mysqlapt-get build-dep pam-mysqlcd 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-devdpkg-buildpackagecd ..
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
Página 4 de 46
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.bakcp /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.sochown 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 mysqlEnter 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
Página 5 de 46
(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=yesMECHANISMS="pam"MECH_OPTIONS=""THREADS=5OPTIONS="-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/rundpkg-statoverride --add root sasl 710 /var/spool/postfix/var/run/saslauthdln --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 0drwx--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
Página 6 de 46
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}
Página 7 de 46
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: cyrussasl_pwcheck_method: saslauthdunixhierarchysep: yesallowusermoves: yesservername: mail.dominio.compostmaster: postmasterduplicatesuppression: 0sasl_mech_list: PLAIN LOGINsasl_minimum_layer: 0umask: 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 | cczetail -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.
Página 8 de 46
Instalación y configuración
Bajamos y descomprimimos OpenMailAdmin y establecemos los permisos adecuados:
mkdir --mode=755 /var/wwwcd /var/wwwwget http://static.ossdl.de/openmailadmin/downloads/openmailadmin-1.0.0.tbz2tar -xjf openmailadmin-1.0.0.tbz2mv openmailadmin-1.0.0 openmailadminchown --recursive www-data:root /var/www/openmailadminchmod 6770 /var/www/openmailadminfind /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
Página 9 de 46
Email Address []:
Please enter the following 'extra' attributesto be sent with your certificate requestA 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 ssla2ensite 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:
Página 10 de 46
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
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/postfixtablenames' prefix:
hashed with: MD5
IMAP connection settings------------------------
Página 11 de 46
type: Cyrus imapdhost: localhostport: 143imap 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:
domains imap_demo user virtual virtual_regexp
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.
Página 12 de 46
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.
Instalación y configuración
Empezamos configurando en los ficheros /etc/mailname y /etc/hostname nuestro nombre de dominio:
echo "mail.dominio.com" > /etc/mailnamehostname 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.1user = postfixpassword = <my_passwd>dbname = postfixtable = userselect_field = canonicalwhere_field = mboxadditional_conditions = and active = '1' limit 1
Creamos el fichero /etc/postfix/mydestination.mysql:
hosts = 127.0.0.1user = postfixpassword = <my_passwd>dbname = postfixtable = domainsselect_field = domainwhere_field = domain
Creamos el fichero /etc/postfix/virtual.mysql:
hosts = 127.0.0.1
Página 13 de 46
user = postfixpassword = <my_passwd>dbname = postfixtable = virtualselect_field = destwhere_field = addressadditional_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.mysqlchmod 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 = noappend_dot_mydomain = nodelay_warning_time = 4h
myhostname = mail.dominio.commydomain = $myhostnamemyorigin = $mydomainmydestination = $myhostname, $mydomain, localhost.$mydomain, localhostmynetworks = 127.0.0.0/8, x.y.z.t
alias_maps = hash:/etc/aliasesalias_database = hash:/etc/aliasesmailbox_size_limit = 0recipient_delimiter = +unknown_local_recipient_reject_code = 550
mailbox_transport = cyrusvirtual_alias_domains = mysql:/etc/postfix/mydestination.mysqlvirtual_alias_maps = mysql:/etc/postfix/virtual.mysqlsender_canonical_maps = mysql:/etc/postfix/canonical.mysql
smtpd_sasl_auth_enable = yessmtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destinationsmtpd_sasl_security_options = noanonymoussmtpd_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:
Página 14 de 46
smtp inet n - - - - smtpd -v
Creamos /etc/postfix/sasl/smtpd.conf con permisos 644 (root:postfix) con el siguiente contenido:
pwcheck_method: saslauthdmech_list: PLAIN LOGINlog_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
Página 15 de 46
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
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 25Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 mail.dominio.com ESMTP Postfix (Debian/GNU)HELO localhost250 mail.dominio.comMAIL FROM: <postmaster>250 OkRCPT TO: <postmaster>250 OkDATA354 End data with <CR><LF>.<CR><LF>Este es un mensaje de pruebas enviado a traves de telnet..250 Ok: queued as 5F496BEE9
Página 16 de 46
QUIT221 ByeConnection 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.squatdrwxr-x--- 2 cyrus mail 79 2007-07-03 10:06 Trashdrwxr-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 +0200X-Sieve: CMU Sieve 2.2Received: 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]: 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
Página 17 de 46
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: 128tls_cert_file: /etc/ssl/certs/mail.dominio.com_newcert.pemtls_key_file: /etc/ssl/private/mail.dominio.com_newkey.pemtls_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 localhostTLS 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 readyC: C01 CAPABILITYS: * 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-IRS: C01 OK CompletedC: L01 LOGIN postmaster {8}S: + go aheadC: <omitted>S: L01 OK User logged inAuthenticated.Security strength factor: 256
Página 18 de 46
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 = yessmtpd_tls_auth_only = nosmtpd_tls_key_file = /etc/ssl/private/mail.dominio.com_newkey.pemsmtpd_tls_cert_file = /etc/ssl/certs/mail.dominio.com_newcert.pemsmtpd_tls_CAfile = /usr/share/ca-certificates/cacert.org/root.crtsmtpd_tls_loglevel = 3smtpd_tls_received_header = yessmtpd_tls_session_cache_timeout = 3600stls_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 25Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 mail.dominio.com ESMTP Postfix (Debian/GNU)EHLO localhost250-mail.dominio.com250-PIPELINING250-SIZE 10240000250-VRFY250-ETRN250-STARTTLS250-AUTH LOGIN PLAIN250-AUTH=LOGIN PLAIN250-ENHANCEDSTATUSCODES250-8BITMIME250 DSN
Página 19 de 46
AUTH PLAIN anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI235 2.0.0 Authentication successfulQUIT221 2.0.0 ByeConnection 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 25Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 mail.dominio.com ESMTP Postfix (Debian/GNU)EHLO localhost250-mail.dominio.com250-PIPELINING250-SIZE 10240000250-VRFY250-ETRN250-STARTTLS250-ENHANCEDSTATUSCODES250-8BITMIME250 DSNSTARTTLS220 2.0.0 Ready to start TLSQUITQUITConnection 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:
IMAP Nombre del servidor: mail.dominio.com Nombre de usuario: postmaster Contraseña: <passwd> Conexión segura: TLS (o SSL) Puerto: 143 (o 993 si se elije SSL)
SMTP Nombre del servidor: mail.dominio.com Nombre de usuario: postmaster Contraseña: <passwd> Conexión segura: TLS Puerto: 25
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:
Página 20 de 46
¿Quién es el usuario? ¿Es el usuario quien realmente pretende ser?
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:
¿Está autorizado el usuario X a acceder al recurso R? ¿Está autorizado el usuario X a realizar la operación P? ¿Está autorizado el usuario X a realizar la operación P sobre el recurso R?
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.
Página 21 de 46
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 tnefapt-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.
Página 22 de 46
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 typeqr'^\.wmf$', # Windows Metafile file(1) typeqr'^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.
Página 23 de 46
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.
Página 24 de 46
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 10024Trying 127.0.0.1...Connected to 127.0.0.1.Escape character is '^]'.220 [127.0.0.1] ESMTP amavisd-new service readyMAIL FROM: <postmaster>250 2.1.0 Sender postmaster OKRCPT TO: <postmaster>250 2.1.5 Recipient postmaster OKDATA354 End data with <CR><LF>.<CR><LF>Subject: Amavis testEste 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 OKRCPT TO: <postmaster>250 2.1.5 Recipient postmaster OKDATA354 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 97D44C000740QUIT221 2.0.0 [127.0.0.1] amavisd-new closing transmission channelConnection 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-Test250 2.5.0 Ok, but 1 BOUNCE250 2.7.1 Ok, discarded, id=16984-01 - VIRUS: EICAR-AV-Test250 2.6.0 Ok, id=17041-01, from MTA: 250 Ok: queued as 3F1841A5F5
Página 25 de 46
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 25Trying x.y.z.t...Connected to mail.dominio.com.Escape character is '^]'.220 mail.dominio.com ESMTP Postfix (Debian/GNU)EHLO dominio.com250-mail.dominio.com250-PIPELINING250-SIZE 10240000250-ETRN250-STARTTLS250-AUTH LOGIN PLAIN250-AUTH=LOGIN PLAIN250-ENHANCEDSTATUSCODES250-8BITMIME250 DSNAUTH PLAIN anNhYmF0ZXIAanNhYmF0ZXIAanNhYmF0ZXI235 2.0.0 Authentication successfulMAIL FROM: <postmaster>250 2.1.0 Sender postmaster OKRCPT TO: <postmaster>250 2.1.5 Recipient postmaster OKDATA354 End data with <CR><LF>.<CR><LF>Subject: Test spam mail (GTUBE)Precedence: junkMIME-Version: 1.0Content-Type: text/plain; charset=us-asciiContent-Transfer-Encoding: 7bitXJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X.250 2.0.0 Ok: queued as D4107C00FD29QUIT221 2.0.0 ByeConnection 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.comX-Spam-Flag: YESX-Spam-Score: 1007.457X-Spam-Level: ****************************************************************
Página 26 de 46
X-Spam-Status: Yes, score=1007.457 tagged_above=2 required=6.31tests=[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 = yesdisable_vrfy_command = yesstrict_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.
Página 27 de 46
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.commail.dominio.com REJECT You are not mail.dominio.comx.y.z.t REJECT You are not x.y.z.tlocalhost 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
Página 28 de 46
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 [email protected] OKmorespammers.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 here10 554 Go away!myfriendsdomain.com OK172.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
Página 29 de 46
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:
Instalación y configuración
Página 30 de 46
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:
Página 31 de 46
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/aliasesalias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliasesmailman_destination_recipient_limit = 1unknown_local_recipient_reject_code = 550owner_request_special = norecipient_delimiter = +
Solicitando a Postfix que recargue la configuración y regenerando los alias habremos terminado con Postfix:
/etc/init.d/postfix reloadnewaliases
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 mailmanEnter the email of the person running the list: [email protected] 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
Página 32 de 46
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/TrashFolder Defaults: Sent Folder = INBOX/SentFolder Defaults: Drafts Folder = INBOX/Drafts
Opcionalmente, podemos cambiar también:
Organization Preferences: Organization NameOrganization Preferences: Organization LogoOrganization Preferences: Organization TitleMessage 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>
Página 33 de 46
# 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 rewriteModule rewrite installed; run /etc/init.d/apache2 force-reload to enable.# /etc/init.d/apache2 force-reloadForcing 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.
Página 34 de 46
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.gztar -xzf avelsieve-1.9.7.tar.gzrm --force avelsieve-1.9.7.tar.gzchown --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.gztar -xzf compatibility-2.0.9-1.0.tar.gzrm --force compatibility-2.0.9-1.0.tar.gzchown --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.gztar -xzf change_sqlpass-3.3-1.2.tar.gzrm --force change_sqlpass-3.3-1.2.tar.gzchown --recursive root.root change_sqlpass/cp --archive change_sqlpass/config.php.sample change_sqlpass/config.php
Página 35 de 46
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.gztar -xzf check_quota-2.2-1.4.0.tar.gzrm --force check_quota-2.2-1.4.0.tar.gzchown --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
Página 36 de 46
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 /rootwget http://mailgraph.schweikert.ch/pub/mailgraph-1.14.tar.gztar -xzf mailgraph-1.14.tar.gzchown --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/mailgraphcp --archive mailgraph-1.14/mailgraph.css /usr/lib/cgi-bin/cp --archive mailgraph-1.14/README /usr/share/doc/mailgraph/
Página 37 de 46
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 ismy $rrd_virus = '/var/lib/mailgraph/mailgraph_virus.rrd'; # path to where the Virus RRD database ismy $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.cssScriptAlias /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 loginPassword: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.
Página 38 de 46
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.
Los permisos definidos son:
l (lookup): el usuario puede ver que el buzón de correo existe;
Página 39 de 46
r (read): el usuario puede leer el buzón de correo. El usuario puede seleccionar el buzón, leer los datos contenidos, llevar a cabo búsquedas y copiar mensajes de ese buzón;
s (seen): mantiene el estado leído por usuario. Se preservan los flags Seen y Recent para cada usuario;
w (write): el usuario puede modificar los flags excepto Seen y Deleted (los cuales son controlados por otros permisos);
i (insert): el usuario puede insertar mensajes en el buzón de correo; p (post): el usuario puede mandar correo a la dirección de envío del buzón. Este permiso
difiere del permiso i en que el sistema de envío inserta información de seguimiento en los mensajes envíados;
c (create): el usuario puede crear subcarpetas en el buzón; d (delete): el usuario puede alterar el flag Deleted, expirar correos y borrar o renombrar el
buzón; a (administer): el usuario puede cambiar la ACL del buzón.
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.
Página 40 de 46
Por ejemplo, dados los buzones:
user.jsabateruser.jsabater.lists.bulmailinguser.jsabater.lists.postfix-usersuser.jsabater.todouser.jsabater.workuser.jsabater.work.customersuser.jsabater.work.suppliers
Y cuotas raíz en:
user.jsabateruser.jsabater.listsuser.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.
Página 41 de 46
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.
ficheros de mensajes. Hay uno por mensaje, que contiene el mensaje en formato RFC 822. Las líneas del mensaje están separadas por CRLF, no sólo LF. El nombre de fichero del mensaje es el UID del mensaje seguido de un punto.
cyrus.header. Este fichero contiene un número mágico e información de tamaño variable sobre el propio buzón de correo.
cyrus.index. Este fichero contiene información de tamaño fijo sobre el propio buzón de correo y cada uno de los mensajes que contiene.
cyrus.cache. Este fichero contiene información de tamaño variable sobre cada uno de los mensajes del buzón de correo.
cyrus.seen. Este fichero contiene información de estado, de tamaño variable, sobre cada uno de los usuarios que han leído el buzón de correo y tenían el permiso s.
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
Página 42 de 46
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:
CRIT: errores críticos que probablemente requieren acciones administrativas en la línea de comandos.
ERR: errores de entrada y salida (E/S), incluyendo fallos al actualizar el uso de la cuota. El mensaje al syslog incluyen el error Unix y el fichero específicos.
WARNING: fallos de mecanismos de protección, timeouts por inactividad del cliente. NOTICE: autenticaciones, correctas o incorrectas. INFO: aperturas de buzones de correo.
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:
nombre del host del cliente; login del usuario, si está conectado; buzón seleccionado, si hay alguno.
Normalmente el subdirectorio proc es purgado al reiniciar el servidor.
Notas
La palabra clave all agrupa todos los permisos.
Página 43 de 46
Para asignar permisos a un grupo UNIX se usa la forma group:nombre_grupo. Un grupo UNIX debe existir en el fichero /etc/group. Los usuarios que añadamos a ese grupo
(editando manualmente el fichero) serán buzones de correo creados con el programa cyradm, no usuarios de sistema (aunque puede existir correspondencia, pero no tendrá relación alguna).
Pese a que el usuario cyrus tiene permisos implícitos de administración sobre todos los buzones, es preciso hacerlos explícitos para ejecutar algunos comandos sobre ellos (por ejemplo, para borrarlos). Un comando del estilo sam user.buzon cyrus all solucionaría el problema, pues luego se heredarían los permisos en los subbuzones.
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):
smtp: 25 TCP https: 443 TCP imaps: 993 TCP
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:
821 : Simple Mail Transfer Protocol 1321 : The MD5 Message-Digest Algorithm 1651 : SMTP Service Extensions 1652 : SMTP Service Extension for 8bit-MIMEtransport 1870 : SMTP Service Extension for Message Size Declaration 1939 : Post Office Protocol - Version 3 2033 : Local Mail Transfer Protocol 2104 : HMAC: Keyed-Hashing for Message Authentication 2195 : IMAP/POP AUTHorize Extension for Simple Challenge/Response 2222 : Simple Authentication and Security Layer (SASL) 2243 : OTP Extended Responses 2245 : Anonymous SASL Mechanism 2289 : A One-Time Password System 2444 : The One-Time-Password SASL Mechanism 2487 : SMTP Service Extension for Secure SMTP over TLS 2554 : SMTP Service Extension for Authentication 2595 : Using TLS with IMAP, POP3 and ACAP 2821 : Simple Mail Transfer Protocol 2831 : Using Digest Authentication as a SASL Mechanism 2920 : SMTP Service Extension for Command Pipelining 2945 : The SRP Authentication and Key Exchange System 3028 : Sieve: A Mail Filtering Language
Página 44 de 46
3174 : US Secure Hash Algorithm 1 (SHA1) 3546 : Transport Layer Security (TLS) Extensions
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
Configuración de un completo servidor de correo seguro con Postfix y Cyrus Greylisting: the next step in the spam control war ISP Mailserver Solution Howto Postfix SMTP AUTH with TLS on Debian GNU/Linux Postfix MySQL Howto Enabling SASL in Postfix Postfix FAQ Postfix Virtual Domain Hosting Howto Postfix SMTP-AUTH 4 DUMMIES Running Cyrus IMAP. Configuring virtual domains with Cyrus+Postfix in FreeBSD 5.4 ISP-style Email Service with Debian-Sarge and Postfix 2.1 Sarge - postfix/saslauthd issues
Página 45 de 46
OpenMailAdmin - Postfix-SASL-Cyrus-MySQL-HOWTO OpenMailAdmin - Configure Support for Multiple Servers OpenMailAdmin - Detailed Installation Instructions OpenMailAdmin - Compiling Postfix with TLS/SSL Postfix-Cyrus-Web-cyradm-HOWTO Postfix and SpamAssassin Rotating Linux Log Files
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.1Añ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.1Añadido el fichero /etc/apt/sources.list usado al principio del documento, principalmente para que conste el uso del proyecto Debian Volatile.
2008/04/27 1.2.2Añadida la línea de fuentes en el fichero /etc/apt/sources.list, necesaria para bajarse los fuentes del paquete pam-mysql.
Página 46 de 46