Sistema de correo con Postfix, Cyrus y MySQL

Transcripción

1 Sistema de correo con Postfix, Cyrus y MySQL Copyright 2006 Liberalia Tempus, S.L.

2 Índice I. Introducción.. 03 II. Tecnologías.. 04 III. Instalando software 08 IV. Seguridad en MySQL 12 V. Configuración de PAM.. 14 VI. Postfix. 15 VII. Cyrus IMAP y SASL 21 VIII. Cifrado del canal 27 IX. Web-Cyradm.. 30 X. Probando la configuración.. 32 XI. Filtrado.. 36 XII. Squirrelmail 45 XIII. Mailman. 51 XIV. Apéndice 54 Copyright 2006 Liberalia Tempus, S.L. Todos los derechos reservados. El manual queda publicado sin coste alguno y es de libre distribución siempre que se respete la inclusión de su procedencia en los medios donde sea publicado y no sea modificado de ninguna forma. Se prohíbe expresamente la publicación parcial del contenido de este manual sin permiso de su autor. Se prohíbe expresamente la modificación de este manual y su posterior publicación en cualquier medio. Sistema de correo con Postfix, Cyrus y MySQL 2

3 I Introducción A partir de este documento, instalaremos y configuraremos de forma adecuada un sistema de correo con el MTA Postfix y el servidor Cyrus IMAP. Conseguiremos con ello tener en funcionamiento un potentísimo sistema de correo que abarcará las últimas tecnologías en servidores y seguridad. Se potenciará, una vez realizada dicha instalación, la facilidad de administración del sistema, que procuraremos sea independiente de la configuración de los distintos paquetes. Así, configuraremos una interfase web que nos permita el control total del sistema de usuarios, siendo accesible desde cualquier ordenador y contando con las mayores garantías de seguridad. El objetivo de nuestra instalación será completar un sistema de correo con las siguientes características: Cuentas de correo independientes del sistema operativo. Opción de gestionar varios dominios desde una misma máquina. Dominios virtuales redirigidos a la cuenta principal. Auteticación mediante SASL con texto plano o login. Tabla de MySQL con datos de usuarios. Transporte de datos bajo TLS. Protocolos IMAP, POP, y webmail para el acceso de los buzones. Seguridad SSL de conexión. Filtros de correo (Sieve). Filtros antivirus (ClamAV) y antispam (SpamAssassin). Listas de correo. Nota: Agradecer con sinceridad a Jaume Sabater y a Luc de Louw su gran trabajo, sin el cual este manual no hubiera sido posible. Al finalizar el manual, añadiré un capítulo de biografías donde se detallarán ampliamente los distintos trabajos en los cuales se ha inspirado este manual. Sistema de correo con Postfix, Cyrus y MySQL 3

4 II Tecnologías Resumiremos a continuación las diferentes tecnologías usadas en la instalación del sistema de correo. Fedora Core - Linux (kernel-2.6) Fedora es el sistema operativo que siguió con el proyecto de software libre iniciado por el famoso Red Hat. Corre con el núcleo linux y la mayor parte de sus herramientas son de libre distribución y uso. En la última actualización de este manual (junio de 2006), el sistema Fedora alcanza ya su quinta distribución. Las configuraciones de este manual se referirán a la configuración bajo esta distribución. Aunque se ha probado la misma bajo otras distribuciones y versiones, es problable que sean necesarios ciertos cambios para que nuestro sistema de correo funcione de forma adecuada fuera de la versión tratada. Postfix (postfix ) Postfix es un MTA (Mail Transport Agent) rápido, fácil de administrar y seguro. Aunque no venga al caso, es totalmente compatible con sendmail, manteniendo externamente las formas de éste. Postfix es una combinación de diversos programas que realizan su función determinada dentro del conjunto. Nos podemos hacer una pequeña idea de esto observando la imágen siguiente: Aunque parezca mentira, el resultado es menos complejo de lo que a primera vista puede parecer, pero no nos extenderemos más. Para más información a cerca de postfix, se puede consultar la documentación de su website: TLS (Transportation Layer Security) y OpenSSL (openssl-0.9.7f-7) Todos los datos que viajan a través de Internet, lo hacen por defecto sin ningún tipo de encriptación ni autenticación fiable. En la práctica, cualquier persona con los conocimientos adecuados y con acceso físico a la línea de datos a través de la cual viaja un paquete, tendría acceso a dicha información. Por supuesto, si dicho acceso se efectúa, el contenido de los distintos paquetes puede ser alterado o redirigido con cualquier propósito. Para evitar este tipo de accesos, la compañía Netscape Inc. introdujo el protocolo de seguridad SSL (Secure Sockets Layer), cuya evolución ha terminado en el actual TLS. Este protocolo aporta encriptación de la comunicación (evitando escuchas no deseadas) y una alta fiabilidad en la autenticación que se asegura de tener correctamente identificadas a las distintas partes de una comunicación para que los datos no puedan ser alterados. Sistema de correo con Postfix, Cyrus y MySQL 4

5 El protocolo de seguridad será implantado en nuestro sistema gracias a OpenSSL. Para una mayor información sobre el particular, consultar la página web Cyrus IMAP (cyrus-imapd ) Cyrus IMAP (Internet Message Access Protocol) es desarrollado y mantenido por Andrew Systems Group, de la Carnegie Mellon University. A diferencia de otros gestores de correo IMAP, Cyrus almacena cada correo en un fichero independiente. Las ventajas son obvias: mayor fiabilidad de almacenamiento y una rapidez de acceso inusitada. Los índices de cada mensaje y su estado se guardan en una base de datos a parte y los mensajes se indexan para una mayor rapidez en el acceso o la búsqueda. No es necesaria una cuenta de sistema linux para cada uno de los usuarios de correo. Esto hace que la creación de usuarios se pueda automatizar y no sea demasiado ardua en el caso de una gran cantidad de las mismas. Como la administración de cada cuenta se realiza mediante comandos específicos, la programación de interfaces dinámicos sirve para tener un mayor control sobre todas las funcionalidades del programa, a la vez que se hace más seguro que la manipulación del /etc/passwd. La versión de Cyrus analizada en este manual utiliza la versión 2 de la librería SASL para la autenticación. Así, Cyrus realizará la autenticación en tres fases o capas: el demonio saslauthdaemon redirigirá la petición al mecanismo definido (en nuestro caso será PAM a través de MySQL), el cual buscará la información del usuario en una base de datos MySQL. Cyrus SASL (cyrus-sasl ) SASL son las siglas de Simple Authentication and Security Layer, método que añade un soporte adicional para la autenticación de los protocolos que fundamentan su conexión en la estandarización fijada por la IETF (Internet Engineering Task Force). Se usa en servidores, como Cyrus IMAP, para controlar las peticiones de acceso de los clientes. El protocolo de autenticación incluirá comandos para la correcta apertura del canal cliente-servidor y las subsiguientes aperturas del canal para la toma de nuevos datos. Opcionalmente, puede negociarse una capa de seguridad entre el protocolo mismo y la conexión. Cyrus SASL utiliza OpenSSL para encriptar los datos. LMTP (Local Mail Transfer Protocol) SMTP (Simple Mail Transfer Protocol) y sus extensiones ESMTP (SMTP Service Extensions), proporcionan los mecanismos necesarios para el trasporte de correo fiable y eficaz. El servidor bajo SMTP controlará las colas de envío de correo. LMTP actúa de forma que el servidor no tenga que manejar colas de correo, a modo de MDA (Mail Delivery Agent). Aunque LMTP puede utilizar extensiones que en un primer momento estarían definidas para su uso por ESMTP, nunca debería funcionar como receptor de escucha sobre el puerto 25. MySQL (mysql ) MySQL es un servidor de bases de datos rápido, potente y muy fácil de usar e implementar bajo cualquier plataforma. Ya que Cyrus puede utilizar PAM como mecanismo de autenticación, usaremos la extensión pam_mysql para conectar a Cyrus con una base de datos de usuarios creada en MySQL. A partir de aquí, podemos crear un interface web que nos permita la gestión administrativa completa de todo el servicio de correo. La potencia de PHP y la fiabilidad de MySQL harán del sistema que desarrollaremos en este manual algo seguro, fiable y rápido. Sistema de correo con Postfix, Cyrus y MySQL 5

6 Pam_MySQL (pam_mysql ) PAM (Pluggable Authentication module) fue desarrollado en primera instancia por el equipo de desarrollo de Sun Microsystems. Como puede suponerse, han quedado una gran cantidad de módulos de conexión con diferentes tecnologías. Uno de esos módulos es Pam_MySQL. Con Pam_MySQL será posible almacenar las contraseñas de los usuarios del servidor de correo en una base de datos MySQL, así como también será posible almacenar datos como alias que podrán ser interpretados por Postfix. En definitiva, gracias a estas tecnologías, tendremos a nuestra disposición una base de datos y un mecanismo de conexión con autenticación que servirán todas las necesidades que pueda tener cualquier administrador/servidor de correo. Gracias a todos estos elementos, las tareas de administración de cada dominio podrán ser delegadas a los propios usuarios de correo, con el consiguiente ahorro de tiempo que eso supone. Sieve Sieve es un pequeño intérprete de órdenes que se encargan de realizar filtrados de correo en el lado del servidor, a la entrega del correo. El mensaje a filtrar necesita del uso del protocolo RFC822. Es un lenguaje muy sencillo y con órdenes muy limitadas, pero perfecto para su uso como lenguaje encargado de crear filtros de correo. Aún así, es preciso recomendar el uso de algún interface que agilice y automatice el uso de Sieve por parte de usuarios sin acceso al servidor. Amavisd-New (amavisd-new ) Amavis supone una pasarela o interface que se coloca entre el servidor y uno o varios filtros de contenidos (antivirus, antispam, filtrado de correo...). Está escrito en Perl, lo que asegura su portabilidad y fiabilidad y se comunica con el servidor por medio de casi cualquier protocolo o programa al efecto. Básicamente, amavisd-new actúa como un servidor smtp que cumple el estándar RFC 2821 o uno lmtp que cumple con el estándar RFC Una vez procesado el mensaje, se generan notificaciones que los programas de antivirus o antispam usarán para analizar los mensajes y filtrarlos o eliminarlos. Las notificaciones se generan bajo las normas RFC 1892 y 1894, lo que supone un estándar para una gran cantidad de programas de filtrado. SpamAssassin (spamassassin ) SpamAssassin es un filtro de correo programado por los creadores de Apache. Analiza en tiempo real el correo entrante y lo compara con listados de spam y trata de analizar el texto para un mejor filtrado del mismo. Una vez realizado el análisis, el mensaje quedará o no marcado como spam para su posterior filtrado o eliminación. El filtrado de los mensajes de spam es habitualmente muy satisfactorio si el programa se ha configurado correctamente, permitiendo incluso el envío de informes de spam a bases de datos internacionales. ClamAV (clamav ) El antivirus Clam es una herramienta bajo licencia GPL desarrollada para sistemas Linux/Unix. Se adapta perfectamente a casi cualquier servidor de correo y su principal función es la de escanear los datos adjuntos de un correo electrónico. La actualización de la base de datos es constante y la librería en la que se basa el programa es de libre distribución y uso por cualquier programa, lo que permite una integración perfecta bajo cualquier entorno. El programa soporta firmas digitales en las actualizaciones y escanea ficheros comprimidos y mensajes de correo en casi cualquier formato. Sistema de correo con Postfix, Cyrus y MySQL 6

7 Mailman (mailman ) Mailman es un software de gestión de listas de correo y de noticias. Su perfecta integración con la web permite una fácil y rápida administración del sistema, así como un uso muy sencillo de cara al usuario de las listas. Mailman puede crear archivos de correo automáticos, procesar correo rechazado, filtrar spam, enviar conjuntos de correos como uno solo y mucho más. Squirrelmail (squirrelmail ) Squirrelmail es un lector de correo vía web escrito en php. Mediante esta tecnología de programación, proporciona acceso al servidor de correo mediante los protocolos IMAP y SMTP. Las páginas son creadas en HTML sobre la marcha y no se requiere el uso de javascript, lo cual garantiza la máxima compatibilidad en casi cualquier navegador. Gracias a la gran cantidad de add-ons disponibles, este lector de correo vía web se convierte en la herramienta perfecta de acceso a la cuenta de correo fuera del lugar habitual de trabajo. Web-cyradm (web-cyradm ) Web-cyradm es un interface web que permite la administración de un sistema de correo completo. Está escrito en php, lo que nos permite un control absoluto sobre todos sus parámetros. Para su correcto funcionamiento, es necesario que de la parte del servidor exista el correspondiente servidor/intérprete de lenguaje php correctamente configurado. Web-cyradm está en constante desarrollo por parte de gente de todo el planeta y el listado de sus características y opciones crece día a día. Se puede tener una idea mucho más cercana del proyecto accediento a la página web del mismo: Algunas de las tareas que podemos completar con web-cyradm pueden ser (entre otras) la administración de múltiples dominios virtuales, cuotas de usuario, creación automática de cuentas con el prefijo del dominio, alias de usuario, soporte MySQL, etc. Sistema de correo con Postfix, Cyrus y MySQL 7

8 III Instalando Software La mayoría del software a instalar viene incluído en la distribución de Fedora al uso. Es probable que las versiones o paquetes incorporados "de serie" con la distribución, no coincidan con las utilizadas para la confección de este manual, así que se recomienda encarecidamente que, en la medida de lo posible, se utilicen las versiones indicadas en el Capítulo II. Es muy recomendable que las actualizaciones de paquetes bajo el sistema Fedora se hagan con herramientas de actualización automática como yum o apt-get. Recalcar que la instalación del servidor de correo ha de hacerse bajo Fedora Core 4 o Fedora Core 5, no garantizándose el correcto funcionamiento del sistema bajo otras distribuciones. Durante la instalación/actualización de paquetes requerida por este manual, se marcarán en azul aquellos paquetes cuya instalación queda recomendada por el autor, no siendo imprescindibles para el correcto funcionamiento del servidor de correo. Instalando MySQL Sitio web de descarga original: Instalaremos los siguientes paquetes con la herramienta yum (yum update [paquete]) : mysql-devel fc4.1 mysql fc4.1 mysql-server fc4.1 php-mysql Como medida de seguridad, Fedora añade al usuario mysql al sistema tras la instalación de los paquetes. Por nuestra parte, haremos un pequeño cambio al fichero de configuración /etc/my.cnf para controlar de manera más eficaz el log de acceso y errores de mysql. Añadiremos las líneas siguientes a los epígrafes entre corchetes: [mysqld] log=/var/log/mysql/mysql-access.log [mysqld_safe] err-log=/var/log/mysql/mysql-err.log Si algún parámetro ya aparece en el fichero, se sustituirá por la línea correspondiente. Acto seguido, crearemos los ficheros de log: # touch /var/log/mysql/mysql-err.log # touch /var/log/mysql/mysql-access.log # chown mysql.mysql /var/log/mysql* Por último, activamos el servicio mysql para su ejecución con el inicio del sistema: # chkconfig mysqld on Con esto queda instalado mysql para el propósito que nos ocupa. Sistema de correo con Postfix, Cyrus y MySQL 8

9 Instalando OpenSSL Sitio web de descarga original: Paquetes a instalar: openssl-0.9.7f-7.10 openssl-devel-0.9.7f-7.10 openssl-perl-0.9.7f-7.10 mod_ssl En el caso de OpenSSL, nos servirá la instalación por defecto del paquete. Instalando CyrusSASL e IMAP Sitios web de descarga original: ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-sasl tar.gz ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-imapd tar.gz Paquetes a instalar: cyrus-imapd fc4 cyrus-imapd-devel fc4 cyrus-imapd-nntp fc4 cyrus-sasl-devel cyrus-sasl cyrus-imapd-utils fc4 cyrus-sasl-plain cyrus-imapd-murder fc4 cyrus-sasl-gssapi cyrus-sasl-md Y añadiremos el servidor de cyrus-imap al script de inicio del sistema: # chkconfig cyrus-imapd on Instalando postfix Sitio web de descarga original: En los sistemas Fedora, postfix viene de origen compilado sin la opción mysql activada. Por lo tanto, el paquete rpm del Fedora original no nos sirve para el propósito de este manual. Descargaremos de nuestro repositorio preferido, mediante la herramienta yum, el paquete de fuentes sin compilar de postfix. En nuestro caso postfix src.rpm y lo instalaremos con la herramienta de paquetería rpm : # rpm -ivh postfix src.rpm Seguidamente editamos el fichero /usr/src/redhat/specs/postfix.spec de los fuentes y modificamos lo siguiente: %define MYSQL 0 --> %define MYSQL 1 Y compilamos e instalamos postfix con la opción mysql activada: # cd /usr/src/redhat/ # rpmbuild -ba SPEC/postfix.spec # cd RPMS/i386 Sistema de correo con Postfix, Cyrus y MySQL 9

10 # rpm -Uvh postfix i386.rpm --replacefiles # rpm -Uvh postfix-debuginfo i386.rpm --replacefiles # rpm -Uvh postfix-pflogsumm i386.rpm --replacefiles Antes de proceder con la instalación de los paquetes, es recomendable asegurarse de que ningún paquete de los referidos (o cualquier otro MTA distinto a postfix) está instalado, para evitar conflictos entre versiones. Obviamente, habremos de configurar yum o apt de forma que no actualice el paquete postfix en ningún momento. Para ello, leeremos las instrucciones correspondientes de cada programa y obtendremos lo deseado. Instalando PAM Si el sistema PAM no ha quedado instalado por defecto en la instalación de Fedora, lo instalaremos mediante yum. Paquetes a instalar: pam pam-devel Instalando pam-mysql Sitio web de descarga original. Paquetes a instalar: pam_mysql Instalando web-cyradm Sitio web de descarga original: No hay binarios pre-compilados de web-cyradm para Fedora, así que descargaremos el paquete comprimido de la web y lo instalaremos sobre la ruta de documentos públicos de nuestro servidor de páginas web. Suponiendo que tengamos el servidor Apache instalado, la ruta sería /var/www/html/. El paquete tar ya viene preparado para descomprimir y usar: # cd /var/www/html # tar -xvzf web-cyradm tar.gz Habilitaremos los ficheros de log para la depuración: # touch /var/log/web-cyradm.log # chown nobody /var/log/web-cyradm.log La verión de web-cyradm es la última considerada estable. Instalando el resto... El resto de paquetes a instalar es el siguiente. Utilizaremos la instalación por defecto que nos deje cada paquete: amavisd-new fc4.rf clamav-lib fc4 Sistema de correo con Postfix, Cyrus y MySQL 10

11 clamav-data fc4 clamav-update fc4 clamav fc4 clamav-server fc4 squirrelmail cvs fc4 spamassassin fc4 mailman fc4 Como se dijo anteriormente, es necesario tener instalado un servidor de páginas web y un servidor de php. web-cyradm funciona correctamente en sistemas Fedora Core con la versión 5 de php y el servidor Apache. Un último paso: Creación de las bases de datos de web-cyradm Para finalizar con la instalación del software y antes de adentrarnos en la configuración de cada paquete, crearemos las bases de datos necesarias para el correcto funcionamiento de webcyradm y postfix. Como ya se ha explicado, el sistema postfix y web-cyradm son totalmente configurables a gusto del usuario, pudiendo cada uno crear las tablas que considere necesarias para el sistema pensado. Para el propósito de este manual, nos limitaremos a crear la estructura necesaria para la integración de web-cyradm y postfix con mysql y PAM, que es más que suficiente para cualquier sistema de correo que cumpla con amplias garantias de seguridad, fiabilidad y consistencia. La instalación de web-cyradm nos proporciona varios scripts de configuración y de creación de tablas. Bajo el directorio scripts de la instalación tenemos dos que nos ayudaran a formalizar nuestras tablas de mysql, insertuser_mysql.sql y create_mysql.sql. El primero crea la base de datos de usuarios en nuestro sistema mysql para el correcto funcionamiento de web-cyradm, además de crear la base de datos mail. El segundo es el encargado de crear las tablas y de rellenarlas con un primer usuario (el administrador) y el usuario cyrus. El resto de scripts realizan funciones de administración y actualización del sistema web-cyradm y no vienen al caso en esta instalación. Antes de lanzar los scripts de creación de bases de datos, usuarios y tablas, es altamente recomendable, por no decir que es necesario, cambiar los nombres de usuario y claves por defecto y adecuarlas a nuestras necesidades. Editaremos los scripts y cambiaremos el usuario admin por otro a nuestro gusto y la contraseña test por la preferida. Una vez editados los scripts, los lanzaremos desde la consola de mysql: # mysql -p < insertuser_mysql.sql # mysql -p < create_mysql.sql Si no se está familiarizado con mysql, se pueden usar herramientas del tipo phpmysqladmin o similares para ejecutar los scripts. Sistema de correo con Postfix, Cyrus y MySQL 11

12 IV Seguridad en MySQL Daremos en este capítulo algunos pasos para añadir seguridad adicional a nuestro servidor mysql. Asegurando MySQL Como nuestra intención es utilizar una base de datos corriendo en un servidor de mysql para autenticar a los usuarios de correo, necesitamos alguna medida adicional de seguridad. En este caso, habremos de cerrar el acceso al puerto que utiliza mysql para la comunicación con otras máquinas: el puerto La forma más sencilla de hacer esto es dirigiendo al demonio mysqld al interface local de red Nos aseguramos de esta forma de que nadie pueda realizar una conexión al demonio de mysql a través de la red. Para lograr este objetivo, es necesario editar el fichero encargado de iniciar el sistema mysql. En Fedora, este fichero se sitúa por defecto en /etc/init.d/mysqld. Una vez cargado el fichero, buscaremos la línea que hace referencia al comando mysqld_safe, que es un ejecutable especial encargado de llamar al demonio mysqld y de pasarle ciertos parámetros que añaden una seguridad extra y un sistema de información en tiempo real de cualquier tipo de error que se produzca en relación a mysql. Por ejemplo, mysqld_safe se encargará de reiniciar el servidor cuando se produzca algún error que impida el correcto funcionamiento del mismo. En Fedora Core, la línea en cuestión aparece como sigue: /usr/bin/mysqld_safe --defaults-file=/etc/my.cnf --pidfile="$mypidfile" >/dev/null 2>&1 & A parte de los suyos propios, mysqld_safe pasará al demonio mysqld cualquier parámetro compatible con este último. Así que usaremos --bind-address para hacer que mysqld se ejecute sólo en el entorno o loopback: /usr/bin/mysqld_safe --defaults-file=/etc/my.cnf --bindaddress= pid-file="$mypidfile" >/dev/null 2>&1 & Para más información acerca de los parámetros de ejecución de mysqld_safe y mysqld, recurriremos a las páginas del manual de ambos comandos. Una vez realizados los cambios, reiniciaremos el servidor de mysql (/etc/init.d/mysqld restart) y nos aseguraremos de haber realizado los cambios de forma correcta. Para ello, podemos hacer uso del siguiente comando: # netstat -an grep LISTEN Y buscaremos en la salida algo similar a esto: tcp : :* LISTEN Configurando el firewall Si tenemos previsto que nuestro servidor de mysql corra en una máquina distinta a la del servidor de correo, habremos de realizar una serie de cambios en la configuración de nuestro firewall. Esto nos permitirá tener asegurada la conexión al demonio mysqld. Para ello, Sistema de correo con Postfix, Cyrus y MySQL 12

13 redirigiremos el puerto 3306 hacia la IP local de nuestro servidor mysql y daremos acceso desde el firewall a la máquina que vaya a hacer de servidor de correo. En los sistemas Fedora, el programa iptables se encarga de realizar redirecciones de puertos, sustituyendo éste al antiguo rinetd. Como podrá suponerse, no se adelantará aquí ninguna configuración de iptables, por la cantidad de configuraciones que se pueden manejar y por estar este manual orientado a otro tipo de instalación que nada tiene que ver con iptables. SELinux Capítulo aparte merece el programa de bloqueos de seguridad sobre el kernel SELinux. En los sistemas Fedora, el kernel viene compilado por defecto con esta característica, siendo altamente recomendable su inutilización. Las incompatibilidades creadas entre SELinux y otras partes del sistema operativo son tantas que, hasta que no sea SELinux un sistema altamente probado, no se puede recomendar su uso. Para el caso que nos ocupa y dependiendo de ciertas configuraciones, el servidor de mysql puede no llegar ni a arrancar de forma correcta si SELinux está habilitado. Por lo tanto, modificaremos el archivo /etc/selinux/config y nos aseguraremos de que el parámetro SELINUX está igualado a disabled: SELINUX = disabled Sistema de correo con Postfix, Cyrus y MySQL 13

14 V - Configuración de PAM Una buena configuración de PAM es imprescindible para la autenticación de todos y cada uno de los usuarios de nuestro sistema de correo. Para nuestros fines, habremos de asegurarnos de una sola cosa: que PAM reciba correctamente todos los datos necesarios para autenticar a los usuarios que pasan por el sistema Cyrus. Modificando ficheros En los sistemas bajo Fedora (y en casi todos los sistemas linux), todos los archivos de configuración de PAM se encuentran bajo el directorio /etc/pam.d/. Es aquí donde tendremos que modificar o crear los ficheros necesarios para una correcta autenticación de los usuarios de Cyrus. La autenticación que se persigue es la siguiente: Petición de acceso -> Intento de login en PAM -> Petición de datos a MySQL mediante pam_mysql -> Devolución de login erróneo o satisfactorio a Cyrus Así, escribiremos un fichero de configuración como el siguiente: auth required pam_mysql.so verbose=0 host=localhost user=usermail passwd=password db=mail table=accountuser usercolumn=username passwdcolumn=password crypt=1 logtable=log logmsgcolumn=msg logusercolumn=user loghostcolumn=host logpidcolumn=pid logtimecolumn=time account required pam_mysql.so verbose=0 host=localhost user=usermail passwd=password db=mail table=accountuser usercolumn=username passwdcolumn=password crypt=1 logtable=log logmsgcolumn=msg logusercolumn=user loghostcolumn=host logpidcolumn=pid logtimecolumn=time El cual guardaremos como /etc/pam.d/imap una vez realizados los cambios pertinentes sobre los parámetros passwd, crypt, user y db. Crearemos un fichero idéntico para cada uno de los servicios que requieran autenticación desde pam_mysql. Por ejemplo, crearemos ficheros para los servicios de pop, sieve o smtp, entre otros y los guardaremos con el nombre del servicio y la ruta anterior. Hay que poner especial atención al parámetro crypt, que deberá coincidir con la configuración de encriptación que deseemos y que nos ofrece web-cyradm. Hablaremos de las diferentes opciones de encriptación en el capítulo dedicado a la configuración de web-cyradm. De momento, usaremos el valor 1 ("encrypt") por ser el más portable. Sistema de correo con Postfix, Cyrus y MySQL 14

15 VI Postfix En el proceso de configuración del programa postfix atenderemos a los dos ficheros fundamentales que hacen que toda la maquinaria de este MTA engrane de forma perfecta: main.cf y master.cf. El fichero /etc/postfix/master.cf Ya que es nuestra intención aprovecharnos de las ventajas que nos ofrece Sieve en las tareas de filtrado, será necesario utilizar LMTP para la comunicación entre postfix y cyrus. Tal y como veremos en un capítulo posterior dedicado a la confiuración de Cyrus, habilitaremos el servicio lmtpunix sobre el fichero de configuración /etc/cyrus.conf. Aunque nuestra configuración del sistema de correo se está basando principalmente en sistemas Fedora y los permisos ya se aplican con las instalaciones de los paquetes, no está de más comentar que el socket creado por el servicio de lmtpunix (en Fedora Core /var/lib/imap/socket/lmtp) tendrá que ser accesible por postfix. Por otro lado, ya que cyrus requiere que todas las entregas por LMTP se autentiquen, considerará que toda entrega que se haga a través de un socket será de confianza, estableciendo que sea el usuario postman el que las realiza. Abriremos por tanto el fichero /etc/postfix/master.cf y observaremos que una línea como esta está presente: lmtp unix - - n - - lmtp Para terminar, nos fijaremos en otra línea de configuración posterior: # The Cyrus deliver program has changed incompatibly, multiple times. old-cyrus unix - n n - - pipe flags=r user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user} Hay que prestar especial atención a la ruta apuntada por el parámetro argv pues en alguna ocasión no refleja bien la situación del programa deliver y las entregas de correo pueden llegar a no efectuarse. El fichero /etc/postfix/main.cf Lo primero que hay que hacer al abrir por primera vez el fichero /etc/postfix/main.cf, es establecer de forma correcta los parámetros de nuestro servidor de correo. Para empezar, cambiaremos el nombre del host: myhostname = foo.bar.org Continuaremos con el parámetro mydestination, que igualaremos a los nombres de todos los dominios que consideremos locales (similar al fichero sendmail.cw de configuración de sendmail). Cada uno de los dominios, si es que hay más de uno, irá separado por comas: mydestination = foo.bar.org, liberaliatempus.com, furchbar-grausam.ch, whatever.domain.tld, mysql:/etc/postfix/mysql-mydestination.cf En algún caso, nos veremos en la necesidad de utilizar los servicios de un proveedor para procesar el envío de correo. En este caso, igualaremos el parámetro relayhost a cada uno de los proveedores de servicios que nos interesen. Si el parámetro queda en blanco, el correo Sistema de correo con Postfix, Cyrus y MySQL 15

16 saliente será procesado directamente por el servicio de smtp que se haya establecido por defecto: relayhost = relay01.foobar.net relay02.foobar.net relay03.foobar.net Otro parámetro importante a tener en cuenta es el referente al mailtransport, o el programa que se encargará de transportar el correo de un programa a otro. Para nuestros propósitos, deberíamos usar como programa de procesamiento a Cyrus, para lo cual igualaremos el parámetro mailbox_transport de la siguiente manera: mailbox_transport = cyrus Si, por ejemplo, preferimos usar lmtp, igualaríamos el parámetro al socket correspondiente: mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp Finalmente estableceremos bajo postfix el sistema de dominios virtuales y su procesamiento correcto. Para esto, utilizaremos distintos ficheros de configuración que informarán a postfix del lugar en la base de datos de mysql en el cual se encuentran los dominios virtuales correspondientes y los alias de usuario: virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf sender_canonical_maps = mysql:/etc/postfix/mysql-canonical.cf virtual_alias_maps establece la configuración de acceso a los alias virtuales, mientras que sender_canonical_maps se encarga de reescribir la dirección de correo a su formato correcto. Este último parámetro es necesario para el uso de un interface web, ya que los usuarios se crean habitualmente del modo test001, sin la dirección completa. Para el correcto funcionamiento de esta última configuración, crearemos los ficheros correspondientes... /etc/postfix/mysql-virtual.cf # Usuario y password de acceso al servidor mysql hosts = localhost user = mail password = password # El nombre de la base de datos dbname = mail # El nombre de la tabla table = virtual # select_field = dest where_field = alias additional_conditions = and status = '1' Sistema de correo con Postfix, Cyrus y MySQL 16

17 /etc/postfix/mysql-canonical.cf # Usuario y password de acceso al servidor mysql hosts = localhost user = mail password = password # El nombre de la base de datos dbname = mail # El nombre de la tabla table = virtual # select_field = alias where_field = username #Devuelve la primera ocurrencia additional_conditions = and status = '1' limit 1 /etc/postfix/mysql-mydestination.cf # Nombre de usuario y contraseña del servidor mysql hosts = localhost user = mail password = password # Nombre de la base de datos dbname = mail # Nombre de la tabla table = domain # select_field = domain_name where_field = domain_name SMTP con autenticación SASL y la seguridad de PAM Antes de comenzar con la activación en postfix de SASL, vamos a comprobar que todo lo que hemos hecho hasta ahora se comporta de manera correcta. Para ello, veremos ante todo que cada uno de los servicios está a la escucha en su lugar correspondiente: # netstat an grep LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN Sobre el puerto 25 tenemos el servicio smtp, en el 2000 se encuentra sieve y en el 143 escucha el servicio imap (a configurar en el siguiente capítulo). Si alguno de los servicios no aparece activado, esperaremos a la configuración correcta de Cyrus y a un capítulo posterior para hacer todas las comprobaciones. A priori, si los tres servicios están activos, ya se podría mandar correo, por ejemplo, a un buzón local (en negrita los comandos a teclear): # telnet localhost 25 Trying Connected to webmail.mailserver.com ( ). Sistema de correo con Postfix, Cyrus y MySQL 17

18 Escape character is '^]'. 220 webmail.mailserver.com ESMTP Postfix (Fedora) HELO localhost 250 webmail.mailserver.com MAIL FROM: < 250 Ok RCPT TO: < 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Este es un mensaje de pruebas enviado a traves de telnet Ok: queued as 5F496BEE9 QUIT 221 Bye Connection closed by foreign host. Para ver un log bastante detallado del proceso de envío de correo, añadiremos el parámetro -v al fichero /etc/postfix/master.cf, sobre la línea correspondiente al servicio de smtp: smtp inet n - n - - smtpd -v Sabiendo que el log queda alojado en /var/log/maillog en los sistemas con Fedora. Procedamos, ahora sí, a activar SASL sobre postfix. Autenticaremos a los clientes conectados mediante smtp para que puedan hacer relay sobre el servidor de correo. Para ello modificaremos la opción smtpd_recipient_restrictions del fichero /etc/postfix/main.cf: smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = broken_sasl_auth_clients = yes Con esto, los clientes sin autoridad podrán hacer relay sobre el servidor siempre que pertenezcan a las redes indicadas en mynetworks. Todo lo demás será rechazado. Más adelante, aseguraremos la conexión mediante TLS. Si smtpd_sasl_local_domain se iguala a algo, forzaremos la comprobación del usuario entrando en /etc/sasldb2 con [usuario@dominio al que se iguala la opción]. Para nuestros propósitos de autenticación bajo mysql, dejaremos la opción igualada a nada. Tendremos que indicar seguidamente el mecanismo a usar a través de SASL y para ello dejaremos, si no lo está ya, el fichero /usr/lib/sasl2/smtpd.conf con una única línea: pwcheck_method: saslauthd Y, sobre todo en sistemas con RedHat o con Fedora, hay que cambiar el método de autenticación con que saslauthd se inicia por defecto. Esto lo haremos sobre el fichero /etc/sysconfig/saslauthd, donde cambiaremos el mecanismo por defecto (habitualmente shadow) para igualarlo a pam: MECH=pam Sistema de correo con Postfix, Cyrus y MySQL 18

19 Para sistemas que no sean Fedora, hay que indicar al sistema dónde se encuentra el socket saslauthd y para esto habrá que crear un enlace hacia la posición deseada. Habitualmente, quedará como sigue, aunque siempre dependerá de la distribución en uso: # mv /var/run/sasl2 /var/run/sasl2-old # ln -s /var/run/saslauthd /var/run/sasl2 Una vez realizados los cambios, potenciaremos la seguridad en postfix mediante diferentes opciones que iremos añadiendo a smtpd_recipient_restrictions, amén de utilizar opciones como smtpd_helo_required = yes para verificar el uso correcto de nuestro servidor de correo. Aunque es necesaria la lectura de la documentación de postfix a este respecto, el fichero /etc/postfix/main.cf podría quedar de esta manera en lo referente a los filtros de autenticación: smtpd_helo_required = yes disable_vrfy_command = yes smtpd_recipient_restrictions = reject_invalid_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_helo_access hash:/etc/postfix/helo_check smtpd_data_restrictions = reject_unauth_pipelining, permit Por último, echemos un vistazo al fichero de configuración /etc/postfix/main.cf al completo, incluyendo opciones que veremos más adelante, como el soporte para TLS o el filtrado con amavisd-new: #CONFIGURACIÓN PRINCIPAL POSTFIX setgid_group = postdrop smtpd_banner = $myhostname ESMTP $mail_name (Fedora) biff = no append_dot_mydomain = no delay_warning_time = 4h command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix program_directory = /usr/libexec/postfix myhostname = webmail.mailserver.com mydomain = mailserver.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = $myhostname, $mydomain, localhost.$mydomain, localhost, mysql:/etc/postfix/mysql-mydestination.cf myorigin = $myhostname mynetworks = /8, /24 relay_domains = $mydestination mailbox_size_limit = 0 recipient_delimiter = + #mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp mailbox_transport = cyrus #SOPORTE SASL smtp_sasl_auth_enable = no Sistema de correo con Postfix, Cyrus y MySQL 19

20 smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous #smtpd_sasl_local_domain = $myhostname smtpd_sasl_local_domain = broken_sasl_auth_clients = yes #smtp_sasl_password_maps = hash:/etc/postfix/sasl/saslpass #AUTENTICACIÓN VÁLIDA smtpd_helo_required = yes disable_vrfy_command = yes smtpd_recipient_restrictions = reject_invalid_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_helo_access hash:/etc/postfix/helo_check smtpd_data_restrictions = reject_unauth_pipelining, permit #SOPORTE TLS smtpd_use_tls = yes smtpd_tls_auth_only = yes smtpd_tls_key_file = /etc/postfix/ssl/newreq.pem smtpd_tls_cert_file = /etc/postfix/ssl/newcert.pem smtpd_tls_cafile = /etc/postfix/ssl/cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom #Amavisd-New content_filter = smtp-amavis:[localhost]: sendmail_path = /usr/sbin/sendmail html_directory = no manpage_directory = /usr/share/man newaliases_path = /usr/bin/newaliases mailq_path = /usr/bin/mailq queue_directory = /var/spool/postfix mail_owner = postfix unknown_local_recipient_reject_code = 450 smtp_host_lookup = dns, native #OTHERS virtual_alias_maps = mysql:/etc/postfix/mysql-virtual.cf sender_canonical_maps = mysql:/etc/postfix/mysql-canonical.cf message_size_limit = Sistema de correo con Postfix, Cyrus y MySQL 20

21 VII - Cyrus IMAP y SASL Con la configuración y puesta en marcha de Cyrus IMAP completaremos la primera fase de instalación de nuestro servidor de correo, teniendo acceso completo a los buzones de almacenamiento de correo y al sistema de autenticación de usuarios. Esta última será protegida mediante una capa de seguridad extra entre el protocolo y la conexión. SASL Recordemos cómo en el capítulo anterior modificábamos el fichero /etc/sysconfig/saslauthd para igualar el mecanismo de autenticación a un sistema con PAM. En sistemas anteriores, el mecanismo utilizado era la autenticación directa bajo SASLDB, quedando éste relegado a la autenticación a través de PAM con la introducción de este último sistema en las distintas distribuciones de linux y, por supuetso, en las distribuciones bajo Fedora Core. Para nuestros propósitos, el sistema de autenticación pasará por el acceso de PAM a una base de datos MySQL, como ya hemos explicado en anteriores capítulos. Con el paquete cyrus-sasl ya instalado tendremos acceso a los diferentes ejecutables que nos permitirán el acceso y la manipulación de las bases de datos de usuarios, entre otras muchas opciones. Por ejemplo, el comando sasldblistusers2 listará los usuarios existentes y el comando saslpasswd2 añadirá usuarios a nuestra conveniencia. Veamos un ejemplo: # saslpasswd2 c user001 El parámetro -c nos permite añadir un usuario y el parámetro -d lo borraría de la base de datos. Si ahora utilizamos sasldblistusers2: #sasldblistusers2 user001@dominio.net : userpassword Para finalizar, limpiemos de la base de datos el ejemplo: # saslpasswd2 d user001 Otro uso de saslpasswd2 es el de asociar usuarios a dominios mediante la utilización de la opción -u: # saslpasswd2 c user002 u dominio_03.net Cyrus-IMAP La configuración de la plataforma Cyrus se establece a partir de dos ficheros fundamentales: /etc/cyrus.conf y /etc/imapd.conf. En el primero de ellos se determinan los servicios a ejecutar mediante el inicio de Cyrus. El segundo especifica los parámetros de configuración del servicio IMAP de Cyrus. Para continuar con la configuración, sería altamente recomendable que el lector de este manual leyera, aunque fuera de forma somera, la documentación incluida en la rama de directorios /usr/share/doc/cyrus-imapd y /usr/share/doc/cyrussasl, donde se incluye toda la documentación necesaria para la correcta configuración de un sistema Cyrus y sus distintas asociaciones con el programa Postfix. Sistema de correo con Postfix, Cyrus y MySQL 21

22 El fichero /etc/cyrus.conf Este fichero de configuración se compone de tres partes bien diferenciadas: 1. START: esta sección lista los scripts que se ejecutarán antes de que se arranquen los servicios. Su uso más característico es inicializar las bases de datos y lanzar los servicios de larga ejecución. 2. SERVICES: esta sección es el corazón del fichero /etc/cyrus.conf, pues describe los procesos que deberán lanzarse para atender las conexiones que los clientes hagan a ciertos sockets, bien sean tipo TCP o UNIX. 3. EVENTS: esta sección lista los procesos que deberían ejecutarse a intervalos específicos, de modo similar a los trabajos del cron. Típicamente se usa para llevar a cabo tareas programadas de limpieza y mantenimiento. El paquete rpm instalado sobre un sistema con Fedora nos deja una configuración por defecto que apenas habrá que cambiar, así que observemos como queda el fichero: START { recover cmd="ctl_cyrusdb -r" idled cmd="idled" } SERVICES { imap cmd="imapd" listen="localhost:imap" prefork=5 imaps cmd="imapd -s" listen="imaps" prefork=1 pop3 cmd="pop3d" listen="pop3" prefork=3 pop3s cmd="pop3d -s" listen="pop3s" prefork=1 sieve cmd="timsieved" listen="sieve" prefork=0 lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1 } EVENTS { checkpoint cmd="ctl_cyrusdb -c" period=30 delprune cmd="cyr_expire -E 3" at=0400 tlsprune cmd="tls_prune" at=0400 } Nótese que se han añadido las líneas correspondientes a la ejecución de los servicios de pop3 y pop3s. Para un sistema sólo con IMAP, estas líneas no se incluirían. El servicio imaps nos servirá para la configuración de IMAP sobre SSL y el servicio de sieve nos ejecutará el servicio de filtrado de correos. Hay que aclarar igualmente que en la configuración descrita se opta por la utilización de sockets UNIX, debido a que toda la configuración seguida en este manual supone que todos los servicios se ejecutarán sobre la misma máquina. En un contexto diferente (con, por ejemplo, los servidores postfix y cyrus corriendo en máquinas distintas) será necesario el uso de sockets TCP. Cada vez que hagamos cambios sobre el fichero de configuración de Cyrus, reiniciaremos el servidor para que estos se apliquen: # service cyrus-imapd restart El fichero /etc/imapd.conf Sobre este fichero definiremos los parámetros locales para el servidor IMAP. Tenemos en el interior de este fichero una serie de líneas con el formato opción: valor, donde opción es el nombre de la opción a configurar y valor el valor al cual se está estableciendo esa opción. Sistema de correo con Postfix, Cyrus y MySQL 22

23 La líneas en blanco o con almohadilla (#) al principio serán ignoradas. Repasemos alguna de las opciones más relevantes: lmtp_downcase_rcpt: esta opción, que sirve para forzar que el nombre de usuario se convierta a minúsculas, viene por defecto comentada, es decir, con valor no. Debido a que Cyrus diferencia mayúsculas y minúsculas, es una buena idea trabajar con los nombres de usuario siempre en minúsculas (el valor por defecto asume que el usuario es consciente de lo que está haciendo). Basta con quitar el comentario a la línea para establecer el valor a yes. En este artículo usaremos éste último valor. admins: esta opción permite definir los usuarios que tendrán permisos de administrador (flag a de la ACL de un buzón) sobre todos los buzones del sistema. El usuario cyrus, y únicamente él, es la opción más recomendable, por lo que bastará con descomentar la línea del fichero. Este usuario se va a autenticar mediante el método SASL, por lo que debe añadirse a la base de datos /etc/sasldb2 mediante el comando saslpasswd2, tal que # saslpasswd2 c cyrus. lmtp_admins: esta opción permite especificar una lista de usuarios, separados por espacios, que tendrán la categoría de administradores LMTP, es decir, que podrán enviar correo a través de LMTP por TCP/IP (además de aquellos definidos en la opción admins anterior). Si se van a usar socketsunix no es necesario quitar el comentario a esta opción, pues el usuario postman (valor por defecto) es autenticado automáticamente. allowanonymouslogin: esta opción permite el acceso anónimo a los buzones en cuyas ACLs se haya añadido al usuario anonymous. Carece de sentido a menos que se quieran implementar grupos de noticias, por lo que se dejará su valor por defecto no. umask: esta opción permite definir los permisos con los cuáles se guardarán los ficheros y subdirectorios dentro de /var/spool/cyrus/mail. Por defecto tiene el valor 077 (lectura y escritura para el propietario, nada para el resto), pero es conveniente permitir que el grupo (mail por defecto) tenga también permisos de lectura, pues de ese modo otras aplicaciones podrán leer el contenido de los s, por ejemplo amavisd new (bastará con que añadamos al usuario con el cuál se ejecutan a ese grupo). Todas estas configuraciones suelen venir activadas por defecto en las instalaciones base de paquetes bajo Fedora Core. allowplaintext: mediante esta opción decidimos si vamos a permitir uso del mecanismo de autenticación sasl plain. Es recomendable mantener el valor por defecto yes hasta que tengamos todo el sistema base configurado y funcionando. sasl_mech_list: esta es la lista de los mecanismos de autenticación que se van a soportar. Es útil para evitar que se prueben todos los plugings existentes y para definir el orden de los mismos. Lo igualaremos al valor PLAIN. sasl_minimum_layer: el SSF (del inglés, security strength factor) mínimo que el servidor permitirá negociar cliente. Un valor igual a 1 requiere protección de integridad; un valor más algo requiere algún tipo de cifrado. Recomienda empezar con un valor de 0 (valor por defecto), que permite login de texto plano, una vez esté todo funcionando será más sencillo aumentar la seguridad. sasl_maximum_layer: valor máximo del SSF que el servidor permitirá negociar al cliente. Es pertinente valor por defecto, 256. sasl_auxprop_plugin: Esta opción nos permite especificar los plugins del auxpropd que deseamos cargar, de estar usando sasl_pwcheck_method: auxprop. Es necesario descomentar esta línea para que use sasldb. lmtpsocket, idlesocket y notifysocket: estas tres opciones especifican las rutas para los tres sockets UNIX Cyrus. Los valores por defecto son correctos. Cabe destacar que el valor de lmtpsocket (por defecto /var/lib/imap/socket/lmtp) debe estar en consonancia con el especificado en el fichero /etc/cyrus.conf. Sobre un sistema con Fedora, ni tan siquiera son necesarias estas líneas. Observemos ahora como quedaría el fichero con las opciones por defecto utilizadas en la configuración de este manual: Sistema de correo con Postfix, Cyrus y MySQL 23

24 #imapd.conf configdirectory: /var/lib/imap partition-default: /var/spool/imap #altnamespace: # no - las subcarpetas de usuario se crean debajo de inbox. # yes - las subcarpetas del usuario se crearán a la altura de inbox. altnamespace: no lmtp_downcase_rcpt: yes #admins: Usuarios con permisos administrativos sobre todos los buzones. Añadir usuarios con saslpasswd2 -c username. admins: cyrus allowanonymouslogin: no allowplaintext: yes sasl_mech_list: PLAIN servername: mail.serverdomain.com autocreatequota: reject8bit: no quotawarn: 90 timeout: 30 poptimeout: 10 dracinterval: 0 drachost: localhost sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_pwcheck_method: saslauthd Consideraciones acerca del servidor Cyrus-IMAP Vamos a acceder a la interfaz de comandos para la gestión de Cyrus-IMAP mediante la llamada a cyradm, programa incorporado en el paquete perl-cyrus : # cyradm --user cyrus --server localhost --auth plain Password: IMAP Password: mail.serverdomain.com> Saldremos del programa de administración mediante la orden exit. Es posible que al ejecutar cyradm obtengamos el siguiente error (diferenciándose en la ruta o en la línea de error, según diferentes instalaciones): Login failed: generic failure at /usr/lib/perl5/site_perl/5.8.5/i386- linux-thread-multi/cyrus/imap/admin.pm line 118 cyradm: cannot authenticate to server with plain as cyrus Esto es debido a que el demonio saslauthd no se está ejecutando. Hay que tener en cuenta que el script /etc/init.d/cyrus-imapd no ejecuta por defecto saslauth2, por lo que comprobaremos su ejecución mediante el siguiente comando: # ps aux grep saslauthd Que nos devolverá, en el caso de una ejecución correcta, varias líneas similares a esta: root ? S Apr02 0:04 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam Sistema de correo con Postfix, Cyrus y MySQL 24

25 En caso contrario, ejecutaremos el servicio de forma manual y nos aseguraremos de su correcta activación: # chkconfig saslauthd on # service saslauthd start Recordemos, tal y como indicamos en un capítulo anterior, que los sistemas con Fedora Core o con RedHat, inician saslauthd con shadow como sistema de autenticación por defecto, lo que origina problemas a la hora de autenticar a los usuarios de los buzones bajo Cyrus-IMAP. Así que recordaremos el cambio en el fichero /etc/sysconfig/saslauthd para dejar el parámetro MECH como sigue: MECH=pam Si esto no se hace así, obtendremos un error al intentar autenticar a un usuario concreto bajo Cyrus-IMAP: # cyradm --user mail server localhost --auth plain Password: IMAP Password: Login failed: authentication failure at /usr/lib/perl5/site_perl/5.8.5/i386-linux-threadmulti/cyrus/imap/admin.pm line 118 cyradm: cannot authenticate to server with plain as mail0001 Otro aspecto a tener en cuenta del servidor Cyrus-IMAP es el uso de cuotas, cuya creación se establece mediante el uso del comando setquota en cyradm y mediante autocreatequota en el fichero /etc/imapd.conf. Para que un mensaje se pueda insertar en un buzón, éste debería tener espacio de cuota suficiente, aunque en el proceso de envío de correo sucede algo curioso: aunque el mensaje a entregar supere la cuota permitida, el mensaje se recogerá de todos modos, avisando al usuario una vez recogido el mensaje. Esto sucede de esta forma ya que si no fuera así, no habría forma de saber cuándo se quiso entregar correo y no se entregó. Si la cuota ya está por encima del límite, el envío del correo fallará, retornando un error temporal y reintentando el envío durante un par de días. Reconstrucción de la base de datos de Cyrus-IMAP Los directorios de buzones componen la base de datos más grande de un sistema Cyrus. Cada directorio se compone de los siguientes ficheros, a excepción de cyrus.seen, que se suele encontrar bajo la rama /var/lib/imap/user, el resto de ficheros pueden encontrarse bajo la rama /var/spool/imap en un sistema con Fedora Core: 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 (p. ej. 102.). cyrus.header. Contiene un número mágico e información de tamaño variable sobre el propio buzón de correo. cyrus.index. Contiene información de tamaño fijo sobre el propio buzón de correo y cada uno de los mensajes que contiene. cyrus.cache. Contiene información de tamaño variable sobre cada uno de los mensajes del buzón de correo. cyrus.seen. Ccontiene 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 es el indicado en los casos en que estos ficheros se corrompan de algún modo. En un principio, el programa intentará recuperar información a partir de los Sistema de correo con Postfix, Cyrus y MySQL 25

26 ficheros de índice y de encabezados, tal como fechas, nombre de flags, etc., recontruyendo el resto de información de la lectura de los propios ficheros de mensajes. Por lo tanto, ante un fallo de disco o una pérdida accidental de datos, podemos restaurar la información a partir de una copia de seguridad de los directorios de usuario y el programa reconstruct. Una vez reconstruidos los ficheros de control, ejecutaremos quota -f para restablecer la cuota de cada uno de los buzones a partir de los ficheros raíz. Es por lo tanto de extrema importancia hacer copia de seguridad de dos ramas de directorios en un sistema con Fedora Core: La rama /var/spool/imap, que recuperaremos mediante reconstruct, y la rama /var/lib/imap, o rama de configuración, que se restaura sin proceso posterior. Utilización de cyradm La administración de los buzones de correo se realiza mediante el programa cyradm o mediante un interfaz al uso como web-cyradm, cuya configuración detallaremos en un capítulo posterior. Usaremos alguno de los administradores definidos en /etc/imapd.conf para acceder a la consola de administración. En nuestro caso, el usuario cyrus : # cyradm --user cyrus --server localhost IMAP Password: mail.serverdomain.com> Una vez dentro de la consola, podemos teclear help para obtener un listado de todos los comandos, siendo los más importantes cm y dm, para crear y borrar buzones, respectivamente, lm, que lista los buzones disponibles, sam, que establece las ACL en un buzón, o dam, que borra las ACL de un buzón. Llegados a este punto, crearemos un buzón de prueba de la manera que sigue (nos suponemos dentro de la consola de cyradm): mail.serverdomain.comt> cm user.usr001 mail.serverdomain.com> lam user.usr001 usr001 lrswipcda Ahora ya deberíamos ser capaces de dar de alta una cuenta de correo usando el protocolo IMAP en nuestro cliente de correo y nos podríamos conectar al servidor. En un capítulo posterior a la configuración de web-cyradm repasaremos la configuración haciendo uso del programa imtest, también incluído en el paquete cyrus-imapd-utils. Sistema de correo con Postfix, Cyrus y MySQL 26

27 VIII - Cifrado del canal Como complemento a la configuración del sistema de correo con Postfix y Cyrus, estudiaremos en este capítulo la implementación de un sistema de cifrado bajo el protocolo TLS para asegurar mediante canales seguros todas las comunicaciones entre el cliente y el servidor de correo. A través de las utilidades incluidas en el paquete OpenSSL generaremos certificados de seguridad que aplicaremos a las configuraciones de los programas Postfix y Cyrus-IMAP. La emisión de un certificado de seguridad tienen un único objetivo: proporcionar información única que prueba que la máquina encargada de cifrar la comunicación es la máquina a través de la cual nuestra máquina cliente quiere establecer una comunicación. La máquina que establece la conexión mediante TLS usará la información de los certificados para iniciar un proceso de validación que evitará la intercepción maliciosa de la comunicación. Cada certificado proporcionará información sobre una autoridad que se encargará de validar el certificado enviado a través de una conexión TLS. La generación de los certificados Si pretendemos que nuestro servidor ofrezca servicio de correo a terceros y pretendemos que la comunicación con estos se realice de forma cifrada, es altamente recomendable el uso de un certificado firmado por una autoridad certificadora del tipo Verisign o Thawte. La finalidad de este manual supone el uso del servidor en la red privada de la empresa o para el disfrute de comunicaciones cifradas a título personal, por lo que será suficiente con la creación de una autoridad certificadora propia que se encargará de firmar los certificados. Las dos opciones serán igual de seguras, evitándose con la segunda el elevadísimo coste de un certificado de pago. Resumiremos por tanto los tres pasos a seguir para generar un certificado: Creación del certificado. Firma del certificado por una entidad certificadora. Instalación del certificado. Lo primero que tendremos que hacer será crear el certificado siguiendo los pasos que se detallan a continuación, atendiendo a una única salvedad: No añadiremos palabra de paso a los certificados para evitar el bloqueo del servidor al iniciarse. Creamos una nueva entidad certificadora mediante el script /etc/pki/tls/misc/ca del paquete openssl (existe otro script más completo que se obtiene de la instalación del paquete openssl-perl y cuyo uso se recomienda. La ruta de este script quedaría en /etc/pki/tls/misc/ca.pl). Adjuntaremos al comando el parámetro -newca para la creación de la nueva CA: #/etc/pki/tls/misc/ca.pl -newca Seguidamente realizaremos la petición del certificado: #/etc/pki/tls/misc/ca.pl -newreq-nodes Finalmente firmaremos el certificado: #/etc/pki/tls/misc/ca.pl -newreq-nodes -sign Sistema de correo con Postfix, Cyrus y MySQL 27

28 Los ficheros resultantes serán copiados a /etc/postfix/ssl. Estos ficheros son los siguientes: cacert.pem: el certificado de la autoridad certificadora, al cual se remitirá al cliente cuando quiera comprobar la autenticidad del certificado que le ha enviado nuestro servidor Postfix. Quedará guardado en /etc/pki/ca/cacert.pem. newcert.pem: el certificado público que enviaremos al cliente para establecer la comunicación segura. newkey.pem: el certificado privado que almacenaremos en el servidor y del cual la parte realmente importante es la clave, que debe permanecer secreta. Para convertir un fichero de clave con palabra de paso en uno sin palabra de paso, tendremos que ejecutar openssl rsa sobre el fichero de clave original. Por ejemplo, para cambiar el estado de la clave de CA generada anteriormente, teclaríamos en la consola lo siguiente: # openssl rsa -inform pem -in /etc/pki/ca/private/cakey.pem -text -out /etc/pki/ca/private/newkey.pem Para finalizar la instalación ejecutaremos los siguientes comandos: #cp cacert.pem /etc/postfix/ssl/ #cp newcert.pem /etc/postfix/ssl/ #cp newkey.pem /etc/postfix/ssl/ #chown root /etc/postfix/ssl/newkey.pem #chmod 400 /etc/postfix/ssl/newkey.pem Para evitar los avisos en los clientes de correo originados por la entidad certificadora no reconocida y tener que recurrir al pago a una entidad reconocida comercialmente, podemos usar los certificados emitidos por asociaciones del tipo CACert.org. Será necesario realizar un alta en su página web, añadir el dominio y solicitar la firma del certificado. Instalaremos entonces su certificado raíz en cada máquina y tendremos certificados firmados por una entidad reconocida con coste es nulo. Modificaciones en Postfix Las modificaciones para cifrar el canal desde postfix se harán sobre el fichero /etc/postfix/main.cf, que contendrá estas lineas adicionales (que ya se publicaron en el capítulo correspondiente a la configuración de postfix): smtpd_use_tls = yes smtpd_tls_auth_only = yes smtpd_tls_key_file = /etc/postfix/ssl/newkey.pem smtpd_tls_cert_file = /etc/postfix/ssl/newcert.pem smtpd_tls_cafile = /etc/postfix/ssl/cacert.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom Así, todas las comunicaciones y autenticaciones que se hagan a través de smtpd se realizarán mediante TLS. Para aplicar los cambios, reiniciaremos el servidor postfix. Sistema de correo con Postfix, Cyrus y MySQL 28

29 Modificaciones en Cyrus-IMAP Para activar el cifrado de la comunicación en Cyrus-IMAP atenderemos primero a las dos lineas de configuración referentes al protocolo imap en el fichero /etc/cyrus.conf, bajo la sección SERVICES: imap imaps cmd="imapd" listen="localhost:imap" prefork=5 cmd="imapd -s" listen="imaps" prefork=1 Donde observamos la ejecución del protocolo seguro de imap (imaps) y la ejecución del protocolo imap sin seguridad sólo bajo localhost (necesario para el uso de cyradm). Para continuar, añadiremos las siguientes líneas a /etc/imapd.conf: tls_cert_file: /etc/ssl/certs/cyrus-global.pem tls_key_file: /etc/ssl/certs/cyrus-global.key tls_ca_file: /etc/ssl/certs/cyrus-imapd-ca.pem Y ejecutaremos los comandos siguientes, ya que usaremos los mismos certificados que postfix: #cp /etc/postfix/ssl/newcert.pem /etc/ssl/certs/cyrus global.pem #cp /etc/postfix/ssl/cacert.pem /etc/ssl/certs/cyrus imapd ca.pem #cp /etc/postfix/ssl/newkey.pem /etc/ssl/certs/cyrus global.key #chown cyrus:mail /etc/ssl/certs/cyrus global.key #chmod 600 /etc/ssl/certs/cyrus global.key Para finalizar, observemos cómo el servidor smtp acepta comunicaciones cifradas al validarse (En azul, los comandos a introducir): # telnet localhost 25 Trying Connected to mail.server.net ( ). Escape character is '^]'. 220 mail.server.net ESMTP Postfix (Fedora) EHLO localhost 250-mail.server.net 250-PIPELINING 250-SIZE ETRN 250-STARTTLS 250 8BITMIME STARTTLS 220 Ready to start TLS QUIT QUIT Connection closed by foreign host. Los distintos métodos de autenticación disponibles se ofrecen antes de comenzar el establecimiento del canal seguro. Si alguna cosa no resultara correcta, podemos aumentar el nivel de loggin sobre el fichero /etc/postfix/main.cf y la opción smtpd_tls_loglevel en un valor de, por ejemplo, 3, que auditaremos sobre el fichero /var/log/maillog. Sistema de correo con Postfix, Cyrus y MySQL 29

30 IX - Web-Cyradm Llegados a este punto, llega a ser una necesidad poder usar un frontend que simplifique lo máximo posible las tareas básicas del administrador, como pudieran ser dar de alta o baja a nuevos usuarios, crear nuevos alias, crear nuevos dominios virtuales, administrar contraseñas, etc. web-cyradm hará exactamente esto por nosotros desde un amigable interface escrito en php. Comprobando las librerías Tal y como ya explicamos en el Capítulo II, web-cyradm necesita un intérprete/servidor de php corriendo en la parte administrativa y, obviamente, un servidor de páginas web en el mismo sitio. No es el objetivo de este manual ayudar a la configuración de ninguno de los dos servidores, aunque habrá que tener en cuenta la instalación de ciertos paquetes bajo una distribución de Fedora Core que, de no estar presentes, no permitirían el correcto funcionamiento de web-cyradm. Los paquetes a instalar son los siguientes: php Paquete contenedor del generador de páginas php 5. php-pear Colección de clases de autenticación sobre servidores web PEAR. php-mysql Librería de objetos que añaden soporte MySQL a php. php-pear-db (Sólo sobre Fedora Core 5) Clase oficial de abstracción de acceso a bases de datos de php. A partir de su versión 5, Fedora Core se distribuye con este componente separado del paquete de PEAR principal. El fichero../config/conf.php La distribución por defecto de web-cyradm nos deja un fichero de configuración por defecto llamado../config/conf.php.dist, que habrá de ser renombrado o copiado con el nombre de../config/conf.php. La primera opción con la que nos encontramos es la opción del lenguaje a utilizar: $DEFAULTLANG = "es_es"; Inmediatamente después, entraremos en la configuración de acceso al servidor Cyrus (las opciones son bastante explícitas y no necesitan de explicación adicional): #The Cyrus login stuff $CYRUS = array( 'HOST' => 'localhost', 'PORT' => 143, 'ADMIN' => 'cyrus', 'PASS' => 'secret' ); El siguiente apartado se refiere a la configuración de la base de datos. En nuestro caso, usaremos MySQL. Dado que web-cyradm usa PEAR como capa de abstracción durante el acceso a las bases de datos, sería posible el uso de otros servidores de bases de datos como PostgreSQL, teniendo en cuenta que postfix no ofrece soporte nativo para este servidor. Sistema de correo con Postfix, Cyrus y MySQL 30

31 $DB = array( 'TYPE' => 'mysql', 'USER' => 'mail', 'PASS' => 'secret', 'PROTO' => 'unix', // set to "tcp" for TCP/IP 'HOST' => 'localhost', 'NAME' => 'mail' ); Seguidamente igualaremos la opción $LOG_DIR a la ruta donde creamos el archivo de log durante la instalación del programa. En nuestro caso "/var/log/web-cyradm/". La opción $SESS_TIMEOUT establece el tiempo de inactividad necesario para considerar una sesión finalizada. Por defecto, el programa nos propone un valor de 1000, que no tocaremos a no ser que fuera necesario. $DEFAULT_QUOTA establece la cuota a asignar por defecto a los buzones cuando creamos un nuevo dominio. El valor por defecto es Encriptación de contraseñas web-cyradm soporta el almacenamiento de contraseñas encriptadas y desde aquí se recomienda encarecidamente su uso. Para establecer este nivel de encriptación, igualaremos el parámetro $CRYPT del fichero../config/conf.php al valor "crypt". Recordemos que en los ficheros que creamos en el capítulo correspondiente a la configuración de PAM, usábamos la opción crypt=1, que se corresponde con la encriptación requerida. Si preferimos crear manualmente los usuarios a través de MySQL, habremos de tener muy en cuenta esta configuración y usar la función crypt() a la hora de introducir la contraseña correspondiente. Nombres de usuarios web-cyradm nos propone dos modos de introducción de usuarios, dependiendo del valor que asignemos a la opción $DOMAIN_AS_PREFIX. Por defecto (valor 0), los nombres de usuario se asignarán sobre la base de un prefijo predeterminado (por ejemplo, test). A partir de este prefijo, web-cyradm irá asignando nombres de usuario por defecto siguiendo el patrón prefijo (en el ejemplo anterior, test001, test002,...). La otra opción a nuestra disposición (valor 1) sería el uso de nombres de usuario del tipo nombre.apellido.dominio.net. Si optamos por esta opción, tendremos que añadir o descomentar una línea en el fichero /etc/imapd.conf tal que: unixhierarchysep: yes Hay que tener en cuenta que no se pueden mezclar ambos tipos de usuario, por lo que se recomienda pensar bien la configuración antes de empezar a añadir usuarios o, en caso de duda, dar por válida la configuración por defecto. En este punto habremos terminado la configuración completa de un servidor de correo con postfix, cyrus y mysql con una interface de administración web con web-cyradm. En los capítulos posteriores comprobaremos el funcionamiento correcto de nuestra configuración y añadiremos a nuestro servidor la capacidad de filtrado de spam y virus, así como una opción para el usuario que permitirá el acceso al correo a través de la web. Sistema de correo con Postfix, Cyrus y MySQL 31

32 X - Probando la configuración Antes de continuar con la instalación de componentes adicionales, no está de más comprobar que la configuración de todos nuestros servidores funciona de forma adecuada. Mediante la herramienta telnet y un puñado de sencillos comandos, comprobaremos el funcionamiento correcto de nuestro servidor de correo. Comprobando servicios Llegados a este punto del manual, todos los componentes esenciales para el funcionamiento correcto de un servidor de correo están instalados. A pesar de todo, comprobaremos que cada uno de los servicios está corriendo. Para hacer esto, utilizaremos, en Fedora Core, el comando service, con el cual ejecutaremos las instrucciones que siguen a continuación (en negrita, las instrucciones a introducir): [root@server ~]# service postfix status Se está ejecutando master (pid 2065)... [root@server ~]# service cyrus-imapd status Se está ejecutando cyrus-master (pid 1946)... [root@server ~]# service mysqld status Se está ejecutando mysqld (pid 1822)... [root@server ~]# service saslauthd status Se está ejecutando saslauthd (pid )... [root@server ~]# service httpd status Se está ejecutando httpd (pid )... En el caso de que algún servicio estuviera caído, lo lanzaremos mediante la instrucción service <nombre del servicio> start. Para continuar, nos aseguraremos de que todos los servicios que nos interesan están a la escucha (del listado original, sólo se muestran las líneas relativas a los servicios que nos interesan): [root@server ~]# netstat -an grep LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp : :* LISTEN tcp 0 0 :::993 :::* LISTEN tcp 0 0 :::995 :::* LISTEN tcp 0 0 :::110 :::* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::2000 :::* LISTEN tcp 0 0 :::443 :::* LISTEN Los puertos, suponiendo que no se han cambiado las asignaciones por defecto de los mismos, quedan como sigue: 993 imap-ssl 995 pop3-ssl 3306 MySQL Sistema de correo con Postfix, Cyrus y MySQL 32

33 110 pop3 143 imap 2000 sieve 25 smtp 80 http 443 https Testeando Web-cyradm Conectaremos con el programa Web-cyradm mediante la cadena si hemos mantenido la configuración por defecto. En caso contrario, introduciremos la ruta asignada. Haremos login mediante el uso de las credenciales que asignamos en el capítulo anterior. Acto seguido, crearemos un nombre de dominio nuevo y alguna cuenta. Los dominios han de pertenecer a nuestro servidor, aunque podemos saltarnos el posible error validando el servidor en el fichero /etc/hosts. Tambien habremos de definir el servidor introducido como local en el fichero /etc/postfix/main.cf (mydestination = domain). Testeando postfix Para comprobar funcionamiento de postfix, intetaremos la conexión al servicio de smtp e intentaremos mandar un (en negrita, los comandos a introducir): [root@server ~]# telnet localhost 25 Trying Connected to mail.mailserver.com ( ). Escape character is '^]'. 220 mail.mailserver.com ESMTP Postfix (Fedora Core 5) helo localhost 250 mail.mailserver.com MAIL FROM: probe@mailserver.com 250 Ok RCPT TO: probe@mailserver.com 250 Ok DATA 354 End data with <CR><LF>.<CR><LF> Mensaje de prueba para probar la configuración de postfix Ok: queued as D78BD469F7B QUIT 221 Bye Connection closed by foreign host. El correo habrá quedado enviado al buzón probe. En caso de error, es bastante recomendable tener abierta una consola con la salida del fichero /var/log/maillog, que nos ofrecerá información muy valiosa sobre todo el proceso de manipulación de correos. Comprobando el canal de cifrado TLS La primera acción a realizar es la comprobación de la existencia del canal cifrado en nuestro servidor de correo: Sistema de correo con Postfix, Cyrus y MySQL 33

34 ~]# telnet localhost 25 Trying Connected to mail.mailserver.com ( ). Escape character is '^]'. 220 mail.mailserver.com ESMTP Postfix (Fedora Core 5) EHLO localhost 250-mail.mailserver.com 250-PIPELINING 250-SIZE ETRN 250-STARTTLS 250 8BITMIME STARTTLS 220 Ready to start TLS QUIT QUIT Connection closed by foreign host. Acto seguido, probaremos la autenticación mediante TLS a través de nuestro cliente de correo, asegurándonos de marcar la opción correspondiente cuando se nos pregunte acerca de si queremos o no usar un canal cifrado SSL: Probando Cyrus-Imap Para finalizar, haremos unas pruebas que nos aseguren el correcto funcionamiento del servidor de IMAP. Ya que Cyrus se autentica primero a través de SASL y después a través de IMAP, será necesario, antes de probar la configuración con las herramientas de Cyrus, asegurarse de que el usuario cyrus está cargado en la base de datos sasldb2. Esto lo haremos, tal y como se vio en el capítulo dedicado a Cyrus, mediante la herramienta saslpasswd2: saslpasswd2 -c cyrus Password: Again (for verification): Ahora probaremos la autenticación bajo cyradm: [root@server ~]# cyradm --user cyrus --server localhost --auth plain Password: IMAP Password: localhost> La primera contraseña se refiere a la contraseña introducida en la tabla sasldb2. La segunda contraseña, se refiere a la de la tabla de MySQL accountusers. Ante cualquier complicación o error inesperado, acudiremos al fichero /var/log/maillog y estudiaremos la salida. Por último, utilizaremos imtest, una herramientamuy útil que nos devolverá información sobre el servidor de IMAP: [root@server ~]# imtest -m login -a <usuario> -s localhost -w <contraseña> verify error:num=20:unable to get local issuer certificate verify error:num=21:unable to verify the first certificate TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits) S: * OK mail.mailserver.com Cyrus IMAP4 v2.3.1-invoca-rpm fc5 server ready Sistema de correo con Postfix, Cyrus y MySQL 34

35 C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL RIGHTS=kxte QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE IDLE AUTH=PLAIN SASL-IR LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH S: C01 OK Completed C: L01 LOGIN probe {9} S: + go ahead C: <omitted> S: L01 OK User logged in Authenticated. Security strength factor: 256 C: Q01 LOGOUT Connection closed. Saldremos de imtest mediante la pulsación de las teclas Control y C. Sistema de correo con Postfix, Cyrus y MySQL 35

36 XI Filtrado Tres son las herramientas fundamentales que habremos de configurar para obtener un filtrado de los correos de nuestro servidor. Sieve, lenguaje con el cual compondremos filtros en la entrega final del correo, SpamAssassin, programa con el que filtraremos el correo no deseado y ClamAV, potente antivirus que evitará la entrega de correo infectado. Al final de este extenso capítulo, probaremos el filtrado con el envío de mensajes infectados y con cabeceras que simularán spam. El uso de Sieve Aunque la forma más sencilla de utilizar Sieve es mediante algún tipo de interfaz que nos facilite la tarea y componga el script por nosotros (de hecho, en el siguiente capítulo atenderemos, entre otras cosas, a la instalación y la configuración de una interfaz que nos permita una generación de estos filtros mucho más amena.), no está de más acercarnos, aunque sea de manera somera, al uso de este lenguaje para la composición de filtros. Es necesario para la activación de un script de Sieve que un comando sea ejecutado sobre el mismo servidor mediante la herramienta sieveshell. La herramienta puede ser usada por cualquier usuario que pretenda filtrar o redirigir la entrega de correo, siendo imprescindible que el script haya sido escrito y guardado en un archivo simple de texto. Como ejemplo de uso, vamos a atender a la activación de un script de ejemplo llamado prueba.sieve: $ sieveshell -user info -authname usuario001 localhost connecting to localhost Please enter your password: > put prueba.sieve > activate prueba.sieve > ls prueba.sieve < active script > quit El uso de la consola de sieveshell es muy sencillo, no llegando a la decena el número de comandos a nuestra disposición. Para tener una idea más clara de cuáles y para qué sirven estos comandos, ejecutaremos man sieveshell en la consola del sistema. A continuación, adjuntaremos un ejemplo del uso del lenguaje utilizado por Sieve en los scripts de filtrado. Dicho ejemplo atiende a la cabecera de los mensajes para filtrar según el remitente o el asunto del mensaje: #Script de Sieve require ["fileinto","reject","vacation", "imapflags","relational", "comparator-i;ascii-numeric","regex","notify"]; if header :contains "Subject" "[SPAM]" { fileinto "INBOX.Spam"; stop; } if header :contains "From" "proveedores.net" { fileinto "INBOX.Proveedores"; } elseif Sistema de correo con Postfix, Cyrus y MySQL 36

37 header :contains "From" "proveedor01" { fileinto "INBOX.Proveedor01"; } #Fin del script SpamAssassin Tanto SpamAssassin como ClamAV serán utilizados desde Postfix y a través de Amavisd-new, que hará de interfaz entre los programas y el servidor. En un sistema con una distribución de Fedora Core, la simple instalación del paquete RPM correspondiente a SpamAssassin dejará este programa completamente instalado y configurado para su uso. Sin embargo, hay que aclarar un punto que puede ser modificado a gusto del usuario y que optimizará el funcionamiento del programa: No es necesaria la ejecución del servidor spamd sobre nuestro sistema, por lo que evitaremos la misma mediante el siguiente comando: #chkconfig --del spamassassin La principal ventaja de spamd es su eficiencia, ya que las comunicaciones se establecen a través del puerto 783 y evitan el tener que cargar un ejecutable cada vez que se hagan las comprobaciones referentes al spam. El principal inconveniente es relativo a la seguridad: aunque bajo, el riesgo de tener corriendo un servidor en un puerto siempre está sujeto a posibles vulnerabilidades por errores en el código. En nuestro caso, cargaremos SpamAssassin a través de Amavisd-new, que llamará al programa mediante el módulo de Perl Mail::SpamAssassin. Con esto conseguiremos que el motor con las reglas siempre quede cargado en memoria, obteniendo una eficiencia similar a la de la ejecución de spamd. No obstante, como hemos dicho anteriormente, esto no es más que una recomendación, quedando a gusto del usuario su aplicación. Para tener un elevado número de aciertos con el filtrado de spam, utilizaremos los llamados filtros bayesianos. Este tipo de filtrado requiere un entrenamiento para que sea eficaz en un alto porcentaje de los casos. Para ello, habremos de proporcionar a SpamAssassin un elevado número de mensajes, tanto de spam como de ham (no-spam), y esto lo conseguiremos mediante el uso de la herramienta sa-learn (ejecutaremos man sa-learn para documentarnos adecuadamente acerca de este programa). Básicamente, ejecutaremos salearn --spam <directorio> para la recolección de mensajes que sabemos a ciencia cierta son spam. Con sa-learn --ham <directorio> haremos todo lo contrario: instruiremos al programa en la recolección de correo que no es spam. Es necesario leerse las páginas del manual para ejecutar otras opciones, como la lectura de directorios por lotes. Como SpamAssassin será llamado por Amavisd-new, la ejecución de sa-learn preferiblemente tendrá que ser a través del usuario amavis. ClamAV Al igual que nos ocurría con SpamAssassin, la configuración por defecto de ClamAV es más que suficiente para el filtrado de virus sobre el servidor. En un sistema con Fedora Core y para nuestros propósitos, tendremos que asegurarnos de que el demonio clamd.amavisd se ejecuta correctamente al inicio del sistema. Ejecutaremos los comandos siguientes para conseguir nuestros propósitos: Sistema de correo con Postfix, Cyrus y MySQL 37

38 #chkconfig clamd.amavisd on #service clamd.amavisd start De esta forma evitaremos el siguiente error registrado en /var/log/maillog: ClamAV-clamd av-scanner FAILED: Too many retries to talk to /var/spool/amavisd/clamd.sock (Can't connect to UNIX socket /var/spool/amavisd/clamd.sock El demonio freshclam-sleep, incluido con el paquete clamav-update será el encargado de actualizar el antivirus mediante cron. La configuración por defecto puede verse en /etc/cron.d/clamav-update. Si necesitamos realizar modificaciones a la configuración de freshclam, lo haremos desde el fichero /etc/freshclam.conf, aunque no es recomendable. Amavisd-new El fichero de configuración de Amavisd-new se encuentra en la ruta /etc/amavisd/amavisd.conf y tiene alrededor de quinientas líneas. Para nuestros propósitos solamente será necesario cambiar una decena de ellas. La idea para el procesamiento de los correos es la siguiente: Un correo se marca como spam o como contenedor no deseado (virus, archivos exe, etc.) y se deja llegar a su destino, lugar donde, a través de un filtro con Sieve, será redirigido hacia un contenedor que alojará todos estos correos. Periódicamente, el usuario revisará el contenedor en busca de falsos positivos y borrará el resto. En caso de encontrarnos con falsos positivos, instruiremos a SpamAssassin mediante la opción forget de sa-learn. Veamos ahora las líneas del fichero /etc/amavisd/amavisd.conf que hemos cambiado para adaptarlo a los propósitos de este manual: $mydomain = 'dominio.net'; #El siguiente directorio tiene que pertenecer #al usuario amavis $QUARANTINEDIR = "/var/virusmails"; $MAXLEVELS = 14; $MAXFILES = 1500; $MIN_EXPANSION_QUOTA = 100*1024; $MAX_EXPANSION_QUOTA = 300*1024*1024; $myhostname = 'mail.dominio.net'; #Sólo en caso de necesidad $notify_method = 'smtp:[ ]:10025'; $forward_method = 'smtp:[ ]:10025'; $final_virus_destiny = D_DISCARD; $final_banned_destiny = D_DISCARD; $final_spam_destiny = D_PASS; $final_bad_header_destiny = D_PASS; #Descomentar si se quieren enviar avisos al remitente #$warnbannedsender = 1; #$warnbadhsender = 1; #Se activa el reenvio a un directorio de los mensajes #infectados. #$virus_quarantine_to = "virus quarantine\@$mydomain"; #Adjuntamos una cabecera al spam $sa_spam_subject_tag = '[SPAM] '; #Rechazamos ficheros adjuntos de los tipos siguientes $banned_filename_re = new_re( qr'\.[^./]*[a-za-z][^./]*\.(exe vbs pif scr bat cmd com cpl dll)\.?$'i, Sistema de correo con Postfix, Cyrus y MySQL 38

39 qr'[{}]', qr'.\.(ade adp bas bat chm cmd com cpl crt exe hlp hta inf ins isp js jse lnk mdb mde msc msi msp mst pcd pif reg scr sct shs shb vb vbe vbs wsc wsf wsh)$'ix, qr'.\.(mim b64 bhx hqx xxe uu uue)$'i, qr'^\.exe$'i, qr'^application/x msdownload$'i, qr'^application/x msdos program$'i, qr'^message/partial$'i, qr'^message/external body$'i, ); Obviamente, el fichero final dependerá de las necesidades de cada administrador, siendo lo anterior un mero ejemplo que adapta unas necesidades concretas. En principio, los cambios más importantes a realizar son los siguientes: o final_spam_destiny, final_virus_destiny, final_banned_destiny, final_bad_header_destiny: Mediante D_DISCARD o D_PASS permitiremos que un correo detectado se descarte o siga su curso, respectivamente, y sea enviado al directorio de cuarentena especificado. Los mensajes descartados se guardarán con las etiquetas spam, virus, banned o badh más un código de control. o warnbannedsender, warnbadhsender: Se activa el envío de un mensaje de aviso al remitente si éste ha sido baneado o las cabeceras de su mensaje están mal formadas. o virus_quarantine_to, banned_quarantine_to, spam_quarantine_to bad_header_quarantine_to: Se activa la cuarentena de los tipos detectados y se mandan al directorio especificado. o o sa_spam_subject_tag: Se añade un texto a la cabecera para su posterior filtrado mediante Sieve. banned_filename_re: Se rechazan los correos que contengan ficheros adjuntos con las extensiones mostradas. Cuando hagamos algún cambio al fichero de Amavisd-new, habremos de reiniciar el servicio con /etc/init.d/amavisd restart y será bastante recomendable observar su carga en el fichero /var/log/maillog, donde veremos los módulos cargados y los posibles errores. Modificaciones en Postfix En primer lugar, añadiremos las líneas siguientes al fichero /etc/postfix/master.cf: # Amavisd-New filtrado smtp-amavis unix - - n - 2 smtp -o smtp_data_done_timeout=1200 -o disable_dns_lookup=yes :10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= /8 -o strict_rfc821_envelopes=yes Sistema de correo con Postfix, Cyrus y MySQL 39

40 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 Y al fichero /etc/postfix/main.cf le añadiremos la siguiente línea: #Amavisd-New content_filter = smtp-amavis:[localhost]:10024 Con estas modificaciones haremos que Postfix redirija el tráfico hacia el puerto de loopback de Amavisd-new, que procesará el mensaje y lo redigirá hacia el puerto 10025, donde hemos habilitado smtpd. Una vez hechas las modificaciones, reiniciaremos Postfix con /etc/init.d/postfix restart. Filtrado de correo sobre Postfix (anti-uce) Vamos a habilitar una serie de mecanismos sobre el servidor Postfix que nos permitirán filtrar usos abusivos o malintencionados del mismo. Intentaremos denegar el uso del servidor a todo aquello que creamos que no ha sido solicitado. Para llevar a cabo nuestros propósitos, habremos de añadir varias líneas al fichero /etc/postfix/main.cf: smtpd_helo_required = yes disable_vrfy_command = 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_sender_access hash:/etc/postfix/sender_checks, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, #reject_rbl_client relays.ordb.org, permit smtpd_data_restrictions = reject_unauth_pipelining, permit Tal y como hicimos anteriormente con SpamAssassin, las restricciones aquí mencionadas deberán ser ajustadas a las necesidades de cada servidor de correo. Expliquemos con algo de detalle qué se pretende con las líneas adjuntadas, teniendo en cuenta que el orden de las instrucciones es siempre relevante: La primera y segunda sentencias aseguran que el proceso de HELO/EHLO y el envoltorio del mensaje son correctos. Se deshabilita la verificación de las direcciones de correo. Sistema de correo con Postfix, Cyrus y MySQL 40

41 Seguidamente se deshabilitará la concatenación de comandos (reject_unauth_pipelining) para evitar ataques de diccionario por parte de spammers. Con permit_mynetworks se acepta cualquier cosa que haya pasado las restricciones de más arriba, sin importar el destino. Permitimos a continuación a los clientes autenticados mediante SASL, rechazando a los que no se hayan autenticado. Con check_recipient_access comprobaremos ciertas direcciones de destinatarios antes de aplicar las listas negras locales. Comprobaremos entonces 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)). Con reject_rbl_client se especifican servidores de listas negras que añadiremos a nuestro gusto (como el especificado ordb.org). El fichero /etc/postfix/recipient_checks.pcre contendrá parámetros para revisar la sintaxis de las direcciones a filtrar. Es necesario tener activado el soporte PCRE (Perl Compatible Regular Expressions) en Postfix para su correcto funcionemiento (por defecto en los sistemas con Fedora Core): # Soporte PCRE requerido en Postfix /^\@/ 550 Invalid address format. /[!%\@].*\@/ 550 This server disallows weird address syntax. /^postmaster\@/ OK /^hostmaster\@/ OK /^abuse\@/ OK El contenido de /etc/postfix/helo_checks, cuyo cometido es comprobar que el comando HELO/EHLO no utilice ni nuestro dominio ni localhost al conectarse, será el siguiente: #Comprobaciones de HELO/EHLO liberaliatempus.com REJECT You are not in dominio.com :C webmail.liberaliatempus.com REJECT You are not mail.dominio.com localhost REJECT You are not me :C Este y todos los ficheros de tipo hash, serán compilados, una vez escritos, con el comando postmap <fichero>, que creará la base de datos Berkeley DB correspondiente. En /etc/postfix/sender_checks se incluyen los remitentes a rechazar. Veamos un ejemplo: # A compilar con postmap... spammers.com 554 Spam not tolerated here someuser@morespammers.com OK morespammers.com REJECT El fichero /etc/postfix/client_checks contiene clientes no deseados. Un ejemplo válido sería el siguiente: # A compilar con postmap... spammers.com 554 Spam not tolerated here Go away! myfriendsdomain.com OK OK Sistema de correo con Postfix, Cyrus y MySQL 41

42 Lo mismo para /etc/postfix/client_checks.pcre : # Soporte PCRE requerido en Postfix /10\.9\.8\.7/ OK /10\.9\.([89] 10)\.\d+/ 554 Go away. We don't want any! Como hemos hecho hasta ahora, reiniciaremos Postfix para aplicar cualquier cambio con /etc/init.d/postfix restart. Comprobaciones finales Para comprobar el correcto funcionamiento de nuestros filtros de contenido, mandaremos dos mensajes de correo: uno con spam y otro con el virus de muestra EICAR. Para empezar, mandaremos, preferiblemente desde una cuenta ajena a nuestro dominio, un mensaje que contendrá lo siguiente en el cuerpo del mismo (el asunto es de libre elección y el destinatario, una cuenta del dominio): This is the GTUBE, the Generic Test for Unsolicited Bulk If your spam filter supports it, the GTUBE provides a test by which you can verify that the filter is installed correctly and is detecting incoming spam. You can send yourself a test mail containing the following string of characters (in upper case and with no white spaces and line breaks): XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST- *C.34X You should send this test mail from an account outside of your network. El correo, si hemos dejado en la configuración de Amavisd-new la línea $final_spam_destiny = D_PASS, se recibirá con el siguiente contenido en su cabecera (variando según los servidores y el gestor de correo utilizado): Return-Path: probe_mail@yahoo.es Received: from murder ([unix socket]) by pegasus.domain.net (Cyrus v2.3.1-invoca-rpm fc5) with LMTPA; Sun, 26 Jun :05: X-Sieve: CMU Sieve 2.3 Received: from localhost (pegasus.domain.net [ ]) by mail.domain.net (Postfix) with ESMTP id 5656C469F7B for user001@mail.domain.net; Sun, 26 Jun :05: (CEST) X-Quarantine-ID: <dfa8ppzir6jp> X-Virus-Scanned: amavisd-new at domain.net X-Spam-Flag: YES X-Spam-Score: Sistema de correo con Postfix, Cyrus y MySQL 42

43 X-Spam-Level: ************************************************************* X-Spam-Status: Yes, score= tagged_above=2 required=6.31 tests=[awl=4.941, BAYES_50=0.001, DNS_FROM_RFC_ABUSE=0.2, GTUBE=1000,HTML_50_60=0.134, HTML_MESSAGE=0.001] Received: from mail.domain.net ([ ]) by localhost (pegasus.domain.net [ ]) (amavisd-new, port 10024) with ESMTP id dfa8ppzir6jp for Sun, 26 Jun :05: (CEST) Received: from smtp109.plus.mail.re2.yahoo.com (smtp109.plus.mail.re2.yahoo.com [ ]) by mail.domain.net (Postfix) with SMTP id 8D0BD478F59 for Sun, 26 Jun :05: (CEST) Received: (qmail invoked from network); 26 Jun :05: From: "Probe" To: Subject: [SPAM] Prueba de spam... X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express X-MimeOLE: Produced By Microsoft MimeOLE V Observemos las líneas marcadas en azul, donde se puede comprobar cómo se ha modificado el asunto del mensaje, se le ha dado un valor de al análisis (contra un valor requerido de 6.31 para ser considerado spam), tiene un nivel de spam bastante largo (****) y se ha adjuntado la cabecera X-Spam-Flag: YES para orientar al gestor de correo sobre su naturaleza. Continuaremos con el envío de un archivo adjunto que contendrá la cadena de comprobación EICAR, una simulación de virus que probará la correcta configuración de ClamAV. Para el correcto funcionamiento de esta prueba, crearemos un archivo de texto plano con esta única línea en su interior: X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* Que guardaremos con el nombre probe_av.txt y adjuntaremos en un correo nuevo que se enviará a una cuenta de nuestro dominio. Como hemos configurado Amavisd-new con $final_virus_destiny = D_DISCARD, el mensaje nunca llegará a su destino. En vez de eso, quedará guardado en la ruta del parámetro $QUARANTINEDIR, que, en nuestro caso, será /var/virusmails, con el nombre virus-<cadenaid>. Atendamos al fichero /var/log/maillog para observar qué ha pasado cuando Amavisd-new ha terminado de procesar un mensaje con un virus en su interior: Apr 30 18:28:15 pegasus amavis[12544]: ( ) local delivery: <> - > <virus-quarantine>, mbx=/var/virusmails/virus-ijhiu5tsb3no Apr 30 18:28:15 pegasus postfix/qmgr[2070]: 9A958469FB3: from= virusalert@domain.net, size=3227, nrcpt=1 (queue active) Apr 30 18:28:15 pegasus amavis[12544]: ( ) SEND via SMTP: virusalert@domain.net -> virusalert@domain.net, Ok, id= , from MTA([ ]:10025): 250 Ok: queued as 9A958469FB3 Apr 30 18:28:15 pegasus amavis[12544]: ( ) Blocked INFECTED (Eicar-Test-Signature), [ ] probe_mail@yahoo.es -> user001@ail.domain.net, quarantine: virus-ijhiu5tsb3no, Message-ID: Sistema de correo con Postfix, Cyrus y MySQL 43

44 mail_id: ijhiu5tsb3no, Hits: -, 2351 ms Apr 30 18:28:15 pegasus postfix/smtpd[14141]: disconnect from pegasus.domain.net[ ] Apr 30 18:28:15 pegasus postfix/smtp[14137]: 63BCA469FA9: to= orig_to= relay=localhost[ ], delay=3, status=sent ( Ok, discarded, id= VIRUS: Eicar-Test-Signature) Apr 30 18:28:15 pegasus postfix/qmgr[2070]: 63BCA469FA9: removed Y observemos alguna de las cabeceras de ese mismo mensaje guardado en /var/virusmails: Return-Path: <> Delivered-To: virus-quarantine X-Envelope-From: probe_mail@yahoo.es X-Envelope-To: user001@mail.domain.net X-Quarantine-ID: <ijhiu5tsb3no> X-Amavis-Alert: INFECTED, message contains virus: Eicar-Test-Signature Como la prueba del funcionamiento de Sieve es bastante personal y depende de los contenedores creados para cada usuario, dejaremos que cada administrador haga las pruebas pertinentes o esperaremos al siguiente capítulo, donde configuraremos Squirrelmail y, entre otras cosas, el front-end avelsieve. Sistema de correo con Postfix, Cyrus y MySQL 44

45 XII Squirrelmail Con el servidor de correo ya funcionando, atenderemos a la parte del frontend del usuario. Ya sea porque no queremos usar un gestor de correo o bien porque necesitamos acceder al correo vía web, la instalación de un programa como Squirrelmail que nos permita realizar las tareas más comunes se hace casi imprescindible. A través de este potente programa de webmail y además de poder acceder a todas las posibilidades del servidor de correo, el usuario podrá construir filtros de Sieve de forma casi automática, gestionar su contraseña, preparar mensajes de auto respuesta y muchas otras cosas de utilidad. Todo ello bajo un entorno seguro con cifrado de la conexión. Configuración de Squirrelmail La instalación por defecto del paquete de Squirrelmail queda bajo la ruta /usr/share/squirrelmail. Y es ahí donde nos dirigiremos para comenzar con la configuración del programa. Aunque podríamos modificar el fichero de configuración a mano, tenemos a nuestra disposición un script escrito en Perl que nos facilitará enormemente la tarea. Ejecutaremos dicho script tecleando lo siguiente en nuestra consola: # /usr/share/squirrelmail/config/conf.pl Lo cual nos devolverá una interfaz de texto bastante intuitiva que se parecerá bastante a lo siguiente: SquirrelMail Configuration : Read: config.php (1.4.0) Main Menu Organization Preferences 2. Server Settings 3. Folder Defaults 4. General Options 5. Themes 6. Address Books 7. Message of the Day (MOTD) 8. Plugins 9. Database 10. Languages D. Set pre-defined settings for specific IMAP servers C S Q Turn color off Save data Quit Command >> A continuación, vamos a repasar los puntos del menú que requieren alguna explicación. Se acompañará con la pantala de configuración por defecto para el funcionamiento del servidor de correo instalado a partir de las indicaciones de este manual. La primera opción del menú principal se refiere a los datos de nuestra compañía y generelmente sirve para rellenar los datos de la página de bienvenida: Sistema de correo con Postfix, Cyrus y MySQL 45

46 SquirrelMail Configuration : Read: config.php (1.4.0) Organization Preferences 1. Organization Name : servermail.com 2. Organization Logo : 3. Org. Logo Width/Height : (135/94) 4. Organization Title : Webmail de servermail.com $version 5. Signout Page : 6. Top Frame : _top 7. Provider link : 8. Provider name : servermail.com R C S Q Return to Main Menu Turn color off Save data Quit Command >> El segundo punto se refiere a la configuración del servidor de correo: SquirrelMail Configuration : Read: config.php (1.4.0) Server Settings General Domain : servermail.com 2. Invert Time : false 3. Sendmail or SMTP : SMTP A. Update IMAP Settings : localhost:993 (cyrus) B. Update SMTP Settings : localhost:25 R C S Q Return to Main Menu Turn color off Save data Quit Command >> El punto 3 se refiere a la configuración de las carpetas de correo. El autor recomienda dejar la configuración como sigue: SquirrelMail Configuration : Read: config.php (1.4.0) Folder Defaults 1. Default Folder Prefix : 2. Show Folder Prefix Option : false 3. Trash Folder : INBOX.Trash 4. Sent Folder : INBOX.Sent 5. Drafts Folder : INBOX.Drafts 6. By default, move to trash : true 7. By default, move to sent : true 8. By default, save as draft : true 9. List Special Folders First : true 10. Show Special Folders Color : true 11. Auto Expunge : true 12. Default Sub. of INBOX : true 13. Show 'Contain Sub.' Option : false Sistema de correo con Postfix, Cyrus y MySQL 46

47 14. Default Unseen Notify : Default Unseen Type : Auto Create Special Folders : true 17. Folder Delete Bypasses Trash : false 18. Enable /NoSelect folder fix : false R C S Q Return to Main Menu Turn color off Save data Quit Command >> El punto 8 nos va a servir para la instalación/desinstalación de los plugins que añadirán distintas funcionalidades a Squirrelmail. Tecleando el número correspondiente al plugin, lo instalaremos o desinstalaremos, según sea su estado. Cualquier plugin para Squirrelmail se instalará bajo la rama /usr/share/squirrelmail/plugins/<nombre_del_plugin>. El resto de puntos se dejarán con su valor por defecto o, en su caso, los adaptaremos a nuestras necesidades concretas (por ejemplo, el punto 10 se adaptará a nuestras preferencias de idioma). Para terminar con la configuración, grabaremos los datos mediante la opción S y saldremos a la consola con la opción Q. Suponiendo lanzado el servidor de apache, probaremos que Squirrelmail esté configurado de forma adecuada (el paquete por defecto deja instalada la extensión para apache, así que, de momento, no tenemos que modificar ningún fichero del servidor de web para lanzar Squirrelmail). Para ello, teclearemos la dirección del servidor en el navegador seguida de /webmail, lo cual nos dejará una pantalla similar a esta: Podemos terminar de probar la configuración de Squirrelmail mediante el añadido de /webmail/src/configtest.php a la dirección del servidor, lo cual realizará una conexión al servidor de correo y dará una información de estado del programa. Sistema de correo con Postfix, Cyrus y MySQL 47

48 Instalación y configuración de avelsieve Para instalar el plugin, nos situaremos a la altura de /usr/share/squirrelmail/plugins y descomprimiremos el archivo tar: # tar xvzf avelsieve tar.gz El programa creará un directorio llamado avelsieve con todos los ficheros necesarios para su ejecución. Tendremos que cargar el plugin en Squirrelmail desde la opción correspondiente del programa de configuración y, posteriormente, borrar la extensión.sample al fichero../avelsieve/config/config.php.sample. Hecho esto, ejecutaremos Squirrelmail desde nuestro navegador y, tras validarnos como un usuario de correo, veremos como una nueva opción llamada Filtros se ha añadido al menú superior de nuestro gestor de mail. Si pulsamos sobre esta opción, tendremos una pantalla parecida a esta: Pulsando sobre el botón "Añadir una nueva regla" entraremos al menú de edición de reglas. Sistema de correo con Postfix, Cyrus y MySQL 48

49 El menú, como puede observarse en la imagen, es muy intuitivo. En el apartado Condición introduciremos los campos sobre los que aplicaremos las distintas condiciones. Podemos añadir tantos campos como sea necesario. El campo Acción ejecutará la acción correspondiente si las reglas se cumplen. Por último, con Acciones adicionales, tendremos la opción de seguir comprobando reglas sobre el mismo mensaje, almacenarlo, etc. Una vez terminada la definición de la regla, pulsaremos sobre el botón Añadir una nueva regla y la regla quedará añadida y habilitada. Instalación y configuración de change_sqlpass Con change_sqlpass permitiremos que un usuario de nuestro sistema de correo gestione su propia contraseña. Esto es muy útil si no queremos tener que estar accediendo a web-cyradm constantemente o deseamos que el usuario cree su propia contraseña para cumplir con determinados requisitos legales. La instalación del plugin es similar al anterior, por lo que descomprimiremos el archivo tar a la altura de /usr/share/squirrelmail/plugins: # tar xvzf change_sqlpass tar Para el correcto funcionamiento de este plugin, es necesaria la descarga y aplicación del parche compatibility, que asegurará la compatibilidad de change_sqlpass con nuestra versión de Squirrelmail. La instalación de este plugin empezará con la extracción del correspondiente archivo tar sobre /usr/share/squirrelmail/plugins de la misma forma que hicimos con change_sqlpass. Seguidamente, aplicaremos el parche de la forma siguiente: # patch -p0 < compatibility/patches/compatibility_patch diff Suponiendo que estamos situados en el directorio plugins de Squirrelmail. El archivo diff a cargar debe de corresponderse con nuestra versión de Squirrelmail, en este caso la Esto aplicará el parche y ya podremos crear nuestro archivo config.php en el directorio /usr/share/squirrelmail/plugins/change_sqlpass. Para una configuración similar a la seguida por este manual, el archivo config.php quedaría como sigue: <?php global $csp_dsn, $password_update_queries, $lookup_password_query, $force_change_password_check_query, $password_encryption, $csp_salt_query, $csp_salt_static, $csp_secure_port, $csp_non_standard_http_port, $csp_delimiter, $csp_debug, $min_password_length, $max_password_length, $include_digit_in_password, Sistema de correo con Postfix, Cyrus y MySQL 49