1. Tutorial de ISPmail para Debian Lenny
1.1. Contenido del tutorial
1.2. Licencia/Copyright
1.3. Lista de cambios
1.4. Herramientas con las que vamos a trabajar
1.5. Sobre este documento
2. Visión general
2.1. El software que vamos a usar
2.2. El maravilloso mundo del correo electrónico
3. Tutorial de actualización desde Etch
3.1. Cambio del esquema de la base de datos
3.2. Nuevos directorios de correo en /var/mail
3.3. Archivo de configuración de AMaViS
3.4. Archivo de configuración Global Dovecot/Sieve
3.5. Ahora Dovecot crea los directorios de correo automáticamente
3.6. Notas de lanzamiento de Debian
4. La base: dominios virtuales en una base de datos
4.1. Dominios locales
4.2. Dominios virtuales
5. Instalación básica de Debian
5.1. Configuración rápida del gestor de volúmenes lógicos (LVM)
5.2. Creando las particiones
5.2.1. Creando grupos de volúmenes
5.2.2. Creando un volumen lógico para / (root)
5.2.3. Creando un volumen lógico para swap
5.2.4. Creando un volumen lógico para /var
5.2.5. Una vez configurado LVM
5.2.6. ¿XFS, ReiserFS o ext3?
5.2.7. Creando las particiones
6. Preparando el sistema
6.1. Si vas a actualizar tu servidor desde "Etch"
6.2. Paquetes a instalar
7. Preparando la base de datos
7.1. Creando la base de datos
7.2. Añadiendo un usuario con menos privilegios en MySQL
7.3. Creando las tablas de la base de datos
8. Enlaces desde Postfix a la base de datos
8.1. virtual_mailbox_domains
8.2. virtual_mailbox_maps
8.3. virtual_alias_maps
8.4. La magia negra de las asignaciones "correo-a-correo"
9. Haciendo que Postfix mande correos a Dovecot
10. Configurando Dovecot
10.1. /etc/dovecot/dovecot.conf
11. Enviando un mensaje de prueba con Telnet
11.1. Emulando una sesión SMTP con Telnet
11.2. Comprobando los registros
11.3. Comprobando el buzón de correo del usuario
12. Probando la obtención de mensajes con IMAP y POP3
12.1. Probando POP3
12.2. Probando IMAP
13. SMTP autentificado
14. AMaViS: filtrando spam y viruses
15. Gestionando tus cuentas de correo
15.1. ISPwebAdmin (interfaz web)
15.2. Autentificación de usuarios
15.3. Instalación en el servidor de (correo) destino
15.4. Autoinicio usando runit
15.5. Configurando del archivo INI
16. DNS
16.1. Cómo otros servidores de correo van a encontrar tu servidor de correo
17. Cuotas
17.1. Habilitando las cuotas en Dovecot
17.2. Configurando cuotas globales
17.3. Configurando cuotas por usuario
17.4. Qué pasa si un usuario no cumple las cuotas
18. Ofreciendo acceso desde la web
19. Filtros por parte del servidor: Sieve
19.1. ¿Qué son los filtros basados en el servidor?
19.2. El script de filtrado global de Sieve
19.3. El servidor ManageSieve
19.4. El cliente ManageSieve
20. Características adicionales
20.1. Búsqueda y filtrado con Fetchmail y Sieve
20.2. Eliminando los mensajes borrados más antiguos
21. Resolución de problemas
22. Contribuyendo a este documento
23. Agradecimientos

---

1. Tutorial de ISPmail para Debian Lenny

1.1. Contenido del tutorial

Seguramente sabrás que los proveedores de internet te permiten alquilar un dominio y utilizarlo para recibir correos. Si tienes un ordenador con Debian conectado permanentemente a internet puedes utilizarlo para tal fin. Ni siquiera necesitas tener una dirección IP fija gracias a servicios de DNS dinámicos como dyndns.org. Lo único que necesitas es este documento, una taza de café y algún tiempo. Cuando lo hagas, tu servidor podrá:

• recibir y almacenar correos de distintos usuarios y de otros servidores de correo
• permitir a los usuarios recuperar correos a través de IMAP y POP3, incluso con cifrado de conexión SSL
• recibir y enviar correos de los usuarios si se les está permitido
• ofrecer una interfaz web para leer correos con un navegador
• detectar la mayoría de los correos basura y filtrarlos o marcarlos

1.2. Licencia/Copyright

Este tutorial está protegido por los derechos de autor (Copyright 2009) por Christohp Haas (email@christoph-haas.de). Se puede usar libremente bajo los términos de la licencia GNU GPL. No te olvides de poner un enlace al artículo original, cuando lo uses (NdT: Puedes encontrar el artículo original en: http://workaround.org/ispmail/lenny). Gracias.

1.3. Lista de cambios

• 17.6.09: Se publica el tutorial para Lenny.
• 19.6.09: La página de comprobaciones SPF está temporalmente inaccesible. Se está preparando una nueva página de lucha contra correo basura, virus y phishing

1.4. Herramientas con las que vamos a trabajar

La configuración del servidor que se describe en este documento es una tarea estándar para un administrador de sistemas profesional. Dependiendo de tu nivel de conocimientos y experiencia podrás utilizar este documento con facilidad o fallar estrepitosamente maldiciendo a su autor. Necesitarás conocer o aprender diferentes aspectos sobre administración de sistemas (por ejemplo: cómo editar un archivo de texto, dónde encontrar los archivos de registro), DNS, SMTP, MySQL y POP3/IMAP. También necesitarás tener acceso como super-usuario (root) a un servidor con Debian Lenny o poder instalarlo en un equipo. Es probable que necesites cambiar los registros DNS para tu dominio. Si tu servidor está protegido por un cortafuegos (firewall) asegúrate de que puedes cambiar su comportamiento. Realizar todo este tutorial puede llevarte unas 2 horas (si eres un profesional) o una semana (si eres un principiante que, inevitablemente, comete errores). Por lo tanto, asegúrate de tomártelo con calma.

1.5. Sobre este documento

Hace unos años quise convertir mi servidor Debian en un servidor de correo con capacidad de detectar virus y correo basura, reenvío de correo electrónico ("aliasing"), acceso POP3, IMAP y a través de la web (webmail). Ya existían todos los componentes pero me llevó un tiempo conseguir que funcionasen juntos correctamente. Lo que hice fué integrar todas las horribles notas de mi escritorio en un tutorial que se ha hecho algo famoso. Teniendo en cuenta las estadísticas de mi servidor web, es la principal razón por la que la gente visita workaroung.org.

Este documento no es un simple tutorial de copiar y pegar, en el que copiar los comandos de la web y ejecutarlos en tu servidor. Por lo contrario, intentará hacerte comprender los diferentes componentes que estás configurando. Al final estarás cualificado para resolver problemas por ti mismo. Si crees que necesitas ayuda con tu configuración, prueba la sección 21. Resolución de problemas o haz una pregunta en la lista de correo. Las configuraciones de este tutorial han sido probadas en profundidad por muchos lectores. En contraste con otros tutoriales de Postfix, ésta es la quinta edición del actual. Escribir este tutorial me ha costado mucho trabajo, no son únicamente notas amontonadas, si no, es un documento consistente con intención de guiarte.

El tutorial está repartido en varios capítulos. Usa el índice para situarte en la parte que te interese. Si prefieres tener todo el contenido en una página (para imprimir) usa el enlace "printer-friendly" (NdT: esta opción no está disponible en esta traducción. Para imprimir el original en inglés haz click aquí). También puedes dejar tus comentarios en las diferentes páginas, simplemente pulsando el enlace "Añadir nuevo comentario" (NdT: esta opción no está disponible en esta traducción. Pudes hacer tus preguntas o comentarios en el foro de esdebian).

Si te ha gustado el tutorial puedes considerar hacer una donación que se destinará a los costes del servidor de prueba y a los gastos de la conexión.

---

2. Visión general

2.1. El software que vamos a usar

La configuración que vamos a describir usa los siguientes componentes, cuyas versiones son las que vienen por defecto en Debian Lenny:

• Postfix (2.5.5), para recibir correos de internet y realizar chequeos básicos
• Dovecot (1.0.15), para almacenar correos en el disco duro y permitir que los usuarios puedan acceder mediante POP3 e IMAP
• Squirrelmail (1.4.15), como interfaz web para que los usuarios puedan leer su correo usando un navegador
• MySQL (5.0.51a), como base de datos para almacenar información sobre dominios, cuentas de usuario y reenvíos de correo
• AMaViS (2.6.1), para escanear los contenidos de los correos entrantes usando ClamAV y SpamAssassin
• Clam Antivirus (0.94), para buscar virus
• SpamAssassin (3.2.5), para buscar correo basura

2.2. El maravilloso mundo del correo electrónico

Antes de entrar en detalles veamos un esquema general:

1. Se envía un correo a un servidor a través de un protocolo SMTP, con puerto TCP 25. Postfix acepta la conexión, lee el correo y hace una comprobación básica. ¿Está el remitente en la lista negra (en tiempo real)? ¿El correo proviene de un usuario autorizado y, por lo tanto, podemos evitarnos los controles de entrada? ¿Es el destinatario un usuario válido en nuestro sistema? Si aún no confiamos en el sistema remoto aplicamos greylisting. En estos momentos, Postfix puede rechazar o aceptar el correo.
2. Postfix envía el correo a través del protocolo SMTP por el puerto TCP 10024 a AMaViS para revisar el contenido. Ten en cuenta que llegados a esta etapa el correo ya no podrá ser rechazado. Por lo tanto, AMaViS puede aceptarlo o desecharlo. Generalmente, AMaViS está configurado para añadir una cabecera al correo indicándole al usuario si piensa que es correo basura.
3. AMaViS permite a SpamAssassin comprobar si el correo es correo basura. SpamAssassin irá aprendiendo que correos son basura para mejorar sus oportunidades de detección.
4. AMaViS también ejecuta ClamAV para comprobar si contiene viruses.
5. Después de las comprobaciones, AMaViS retorna el correo al proceso Postfix pero por el puerto TCP 10025. Postfix está configurado para confiar en los correos enviados a través de este puerto y no ejecutará los controles de contenido.
6. Postfix envía el correo a Dovecot, que puede aplicar filtros por usuario, y se almacenará automáticamente en las distintas carpetas si así lo desea.
7. Dovecot escribe el correo en el disco duro en formato maildir.
8. Ahora los usuarios del cliente de correo puden ver sus mensajes desde Dovecot usando los protocolos POP3 o IMAP.

---

3. Tutorial de actualización desde Etch

Este tutorial se lleva manteniendo desde el 2002. Puede que hayas seguido otras versiones del tutorial y que, ahora, quieras saber cómo actualizar apropiadamente tu servidor de correo a Lenny. Es difícil dar unas instrucciones exactas por las que guiarse, pero aquí tienes unas cuestiones a tener en cuenta.

3.1. Cambio del esquema de la base de datos

Sé que me odiarás por esto, pero el diseño normalizado de la base de datos usado en Etch ha quedado obsoleto. Por tanto, este tutorial usa un diseño más amigable, que realmente no se diferencia demasiado. Es más ligero para la base de datos porque las consultas anteriores usaban operaciones string, de forma que hacían que el servidor de correo fuese más lento cuando había un gran número de usuarios. Antes de actualizar tu base de datos haz una copia de ella (nunca se sabe). Las siguientes consultas SQL deberían hacer una transición sin incidentes al nuevo esquema:

• Crear una columna adicionar denominada "email" en la tabla "virtual_users":
  • ALTER TABLE virtual_users ADD email VARCHAR(100) NOT NULL;
• Llenar la columna "email" con las direcciones de correo completas:
  • UPDATE virtual_users LEFT JOIN virtual_domains ON
  • virtual_users.domain_id=virtual_domains.id SET
  • email=concat(virtual_user.user,'@',virtual_domains.name);

• Eliminar la columna "user":
  • ALTER TABLE virtual_users DROP user;

• Suprimir la vista "view_users":
  • DROP VIEW view_users;

• Ampliar los campos de correos en la vista "virtual_aliases":
  • ALTER TABLE virtual_aliases CHANGE source source VARCHAR(100);
  • ALTER TABLE virtual_aliases CHANGE destination destination VARCHAR(100);

• Suprimir la vista "view_aliases":
  • DROP VIEW view_aliases;

También necesitarás ajustar los archivos de configuración ".cf" de la forma que se describe en 8. Enlaces desde Postfix a la base de datos.

3.2. Nuevos directorios de correo en /var/mail

El FHS (File Hierarchy Standard) sugiere poner los correos en el directorio /var/mail. En los tutoriales anteriores se indicaba que se pusieran en /home/vmail, pero realmente ése no era su sitio; y el nuevo tutorial usa la localización /var/mail. Esta cuestión es un poco engorrosa pues tienes que mover todo tu directorio de correos. Este tutorial introduce los filtros por parte del servidor para permitir a los usuarios aplicar filtro predefinidos en los correos entrantes. Dovecot almacena estos archivos con los filtros en el directorio de correos del usuario por lo que los correos se tienen que mover un nivel más adentro en la estructura de tu directorio.

Sólo es un cambio superficial por lo que no tienes que mover tus correos, pero si lo haces, entonces cambia los siguientes archivos:

• /etc/dovecot/dovecot.conf: mail_location=maildir:/var/vmail/%d/%n/Maildir (En las primeras versiones del tutorial de Etch no se usaba un subdirectorio "Maildir". Así que, si ya tienes un directorio sin esta estructura, tienes que crear una carpeta Maildir en el lugar indicado y mover todas las carpetas de los correos (cur, new, tmp y todas las carpetas que tengan un punto al principio del nombre). Si no, el filtro basado en "sieve" que se describe en este tutorial, no funcionará).
• /etc/dovecot/dovecot.conf: Revisa la sección "namespace private" para cambiar "/home/vmail" por "/var/vmail".

3.3. Archivo de configuración de AMaViS

Antes el tutorial recomendaba poner tu propia configuración de AMaViS en el archivo /etc/amavis/conf.d/20-debian_defaults. Como consecuencia este archivo puede ser alterado durante una actualización. Por lo tanto debes mover tu archivo de configuración a /etc/amavis/conf.d/50-user.

3.4. Archivo de configuración Global Dovecot/Sieve

En las últimas versiones de Dovecot ha cambiado el directorio de configuración para el archivo del filtro global sieve. Antes se configuraba como "global_script_path" en la sección "protocol lda". Ahora se configura en "sieve_global_path" en la sección "plugin" de /etc/dovecot.conf. Más información.

3.5. Ahora Dovecot crea los directorios de correo automáticamente

La versión de Dovecot presente en Debian Etch arrojaba errores si un usuario accedía a su bandeja de correo y aún no había recibido ningún mensaje. La versión de Debian Lenny no presenta este problema, por lo que no tienes que enviarle al usuario un correo de bienvenida o crear un directorio de correo manualmente.

3.6. Notas de lanzamiento de Debian

También deberías de leer las notas de lanzamiento de Debian Lenny antes de intentar actualizar tu sistema de Etch a Lenny.

---

4. La base: dominios virtuales en una base de datos

Antes de entrar en datalles sobre los dominios virtuales vamos a comprender el concepto...

4.1. Dominios locales

Postfix es el componente que recibe los correos desde internet. Generalmente Postfix conoce los dominios locales (NdT: local domains) (configurados en las opciones de "mydestination") y los usuarios locales (NdT: local users) (los que pueden entrar en el sistema y que se encuentran en el archivo /etc/passwd). Esto indica que todos los usuarios del sitema recibirán correos de cualquier dominio local. Como ejemplo podría ser:

mydestination = example1.com, example2.com, example3.com

Pongamos que has creado un usuario llamado "johndoe" (por ejemplo usando el comando adduser). Esta simple configuraión permitirá a Postfix recibir correos de:

• johndoe@example1.com
• johndoe@example2.com
• johndoe@example3.com

No puedes hacer que la cuenta de johndoe funcione sólo con un dominio. Pero esto no es factible para diferentes usuarios de diferentes dominios. Tampoco funcionará correctamente con muchos usuarios pues tendrías que crear cuentas de sistema para cada uno.

4.2. Dominios virtuales

En vez de difinir tus dominios de correo en un archivo de texto y crear muchas cuentas del sistema, hay una opción mejor para los servidores de correo basados en Postfix. Los nombres de los dominios y las cuentas de usuario se pueden almacenar en un directorio tal como LDAP o una base de datos como MySQL o PostgreSQL. Postfix sólo necesitará saber cómo acceder a la base de datos para conseguir la información de control. En tal caso, los dominios de configuración del correo de los que se encargará Postfix, de denominarán dominios virtuales (NdT: virtual domains). De forma similar, las cuentas de usuario se denominarán usuarios virtuales (NdT: virtual users). Sólo existen en la base de datos.

Hay dos tipos básicos de dominios virtuales que reconoce Postfix. Los "dominios con sobrenombre virtual" (NdT: "virtual alias domains") se usan para transmitir mensajes de una dirección de correo a otra (o otras). Los dominios con sobrenombre virtual no reciben mensajes de ningún usuario, sólo los envían. Las asignaciones "virtual_alias_maps" contienen transmisiones (origen, destino) de usuarios o dominios a otras direcciones de correo o a todos los dominios. Al mismo tiempo, virtual_alias_maps también funcionan para las direcciones de correo locales. Por tanto, realmente no necesitas dominios con sobrenombre virtual pues puedes declarar todos los dominios como dominios virtuales de correo y usar virtual_alias_maps para los sobrenombres.

El otro tipo de dominios virtuales son los "dominios virtuales de correo" (NdT: "virtual mailbox domains") que son más importantes en este caso, pues definen los dominios que se usan realmente para recibir mensajes.

¿Esto te empieza a sonar raro? No te preocupes. Veamos un ejemplo de una tabla de base de datos que indica qué usuarios pueden recibir mensajes y dónde deberían guardarse en tu sistema:

Ejemplo de virtual_mailbox_maps:

La tabla anterior es un ejemplo perfectamente válido de por qué Postfix espera por una asignación llamada "virtual_mailbox_maps".

Aunque puedas decir que la tabla anterior contiene toda la información necesaria, hay una cosa más que Postfix necesita: una lista de dominios (virtuales). En el ejemplo anterior, esa lista debería consistir en doe.org y foo.org. Esa tabla de asignación podría usarse como "virtual_mailbox_domains" y se parecería a esto:

Ejemplo de virtual_mailbox_domains

Probablemente te preguntarás por qué hay una segunda columna con datos aparentemente innecesarios. La razón es que Postfix siempre necesita dos columnas en una asignación. La primera columna es la clave y contiene lo que Postfix está buscando. La segunda columna es lo que le dice a Postfix lo que tiene que hacer. Para la tabla de dominios virtuales, Postfix sólo busca cualquier resultado no vacío en una línea, donde se muestra el dominio en la primera columna. Hay gente que sólo escribe "OK", no importa.

Has visto que una asignación da un valor a otro. Si haces consultas en una base de datos, necesitas indicarle a Postfix las dos columnas correspondientes. Esto se hace a través de los archivos de configuración ".cf", como se describe en http://www.postfix.org/MYSQL_README.html o en "man 5 mysql_table".

Archivo de ejemlo:

# Information on how to connect to your MySQL server
user = someone
password = some_password
hosts = 127.0.0.1

# The database name on the servers.
dbname = mailserver

# The SQL query template.
query = SELECT destination FROM virtual_aliases WHERE source='%s'

Este archivo define la forma en que Postfix puede conseguir datos de la base de datos. Puede ser apropiado para una asignación virtual_alias_maps (se usa para envío de mensajes, ya lo explicaré más adelante). Imagínate que has guardado las líneas anteriores en un archivo de configuración /etc/postfix/mysql-virtual-alias-maps.cf, luego, la siguiente línea en tu /etc/postfix/main.cf haría que Postfix consultase la base de datos:

virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_alias_maps.cf

¿Cómo funciona? Imagínate que Postfix está a punto de enviar un mensaje a john@doe.net y quiere comprobar la asignación del sobrenombre virtual. Luego Postfix realiza una conexión con el servidor MySQL en la dirección IP 127.0.0.1 y entra en el servidor MySQL con el nombre de usuario someone y la clave some_password. Selecciona la base de datos mailserver y ejecuta la consulta reemplazando '%s' por lo que está buscando:

SELECT destination FROM virtual_aliases WHERE source='john@doe.net'

Supón que la consulta muestra los siguientes resultados:

• jack@example.com
• jeff@example.com
• kerstin@example.com

Esto pasaría si tienes un archivo de texto con unos sobrenombres como:

john@doe.net -> jack@example.com, jeff@example.com, kerstin@example.com

Esto es suficiente para una introdución rápida de cómo se usan las asignaciones en las bases de datos.

---

5. Instalación básica de Debian

A no ser que tengas un servidor con Debian preinstalado, deberías de hacer la instalación por ti mismo. Esto te daríala oportunidad de seleccionar las particiones y el sistema de archivos. Puedes saltarte el apartado 5. si no tienes acceso a la consola o no quieres hacer una (re)instalación nueva.

En líneas generales, tu sitema debería tener por lo menos 2GB de RAM y un buen montón de espacio en discos duros montados en un controlador RAID basado en hardware. Los usuarios juntarán un montón de mensajes con un montón de adjuntos inútiles, y no esperes que limpien sus bandejas de entrada, especialmente cuando ofrezcas IMAP. Necesitarás un disco de 500GB para 100 usuarios. Con respecto a la carga del procesador, la mayoría será debida a los buscadores de virus y correo basura. Probablemente un sitema de cuatro núcleos procesará entre 5 y 10 mensajes por segundo. Si no necesitas un rastreador de correo basura te servirá un procesador de menor capacidad.

Por cierto, he creado una pequeña grabación con los primeros pasos y, especialmente, el particionado del servidor con el gestor de volúmenes lógicos. Si te quedas atascado en algún momento pudes ver el vídeo aquí (en formato OGG).

Inserta uno de los dispositivos de arranque (el CD de instalación por red o el primer DVD) y arranca el sistema. Deberías de ver la siguiente pantalla:

Selecciona "Install".

Luego te preguntará el lenguaje por defecto en tu sistema:

Selecciona siempre "English" aunque tu lengua sea otra, de lo contrario los procesos del sistema podrían no escribir los mensajes de carga en inglés, lo que puede ocasionar problemas en los scripts automáticos. Además, si tienes que buscar ayuda por internet puedes encontrarla más fácilmente si tienes los mensajes en inglés.

Continúa seleccionando tus opciones hasta llegar al menú de particionamiento:

Elige "Manual" para poder usar el gestor de volúmenes lógicos (LVM). ¿Gestor de qué...?

5.1. Configuración rápida del gestor de volúmenes lógicos (LVM)

Es muy recomendable que elijas usar el gestor de volúmenes lógicos (LVM). Esto asusta a muchos administradores de sistemas pero no es ni la mitad de complicado de lo que puedas esperar. Además Debian te hace la configuración inicial. Estas son algunas de las ventajas que obtendrás si usas LVM:

• Puedes crear particiones que ocupen varios discos duros. (Ten en cuenta que sin un controlador RAID por hardware apropiado y discos redundantes, cada disdo físico puede convertirse en un potencial punto de fallos.)
• Puedes extender particiones (hacerlas más grandes) sin particionar o tener que desmontar un sistema de archivos. ¿Tu sistema de archivos está lleno? Sólo tienes que escribir dos comandos para conseguir espacio libre, ¡esto no tiene precio!
• No tienes que decidir cuánto espacio necesitarás para cada partición. Hazlas pequeñas y ya las extenderás cuando lo necesites.

Este es el vocabulario LVM que necesitas conocer:

• Volúmenes físicos (PV): particiones actuales de los discos duros, como /dev/sda1
• Grupos de volúmenes (VG): puedes combinar volúmenes físicos para conseguir más espacio del que un disco duro podría darte
• Volúmenes lógicos (LV): una partición lógica hecha con partes de grupos de volúmenes (VG), aquí es donde vas a poner tu sistema de archivos
• Extensiones físicas (PE): LVM gestiona tus volúmenes físicos en pedazos de 4MB, por lo que tu grupo de volúmenes siempre tendrá un tamaño múltiplo de 4MB.

Resumiento: tienes unas cuantas particiones clásicas (PVs), las combinas en una mayor (VGs) y las divides (PEs) en particiones lógicas (LVs) en las que pondrás tu sistema de archivos. Un diagrama puede ayudarte a visualizar la situación. La primera imagen es un típico servidor de correo sin particionamiento LVM:

Puedes observar que las particiones y sus tamaños son inamovibles. Si necesitases más espacio en "/" estarías muy condicionado, teniendo que copiar todo a un nuevo disco y ocasionando que el servidor estuviese mucho tiempo fuera de servicio. Con LVM la situación podría ser esta:

En la imagen de arriba tienes dos discos duros físicos, /dev/sda y /dev/sdb. Teóricamente es posible arrancar el sistema desde una partición LVM pero se recomienda tener una partición para tal efecto. Por tanto /dev/sda1 es la pequeña y clásica partición en ext2 o ext3. /dev/sda2 y /dev/sdb1 son particiones de tipo 8e (Linux LVM). Estas dos particiones son los volúmenes físicos que proveen el espacio físico real, donde se almacenan los datos. Están agregadas en un grupo de volumen denominado "vgmain" (este nombre sólo es un ejemplo, puedes poner el que quieras). Ahora, este grupo de volumen de divide en volúmenes lógicos, que son particiones en las que puedes poner sistemas de archivos y montarlas como de costumbre. El volumen lógico denominado "lvvar" te aparecerá en el sistema como /dev/mapper/vgmain-lvvar y se puede usar como una partición física. Y, en este ejemplo, sigues teniendo 537GB para ampliar / o /var si lo necesitas, por falta de espacio.

(Si sigues sin estar seguro de haber entendido el LVM, puedes encontrar una buena explicación en tuxradar.)

5.2. Creando las particiones

Volviendo a cuando seleccionamos "Manual", ahora deberías ver una pantalla similar a la siguiente (tu disco duro debería ser mayor de 8GB):

Desplázate hasta la línea "FREE SPACE" y presiona entrar. Empecemos con /boot. Selecciona crear una nueva partición y hazla, por lo menos, de 100MB. Ahora te preguntará cómo quieres usar esa partición:

Deja las opciones como se muestra en la anterior imagen. Debería ser ext2 o ext3, montada en /boot y tener la marca de arranque. Luego elige "Done setting up the partition". Volverás a la vista general de tus particiones en la que puedes ver tu nueva partición /boot:

Selecciona todo el espacio restante como "physical volume for LVM" como se muestra:

Ahora que has creado un volumen físico tienes la nueva opción en la vista general de "Configure the Logical Volume Manager":

Selecciona esta opción y, luego de una rápida confirmación en la que deberás elegir "Yes", entrarás en el configurador de LVM:

5.2.1. Creando grupos de volúmenes

Crea un (nuevo) grupo de volúmenes y ponle un nombre, por ejemplo puedes llamarlo "vgmailserver" ("vg" indica claramente que es un grupo de volúmenes (NdT: volume group)). Te preguntará que volúmenes físicos formarán parte del grupo, selecciónalos.

5.2.2. Creando un volumen lógico para / (root)

Ahora usa este grupo de volúmenes para "crear un volumen lógico" (NdT: "Create a logical volume") y selecciona tu grupo de volúmenes (vgmailserver) para contenerlo. Dale al nuevo volumen lógico un nombre indicativo, como "lvroot" ("lv" deja claro que es un volumen lógico (NdT: logical volume)). Que ocupe unos 2GB. Esta partición contendrá los binarios básicos de tu sistema operativo.

5.2.3. Creando un volumen lógico para swap

Aunque tengas mucha RAM deberías crear una partición swap. Se usará como memoria de intercambio para partes de tu memoria que no se necesiten activamente. La RAM liberada puede ser usada automáticamente como cache de disco. Crea otro volumen lógico "lvswap" como una partición swap y dale 1GB. (Si tu sistema empieza a "swapear" como loco significa que tienes demasiada poca RAM o que algo anda mal y aunque pongas más swap no va a mejorar. Nota: Un servidor de correo decente tiene, por lo menos, 2GB de RAM.)

5.2.4. Creando un volumen lógico para /var

Esta partición es dónde se almacenarán tu base de datos (/var/lib/mysql) y tus directorios de correo (/var/mail). Seguramente necesitarás expandir esta partición más tarde. Por tanto, crea otro volumen lógico "lvvar". A no ser que conozcas cuanto espacio vas a necesitar, empieza con 2GB.

(Si quieres ganar puntos extra podrías separar los volúmenes lógicos para /var/lib/mysql y /var/vmail. Esto te permitirá hacer rápidas copias de seguridad de MySQL, bloqueando las tablas; haciendo una instantánea de LVM y respaldando con seguridad los archivos. Esto es más rápido que el método de la vieja escula de usar mysqldump. También puedes poner la bandera de montaje como "noatime" en /var/mail para evitar accesos de escritura extas, en cada acceso de lectura de un mensaje. También puedes crear un volumen lógico para /tmp o, si tienes suficiente RAM, usar tmpfs para ello. Ten en cuenta que los escáneres de virus ocupan espacio en /tmp, por lo que no escatimes espacio en esta partición.)

5.2.5. Una vez configurado LVM

En el diálogo "Partition disks" puedes seleccionar "Display configuration details" y verificar que tu configuración LVM se parezca a esto:

Finaliza la configuración de LVM, los volúmenes lógicos deberían verse como:

Todo lo que queda es darle formato a los volúmenes lógicos. Formatea "lvroot" usando un sistema de archivos XFS montado en "/". Formatea "lvvar" con un sistema de archivos XFS montado en "/var". Finalmente configura "lvswap" como un área de intercambio.

5.2.6. ¿XFS, ReiserFS o ext3?

Hay disponibles distintos sistemas de archivos y mucha gente sigue usando ext3. XFS, ReiserFS y Ext3 son "journaling file systems". Parece que ext3 no confía demasiado en su "journaling" porque después de un determinado número de veces montado, o después de cierto tiempo y de un reinicio, ¡hace un chequeo completo del sistema de archivos! ¿Eso no suena mal? En la vida real significa que si después de medio año de funcionamiento de tu servidor de correo, si necesitas reiniciar, es mejor que consigas una olla de café porque este chequeo puede llevar horas o, en los peores casos, días. Esto es totalmente inaceptable. Este chequeo automático del sistema de archivos puede deshabilitarse, pero no me da confianza.

Ten en cuenta que XFS también tiene desventajas. Una de ellas es que estas particiones sólo se podrán expandir, no encoger. XFS también es problemático si tu servidor se muere de repente, por su caché de escritura. Por tanto se recomienda un caché de escritura soportado con batería o una fuente ininterrumpida de energía (UPS). Si estas desventajas son demasiado importantes para ti, puedes optar por ReiserFS.

5.2.7. Creando las particiones

Si has seguidos los pasos antereriores deberías ver una pantalla como esta:

Es cierto que se trata de mucho trabajo, pero es un tiempo bien invertido. Si luego necesitas más espacio en cualquiera de estas particiones no tendrás que tener desconectado tu servidor. Por ejemplo, si necesitas 10GB más en /var tendrías que teclear estos dos comandos:

• lvextend -L +10G /dev/vgmail/lvvar
• xfs_grow /var

(Por cierto, si quieres crear un CD de rescate, con grml por ejemplo, por si algo sale mal y necesitas recuperar tus datos de una partición LVM; arranca el CD con grml lvm y tus volúmenes lógicos se activarán automáticamente y podrás montarlos.)

---

6. Preparando el sistema

6.1. Si vas a actualizar tu servidor desde "Etch"

Si has actualizado tu servidor desde una instalación de Debian 4.0 "Etch" puedes necesitar corregir dos archivos. Primero asegúrate de que tu /etc/hostname contiene el nombre del host sin la parte del dominio. Así estará en Lenny por defecto, pero si estás actualizando desde "Etch" puede que no esté de la forma correcta. El archivo /etc/mailname se supone que tiene que contener el "fully-qualified host name" con la parte del dominio.

Tu /etc/hosts también puede necesitar ser corregido. Ejecuta hostname --fqdn y mira si obtines el "fully-qualified host name". Si sólo obtienes el nombre del host sin el dominio, revisa que tu archivo /etc/hosts tenga el "fully-qualified hostname" al principio de la lista.

• Incorrecto: 20.30.40.50 mailserver42 mailserver42.example.com
• Correcto: 20.30.40.50 mailserver.42.example.com mailserver42

6.2. Paquetes a instalar

Vamos a empezar instalando Postfix con soporte para MySQL:

$> aptitude install postfix-mysql

Esto también instalará el paquete postfix automáticamente. Exim (el servicio de correo por defecto en una instalación nueva) se desinstalará. Cuando te pregunte por el tipo general de configuración escoge "Internet Site". Responde a la pregunta de "System mail name" poniendo el "fully-qualified hotname" de tu sistema.

Ejecuta esta línea para instalar el servidor MySQL:

$> aptitude install mysql-server

Nota: Puedes ejecutar el servidor MySQL en el mismo sistema que tu servicio de correo existente, pero no tiene que hacerlo. El servicio de correo puede comunicarse con el servidor MySQL a través de una conexión TCP. Durante la instalación te preguntará por la contraseña de un nuevo usuario "root", que no es la cuenta de administrador de tu sistema, pero es un usuario especial para acceder al servidor MySQL. Elige una contraseña y escríbela. Y otro aviso, durante la instalación se creará la cuenta de usuario de MySQL llamada "debian-sys-maint" con una contraseña aleatoria, que se guarda en el archivo /etc/mysql/debian.conf. No toques este archivo ni cambies la contraseña de usuario en la base de datos o nunca más podrás parar ni iniciar el servicio MySQL.

Querrás ofrecer los sevicios POP3 e IMAP a tus usuarios, por lo que necesitas instalar los servicios de Dovecot:

$> aptitude install dovecot-pop3d dovecot-imapd

Algunos de los paquetes que necesitas para comprobar los posibles adjuntos infectados con virus no son "lo suficientemente libres" para estar incluidos en la sección main de los repositorios Debian (por ejemplo "unrar" y "lha"). Si los quieres instalar primero tienes que añadir la sección non-free en la lista de repositorios presente en /etc/apt/sources.list. Generalmente sólo es necesario añadir "non-free" a las líneas de los servidores, tal como:

deb http://ftp.debian.org/debian/ lenny main non-free

Y ejecutar:

$> aptitude update

Para actualizar el caché de paquetes añadiendo los "non-free".

Es bueno para tus usuarios que añadas un filtro contra el correo no deseado y los víruses. AMaViS hace un buen trabajo detectanto mensajes no deseados:

$> aptitude install amavisd-new spamassassin clamav-daemon lha arj unrar zoo nomarch cpio lzop cabextract

AMaViS se instalará con un número de paquetes sugeridos para escanear adjuntos en busca de víruses y detectar correo no deseado.

Si vas a ofrecer un servicio de correo mediante la web te puedo recomendar el paquete Squirrelmail. Te instalará automáticamente el servidor web de Apache, si aún no tienes ninguno instalado. Escribe:

$> aptitude install squirrelmail

Como tu información de control para Postfix se almacenará en una base de datos MySQL, puede que quieras instalar el software PhpMyAdmin que te permite gestionar la base de datos y sus datos por medio de un navegador web:

$> aptitude install phpmyadmin

(Si te pregunta qué servidor web configurar probablemente quieras elegir "apache2".)

El cliente de correo basado en consola mutt te permite leer mensajes directamente desde las carpetas de correo de tu disco duro. Te puede ser muy útil para probar la configuración y, es un cliente de correo IMAP muy potente que mucha gente usa como su principal programa para leer los mensajes. Puede que a ti también te empiece a gustar. Deberías instalarlo aunque sólo sea para hacer pruebas:

$> aptitude install mutt

Con esto tienes todos los paquetes básicos instalados y es hora de preparar la base de datos, en el próximo apartado.

---

7. Preparando la base de datos

Tu servidor Debian debería estar instalado. Es hora de preparar la base de datos MySQL que almacenará la información que controla tu servidor de correo. En el proceso tendrás que ejecutar consultas SQL. Las puedes introducir en la línea de comandos de "mysql", pero si no tienes mucha experiencia con MySQL te sugiero que empieces de una forma sencilla escribiendo en tu navegador de internet esta URL: http://TU-SERVIDOR-DE-CORREO/phpmyadmin. Deberías ver una página web como esta:

7.1. Creando la base de datos

Tu primera tarea es crear una base de datos en MySQL. Le llamaremos "mailserver". En una consola de superusuario (root) ejecuta este comando:

$> mysqladmin -p create mailserver

Te preguntará por la contraseña de "superusuario" (root) de MySQL que has introducido cuando instalaste el paquete MySQL.

(En phpMyAdmin lo puedes hacer escribiendo "mailserver" en el campo de "Create new database" y pulsando "Create".)

7.2. Añadiendo un usuario con menos privilegios en MySQL

Por razones de seguridad deberías crear otra cuenta de usuario de MySQL, con menos privilegios. Postfix sólo necesita leer de la base de datos por lo que no necesita acceso con privilegios de escritura.

Conéctate a tu base de datos:

$> mysql -p

Cuando veas el puntero mysql> escribe la siguiente sentencia SQL (lo que tienes que escribir se muestra en negrita) para dar los privilegios apropiados.

mysql>
GRANT SELECT ON mailserver.*
TO 'mailuser'@'127.0.0.1'
IDENTIFIED BY 'mailuser2009';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye

(También lo puedes hacer en phpMyAdmin siguiendo estos pasos: Pulsa en "Privileges". Selecciona "Add a new User" y como "User" escribe "mailuser". Como "Host" elige "local". Y la clave que tienes que escribir dos veces es "mailuser2009". Pulsa en "Go". Ahora busca "Database-specific privileges" y selecciona la base de datos "mailserver. En la siguiente página tica la casilla "SELECT" y presiona "Go".)

Esto creará un usuario llamado "mailuser" que sólo tiene privilegios para seleccionar y leer datos, no puede alterarlos. Si quieres añadir o alterar datos de la base de datos puedes usar la cuenta de "root" o crear otra cuenta para tal fin. La contraseña "mailuser2009" sólo es un ejemplo, cámbiala por otra mejor. Si andas falto de creatividad puedes usar "pwgen" o "apg" para crear buenas contraseñas.

7.3. Creando las tablas de la base de datos

Dentro de la recién creada base de datos tendrás que crear tablas para guardar información de los dominios, de las transmisiones y de las carpetas de correo de los usuarios. Es fácil crear las tablas de la base de datos usando SQL en vez de ir clicando a través de phpMyAdmin.

Conéctate de nuevo a MySQL y elige la base de datos "mailserver":

$> mysql -p mailserver

Verás de nuevo el puntero mysql>. Primero crea una tabla para la lista de dominios virtuales que quieres organizar:

mysql>
CREATE TABLE `virtual_domains` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(50) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

La siguiente tabla contiene información de las cuentas de usuario reales. Cada usuario tiene un nombre de usuario y una contraseña. Se usa para acceder a las carpetas de correo por POP3 o IMAP, entrar desde la web o para enviar un mensaje ("relay") si no se encuentran en tu red local. Como los usuarios tiende fácilmente a olvidarde de de cosas, las direcciones de correo de los usuarios también se usan como nombres de usuario para iniciar sesión. Vamos a crear la tabla de usuarios:

mysql>
CREATE TABLE `virtual_users` (
`id` int(11) NOT NULL auto_increment,
`domain_id` int(11) NOT NULL,
`password` varchar(32) NOT NULL,
`email` varchar(100) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `email` (`email`),
FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

El campo email contendrá las direcciones/nombres de usuario del correo, el campo password contendrá un hash MD5 de la contraseña del usuario. La unique key del campo email asegura que no haya dos usuarios en un mismo dominio.

Y, finalmente, se necesita la tabla para los sobrenombres (aliases) (transmisiones de mensajes de una cuenta a otra):

mysql>
CREATE TABLE IF NOT EXISTS `virtual_aliases` (
`id` int(11) NOT NULL auto_increment,
`domain_id` int(11) NOT NULL,
`source` varchar(100) NOT NULL,
`destination` varchar(100) NOT NULL,
PRIMARY KEY (`id`),
FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

En este caso, la columna source contiene las direcciones de correo de los usuarios a los que quiere enviar su mensaje. En caso de direcciones de correo catchall la columna "source" mostrará "@domain". La columna destination contiene las direcciones de correo objetivo. Como se describió en 4. La base: dominios virtuales en una base de datos, puede haber varias filas para una dirección de correo "source" designando los múltiples destinos que obtendrán una copia del mensaje.

Puede que te estés preguntando sobre las foreign keys. Expresan que entradas en las tablas "virtual_aliases" y "virtual_users" se conectan a las entradas de la tabla "virtual_domains". De esta forma los datos de tu base de datos se mantendrán compatibles porque no puedes crear sobrenombres virtuales o usuarios virtuales que no estén conectados a un dominio virtual. El sufijo "ON DELETE CASCADE" significa que si borras una fila de la tabla referenciada, ese borrado también se hará automáticamente en la tabla en la que te encuentres; así no dejas entradas huérfanas por accidente. Imagina que ya no vas a organizar más un dominio, puedes borrar la entrade de ese dominio de la tabla "virtual_domains" y todas las entradas dependendientes/referentes en las otras tablas también se borrarán. (Sin embargo, esto no borraría automáticamente los directorios físicos de correo de tu disco duro.)

Un ejemplo de los datos en las tablas:

Vamos a añadir un sobrenombre:

Esto hará que un mensaje para steve@example.com se redireccione a devnull@workaround.org; un mensaje para kerstin@foobar.org se redireccionará a los dos correos kerstin42@yahoo.com y kerstin@mycompany.com. Ni Steve ni Kerstin recibirán una copia del mensaje.

---

8. Enlaces desde Postfix a la base de datos

Ahora la base de datos está lista para ser rellenada con la información de las cuentas de los usuarios. El punto de partida para todos los correos en tu sistema es Postfix. Por tanto necesitamos decirle a Postfix cómo conseguir la información almacenada en la base de datos. Empecemos diciéndole cuáles son nuestros dominios virtuales.

8.1. virtual_mailbox_domains

Como describimos anteriormente, las asignaciones en Postfix sólo son una tabla que contiene dos columnas. Para hacer que Postfix use MySQL para definir una asignación necesitamos un archivo ".cf" (archivo de configuración). Empieza creando un archivo llamado /etc/postfix/mysql-virtual-mailbox-domains.cf para las asignaciones "virtual_mailbox_domains", que contenga:

Imagina que Postfix recibe un mensaje de somebody@example.com y quiere averiguar si example.com es un dominio de correo virtual. Ejecutará la anterior consulta SQL y reemplazará '%s' por 'example.com'. Si, por lo menos, encuentra una entrada en la tabla virtual_domains devolverá un '1'. Realmente no importa lo que devuelva exactamente, con tal de que devuelva algo.

Y necesitas hacer que Postfix use esa asignación de la base de datos:

$> postconf -e virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

(El comando postconf -e añade convenientemente líneas de configuración a tu archivo /etc/postfix/main.cf. También activa la nueva configuración al instante y no tendrás que recargar el proceso Postfix.)

Ahora Postfix buscará tu tabla virtual_domains para averiguar si "example.com" es un dominio de correo virtual. Veamos si esto funciona. Crea una nueva fila en la tabla virtual_domains con un dominio. Lo puedes hacer con phpmyadmin en la pestaña "Insert" o conectándote a la base de datos y ejecutando:

$> mysql -p mailserver

y ejecuta esta consulta:

mysql>
INSERT INTO virtual_domains (id, name) VALUES (1, 'example.com');
exit

Vuelve a la consola de superusuario y, ahora, puedes comprobar si el dominio 'example.com' está en los dominios de correo virtual:

$> postmap -q example.com mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Deberías obtener un '1' como resultado. Tu primera asignación funciona. Magnífico. Sigamos con la segunda.

Nota:

• Si lo que obtienes es un mensaje de error diciéndote postmap: warning: connect to mysql server 127.0.0.1: Access denied... lo que tienes es un problema con la cuenta de usuario "mailuser" que usas para conectarte a la base de datos. Revisa de nuevo los privilegios de MySQL.
• Si lo que obtienes es un mensaje de error como postmap: warning: connect to mysql server 127.0.0.1: Can't connect to MySQL server on '127.0.0.1', luego tu servidor MySQL o no se está ejecutando o no está escuchando en 127.0.0.1. Revisa tu configuración del servidor MySQL (/etc/mysql/my.cnf).

8.2. virtual_mailbox_maps

Ahora definirás virtual_mailbox_maps que asigna direcciones de correo a la localización de la bandeja de correo de los usuarios en tu disco duro. Si guardaste mensajes entrantes en el disco duro usando la característica de Postfix virtual derivery agent, luego tendría que ser consultado para encontrar la ruta de acceso al buzón. Pero, en nuestra configuración, el reparto real lo hace el LDA (local delivery agent) de Dovecot por lo que Postfix non tiene que preocuparse de la ruta de acceso. Postfix sólo necesita comprobar si cierta dirección de correo es válida. De una forma similar a la anterior, necesitas una consulta SQL que busque una dirección de correo y devuelva un "1".

Crea una entrada en la tabla virtual_users para un usuario de prueba john@example.com:

mysql>
INSERT INTO virtual_users (id, domain_id, email, password)
VALUES (1, 1, 'john@example.com', MD5('summersun'));

A continuación necesitarás crear un archivo ".cf" para indicarle a Postfix la consulta SQL para esta tabla. Además de la dirección de correo también es importante para conseguir después la contraseña del usuario. Como la ruta de acceso al buzón de correo del usuario es fija no es importante conseguir esta información de la base de datos. La estructura del directorio siempre será /var/vmail/$DOMAIN/$USER, por tanto, en el ejemplo de John sería /var/vmail/example.com/john.

Ahora las cosas son un poco más simples y, al fin, puedes crear un archivo ".cf" en /etc/postfix/mysql-virtual-mailbox-maps.cf tan simple como:

Indícale a Postfix que este archivo de asignaciones lo tiene que usar para virtual_mailbox_maps:

$> postconf -e virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf

Comprueba si Postfix está contento con esta asignación preguntándole dónde está el directorio del buzón del usuario john@example.com:

$> postmap -q john@example.com mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf

Deberías de obtener un "1", lo que significa que john@example.com es un usuario de correo virtual existente en tu servidor. Más tarde, en la parte de configuración de Dovecot, también tendrás que usar los campos email y password, pero Postfix no los necesita en estos momentos. Bien, sólo nos queda una asignación por definir.

8.3. virtual_alias_maps

Las asignaciones virtual_alias_maps se usan para el envío de mensajes de una dirección de correo a otra. Un ejemplo de cómo se ven las entradas en estas asignaciones:

(Ver "man 5 virtual" para una definición más formal.)

Atención: las cuentas catchall recojen correo basura en grandes cantidades. Pueden parecer cómodas porque reciben todos los mensajes de una persona sin la necesidad de crear sobrenombres, pero los generadores de correo no deseado generalmente intentan adivinar las direcciones de correo de dominios conocidos. Con un sobrenombre catchall recibirás correo no deseado por cada intento de adivinar una dirección de correo. Intenta evitarlas y define las direcciones de correo existentes, aunque te parezca mucho más loborioso.

Como ves, es posible nombrar múltiples destinos. En la base de datos esto se ha logrado haciendo diferentes filas. Por ejemplo, la segunda línea de la tabla anterior debería repartirse en los filas:

Añade este ejemplo a la base de datos:

mysql>
INSERT INTO virtual_aliases (id, domain_id, source, destination)
VALUES (1, 1, 'john@example.com', 'john@example.com'),
(2, 1, 'john@example.com', 'devnull@workaround.org');

Crea otro archivo ".cf" en /etc/postfix/mysql-virtual-alias-maps.cf:

Comprueba si el archivo de asignación funciona como se espera:

$> postmap -q john@example.com mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Deberías ver los dos destinos esperados:

john@example.com,devnull@workaround.org

8.4. La magia negra de las asignaciones "correo-a-correo"

Antes de definir la configuración <"virtual_alias_maps", hay un pequeño detalle del que tienes que preocuparte. Hay una clase especial de envíos: los sobrenombres "catchall". Los "catchall" recojen todos los mensajes de un dominio si no existe una cuenta de usuario específica. Un sobrenombre catchall se parece a "@example.com" y envía mensajes a todos los dominios a una cuenta. Hemos creado el usuario "john@example.com" y querríamos enviar todos los otros mensajes del dominio a "kerstin@gmail.com", por lo que tenemos que añadir un sobrenombre catchall como:

Ahora imagínate lo que pasa cuando Postfix recibe un mensaje para "john@example.com". Postfix primero comprobará si hay algún sobrenombre en la tabla virtual_alias_maps (por ahora no busca en la tabla virtual_mailbox_maps). Encuentra la entrada catchall indicada en la tabla anterior y ya que no hay más sobrenombres específicos, la cuenta catchall coincide y el mensaje se redirecciona a "kerstin@gmail.com". Esto probablemente no es lo que quieres, así que necesitas hacer la tabla como la siguiente:

Los sobrenobres más específicos tienen prioridad sobre los sobrenombres generales catchall. Postfix primero encontrará una entrada para "john@example.com" y verá que el mensaje tien que ser enviado a "john@example.com", la misma dirección de correo. Esta treta puede parecer algo raro pero se necesita si pretendes usar cuentas catchall. Por lo tanto, las asignaciones virtual_alias_maps deben cumplir ambas asignaciones: la de "ver sobrenombres" y la de "john a sí mismo". Crea un archivo ".cf" en /etc/postfix/mysql-email2email.cf para la última asignación:

Comprueba que consigues la dirección de correo de John cuando le pregunas a Postfix si hay sobrenombres para el:

$> postmap -q john@example.com mysql:/etc/postfix/mysql-email2email.cf

El resultado debería ser la misma dirección:

john@example.com

Ahora tienes que decirle a Postfix que estas dos asignaciones deberían ser buscadas, añadiendo esta línea a tu main.cf:

$> postconf -e virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf

Ten en cuenta que aquí la orden de las dos asignaciones es importante. Postfix buscará todas las entradas coincidentes en la primera asignación de sobrenombres virtuales y las usará como sobrenombres. Sólo si no encuentra resultados, Postfix consultará la segunda asignación email2email.

¡Lo has hecho! Todas las asignaciones están configuradas y, en general, la base de datos está lista para ser rellenada con dominios y usuarios. Asegúrate de que sólo "root" y el usuario "postfix" pueden leer los archivos ".cf", después de todo, tu contraseña de la base de datos está almacenada en esos lugares:

$>chgrp postfix /etc/postfix/mysql-*.cf
$>chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf

---

9. Haciendo que Postfix mande correos a Dovecot

En el apartado anterior nos aseguramos que Postfix conociese qué mensajes le está permitido recibir. ¿Qué hacemos ahora con los mensajes? Los tenemos que almacenar en el disco. Generalmente esto lo hace Postfix que trae incorporado un agente de reparto de mensajes (MDA: mail delivery agent) muy básico, llamado "virtual"; que puedes usar para guardar los mensajes en buzones virtuales de tu disco duro. Pero, como vamos a usar Dovecot (para el acceso POP3 e IMAP) también podemos usarlo más satisfactoriamente como agente de reparto local (también conocido como "Dovecot LDA"). Para hacer que Postfix use ese agente tendrás que añadir un servicio a tu /etc/postfix/master.cf:

(Nota: ¡la segunda línea tiene que tener un sangrado por espacios!)

Reinicia Postfix:

$>postfix reload

También haz que Postfix use ese servicio para las entregas virtuales añadiendo estas líneas a tu /etc/postfix/main.cf:

$>postconf -e virtual_transport=dovecot
$>postconf -e dovecot_destination_recipient_limit=1

Sin más, esto hará que Postfix envíe los mensajes entrantes a los usuarios virtuales del programa /usr/lib/dovecot/deliver. Ahora es el momento de configurar Dovecot, en el siguiente punto.

---

10. Configurando Dovecot

Configuremos Dovecot, que nos hará varias cosas:

• recoger mensajes de Postfix y guardarlos en el disco
• vigilar las cuotas (cuánto espacio puede ocupar un usuario en tu disco)
• ejecutar reglas de filtrado "sieve" basadas en usuario (se puede usar para guardar mensajes en diferentes carpetas)
• permitir a los usuarios entregar mensajes usando POP3 e IMAP

Antes de llevar a cabo la configuración real, por razones de seguridad, te sugiero que crees un nuevo usuario del sistema que sea el propietario de todos los buzones de correo virtuales. Los siguientes comandos de consola crearán el grupo del sistema "vmail" con GID (group ID) 5000 y un usuario del sistema con UID (user ID) 5000. (Asegúrate que esos UID y GID no se están usando, si no elige otros; el número puede ser cualquiera que no esté en uso entre 1000 y 65000):

$>groupadd -g 5000 vmail
$>useradd -g vmail -u 5000 vmail -d /var/vmail -m

Los archivos de configuración de Dovecot los puedes encontrar en /etc/dovecot. Empieza con el archivo principal...

10.1. /etc/dovecot/dovecot.conf

Busca la línea protocols y define los protocolos que quieres ofrecer. Por defecto aparecen:

protocols = imap imaps pop3 pop3s

Así que Dovecot inicia los servicios IMAP, POP3 y sus equivalentes que funcionan con una conexión cifrada SSL (secure socket layer).

Aunque esta sea una configuración menos segura, es posible que aún la necesites:

disable_plaintext_auth = no

Esto permitirá contraseñas de texto plano sobre una conexión no segura (sin SSL). Por defecto viene con "yes" por razones de seguridad. Cambiándolo a "no" obtendremos menor nivel de seguridad pero puede ayudar a los usuarios de "cierto" software de correo Microsoft que se estropea de muchas formas.

Una configuración más importante es:

mail_location = maildir:/var/vmail/%d/%n/Maildir

Lo que le dirá que los buzones de los usuarios siempre están en /var/vmail/DOMAIN/USER y que deberían estar en formato maildir.

También hay una sección "namespace private" en el archivo dovecot.conf que se comenta con caracteres "#". El espacio de nombres "privados" es el buzón de correo personal y sólo está disponible par cierto usuario. Puedes dejar esta sección deshabilitada y conseguir un directorio maildir de la forma /var/vmail/christoph.haas/email/Maildir/.spam.

Si seguiste los tutoriales ISPmail anteriores tus directorios deberían ser diferentes; seguramente tengas: /var/vmail/christoph.haas/email/Maildir/.INBOX.spam. Por tanto, necesitas declarar en la sección "namespace private" lo siguiente, habilitando la sección y asegurándote que estableces estas variables:

Lo siguiente es buscar la sección denominada "auth default". Primero define los mecanismos de autentificación permitidos:

mechanisms = plain login

Al navegar a través de la sección puedes ver numerosos estados a los que Dovecot puede acceder para conseguir los datos de los correos de los usuarios. Dentro de esta sección necesitas establecer:

Que le indica a Dovecot que las contraseñas se almacenan en una base de datos SQL.

Que le indica a Dovecot dónde están localizados los buzones de correo. Esto es parecido a la configuración de mail_location. El usuario se autentifica en la sección "passdb sql". Por tanto la sección "userdb static" define donde se localizan las carpetas de correo. Usando "userdb sql" no se necesita que todos los buzones de correo sigan un esquema de directorios fijo.

Deberás descomentar la sección llamada "passdb pam" que trata con los usuarios del sistema. De lo contrario Dovecot también buscará los usuarios del sistema cuando alguien obtenga mensajes que provoquen advertencias en tu archivo de registro.

Ahora busca la sección "socket listen". Aquí tienes que definir los archivos que se usan para interactuar con el mecanismo de autentificación de Dovecot. En la sección debe constar lo siguiente:

La sección "master" se necesita para darle al agente de entrega de Dobecot (el programa que guarda los nuevos mensajes en el buzón del usuario) acceso a la información de la base de datos de usuarios. La sección "client" crea un agujero dentro del directorio "chroot" de Postfix. "chroot" significa que esa parte de Postfix está enjaulada en /var/spool/postfix y sólo puede accederse a los archivos de ese directorio y sus subdirectorios. Es una buena medida de seguridad pues aunque Postfix tenga errores y fuese hackeado, el atacante no tendría acceso a, por ejemplo, /etc/passwd porque se encuentra fuera de /var/spool/postfix.

Y, finalmente, la sección "protocol lda" necesita unos arreglos. El LDA (local delivery agent) es más poderoso que el agente virtual de reparto de Postfix. Te permite cuotas y filtrado Sieve (que viene en el paquete dovecot-common). Deja la sección tal que:

Acuérdate de cambiar la dirección de correo anterior postmaster@example.com por una válida donde se pueda contactar con el administrador.

La opción "log_path" pero puede ayudarte a averiguar por qué un cierto filtro del servidor no está haciendo lo que tú esperabas. Como el dovecot-deliver.log puede crecer muy rápido, debes crear un archivo logrotate de configuración /etc/logrotate.d/dovecot-deliver para él:

Edita /etc/dovecot/dovecot-sql.conf y cambia estas opciones:

Reinicia Dovecot:

$>/etc/init.d/dovecot restart

Ahora mira el archivo de registro /var/log/mail.log. Deberías ver:

Antes de enviar tu primer mensaje de prueba tienes que corregir los permisos del sistema de archivos para el archivo /etc/dovecot/dovecot.conf, puesto que el usuario "vmail" puede acceder a la configuración de Dovecot. Esto se debe a que Postfix inicia el agente de reparto con los permisos de "vmail":

$>chgrp vmail /etc/dovecot/dovecot.conf
$>chmod g+r /etc/dovecot/dovecot.conf

---

11. Enviando un mensaje de prueba con Telnet

11.1. Emulando una sesión SMTP con Telnet

Ahora intentemos enviar un mensaje al usuario. Como el dominio "example.com" no existe realmente tu configuración DNS no apuntará al servidor correcto. Así que vamos a simular una sesión SMTP con el comando telnet. Instala el paquete telnet si aún no lo tienes:

$>aptitude install telnet

Luego establece una conexión TCP con el puerto SMTP:

$>telnet localhost smtp

El servidor debería responder:

Bien. Postfix está escuchando y quiere hablar contigo en SMTP. Primero tienes que ser cordial:

ehlo example.com

Postfix aprecia tu cordialidad y te ofrece las características de las que dispone:

¡Eh!, Postfix, tenemos un correo de steve@example.com:

mail from:<steve@example.com>

Parece como si Postfix se alegrase pues nos devuelve códigos que empiezan por un "2" y eso son buenas noticias:

250 2.1.0 OK

Dile a Postfix quién va a recibir el mensaje:

rcpt to:<john@example.com>

Postfix lo acepta:

250 2.1.5 OK

Cuando estamos preparados para enviar un mensaje real:

data

Postfix está de acuerdo y nos dice que ahora podemos enviar el mensaje real:

354 End data with <CR><LF>.<CR><LF>

Vale, pues escribimos un mensaje:

Postfix nos dice que ha recibido el mensaje y lo pone en cola bajo un ID:

250 2.0.0 Ok: queued as A9D64379C4

Gracias, Postfix, esto es todo:

quit

11.2. Comprobando los registros

Ahora échale un vistazo al archivo /var/log/mail.log. Deberías ver algo parecido a esto:

La entrega se ha efectuado. Postfix ha determinado correctamente que el dominio de destino es un dominio virtual y ha reenviado el mensaje al servicio "dovecot".

11.3. Comprobando el buzón de correo del usuario

Ahora el mensaje debería estar en algún lugar de /var/vmail/example.com/john. Vamos a verlo:

$>cd /var/vmail/example.com/john/Maildir
$>find
.
./cur
./new
./new/1179521979.V801I2bbf7M15352.mailtest
./tmp

Ahí es dónde se encuentra el mensaje. Intenta leerlo con el programa "mutt"

$>mutt -f .

Y te muestra el nuevo mensaje:

Presiona INTRO para leer el mensaje:

Por tanto el mensaje ha llegado a la cuenta de John. Perfecto. Pulsa "q" dos veces para salir de mutt.

---

12. Probando la obtención de mensajes con IMAP y POP3

John seguramente preferirá leer su mensaje en un programa de correo confortable. Lo que necesita es una forma de acceder a su buzón y dos protocolos entran en el terreno de juego.

• POP3 (Post Office Protocol) es un protocolo simple que te permite obtener los mensajes de un buzón. Generalmente se usa para recoger todos los mensajes, aunque también puedes dejarlos en el servidor pero es un poco más complicado y no puedes crear múltiples carpetas en el servidor para clasificar tus mensajes. Ahorra espacio en el servidor de correo porque mueve los mensajes al disco duro del ordenador del usuario. Sólo hay una bandeja de entrada. Esta variante es anticuada y no exactamente amigable.
• IMAP (Internet Messaging Aplication Protocol), este protocolo está prácticamente enfocado a dejar los mensajes en el servidor pero también los puedes recoger como con el POP3. La bandeja de entrada es donde se almacenan tus mensajes entrantes pero los usuarios también pueden crear otras carpetas y mover a ellas los mensajes. Pero los usuarios pueden mover los mensajes a diferentes directorios. IMAP es muy práctico cuando quieres acceder a tu correo desde diferentes ubicaciones sin perder mensajes porque los hayas descargado desde otro lugar. El inconveniente es que los usuarios perezosos dejan sus mensajes en el servidor ocupando el espacio del disco duro de tu servidor (a no ser que uses cuotas).

12.1. Probando POP3

Vamos a establecer una conexión POP3 y recuperar el mensaje de John:

$>telnet localhost pop3

El servidor responde:

Inicia sesión como John:

user john@example.com

El servidor debería aceptarlo:

+OK

Envía la contraseña:

pass summersun

El servidor debería reconocer la contraseña correcta:

+OK Logged in.

Pide una lista de los mensajes de John:

list

Dovecot te dirá que tienes un mensaje en el buzón:

Lee ese mensaje número 1:

retr 1

Dovecot te envía el mensaje:

Cierra la conexión con el servidor POP3:

quit

El servidor te desconectará:

Seguramente los usuarios no usarán TELNET para leer sus mensajes. Usarán un cliente de correo más cómodo. Esto sólo es para mostrarte cómo funciona básicamente POP y para asegurarnos que Dovecot se está comportando bien.

12.2. Probando IMAP

En vez de seguir el mismo procedimiento (IMAP es más complicado), puedes usar mutt para crear una conexión IMAP:

$>mutt -f imap://john@example.com@localhost

De forma alternativa, puedes crear una conexión IMAP pura con el servidor y teclear los comandos IMAP por ti mismo:

$>telnet localhost imap2

Deberías conseguir conectarte:

Los comandos IMAP siempre empiezan por un número y la respuesta a ese comando también empieza por el mismo número. Así que los siguientes comandos deben teclearse con el número al principio de cada línea. Inicia sesión con el nombre de usuario y la contraseña:

1 login john@example.com summersun

Dovecot te inicia la sesión:

1 OK Logged in.

Pregúntale a Dovecot por la lista de carpetas de correo de John:

2 list "" "*"

Y te muestra la lista:

Selecciona la bandeja de entrada:

3 select "INBOX"

Dovecot te da toda clase de información sobre esa carpeta:

Y ves que tienes un mensaje. Recógelo:

4 fetch 1 all

IMAP sólo te proporcionará información básica del mensaje:

Para realmente leer el mensaje necesitas recogerlo explícitamente:

5 fetch 1 body[]

Y aquí está:

Desconéctate del servidor:

6 logout

Y Dovecot te desconecta:

Parece que POP3 e IMAP funcionan. Ahora podrías usar cualquier programa de correo como Kmail, Evolution o Thunderbird/Icedove y configurar una cuenta POP3 o IMAP. La forma más rápida de probar las conexiones cifradas es, otra vez, usando mutt:

$>mutt -f imaps://john@example.com@localhost

Si usas otros programas de correo, ten en cuenta que el nombre de usuario será la dirección de correo "john@example.com" y la contraseña "summersun". Puedes probar estas clases de conexiones:

• POP3
• IMAP
• POP3 con TLS/SSL habilitado
• IMAP con TLS/SSL habilitado

Cuando uses TLS/SSL probablemente recibirás una advertencia de que el certificado del servidor no es de confianza. Dovecot crea sus propios certificados. Si no estás contento con el certificado crea el tuyo propio:

$>openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem \ -keyout /etc/ssl/private/dovecot.pem

El certificado y la llave se crearán mientras te hace unas cuantas cuestiones:

Seguramente deberías rellenarlo con tu propia información. La opción más importante es la Common Name que debería contener el nombre totalmente cualificado de tu servidor de correo. Ah, y este certificado será válido for 10 años (3650 días), ajusta este periodo como quieras.

No te olvides de establecer los permisos de la llave privada pues la gente no autorizada puede leerla:

$>chmod o= /etc/ssl/private/dovecot.pem

Y tendrás que reiniciar Dovecot para hacer que lea tu nuevo certificado:

$>/etc/init.d/dovecot restart

---

13. SMTP autentificado

Es importante que entiendas qué es una "retransmisión" (NdT: "relaying") y por qué las "retransmisiones abiertas" (NdT:"open relays") son un gran problema en internet. Generalmente, Postfix acepta un mensaje sólo si coincide con uno de estos criterios:

• la dirección del correo electrónico del destinatario pertenece a un usuario de tu servidor de correo

  

• el remitente está enviando un mensaje desde dentro de la red local (definoda por Postfix en las opciones "mynetworks")

  

• el remitente está autentificado (SMTP admite autentificación con un nombre de usuario y una contraseña)

Por razones de seguridad lo siguiente no debería estar permitido:

Si no, un creador de correo basura podría abusar de tu sistema para enviar millones de correos basura. Esto podría acabar con tu ancho de banda, molestar a mucha gente y hacer rápidamente que tu servidor pasase a formar parte de una lista negra. Esa transmisión que no está controlando los mensajes que acepta se denomina una "open relay". Afortunadamente Postfix te lo pone difícil para que lo configures como una "open relay". Es muy importante configurar correctamente el "smtpd_recipient_restrictions", como vamos a describir.

Normalmente puedes definir las redes en las que puedes transmitir con tu servidor de correo, configurando el parámetro "mynetworks" en tu main.cf. Generalmente lo estableces para tu red local pues los usuarios locales no necesitan autentificarse:

$>postconf -e mynetworks=192.168.50.0/24

Pero en caso de transmisión desde el exterior tu red es importante. Imagina que tienes un usuario que, en este momento, no está conectado a tu red local pero quiere enviar un mensaje a internet desde tu servidor. De acuerdo con las reglas anteriores, el usuario no podría hacerlo porque ni está en tu red local ni está enviando un mensaje a uno de tus dominios. Necesitas encontrar la forma de que tu servidor confíe en tu usuario externo. Los usuarios necesitarán enviar su nombre de usuario y su contraseña por tanto tu sabes si la transmisión debería estar permitida. Esto es de lo que trata el SMTP autentificado (NdT:authenticated SMTP), y todos los clientes de correo decentes tienen esta característica.

El SMTP autentificado con Postfix siempre ha sido una pena. Se realiza a través de la biblioteca SASL (Simple Authentification and Security Layer) que fue parte del servidor de correo de Cyrus. Fue casi imposible depurar y arrojaba mensajes de error incomprensibles y engañosos. Afortunadamente, con Postfix 2.3 podemos hacer que Postfix le pregunte al servidor de Dovecot para verificar el nombre de usuario y la contraseña. Y, si tienes bien configurado Dovecot, esto ahora es muy fácil. Postfix sólo necesita un poco de configuración extra:

$>postconf -e smtpd_sasl_type=dovecot
$>postconf -e smtpd_sasl_path=private/auth
$>postconf -e smtpd_sasl_auth_enable=yes
$>postconf -e smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination

El parámetro smtpd_sasl_auth_enable habilita la autentificación SMTP, smtpd_recipient_restrictions define las reglas con las que luego se comprueba la línea RCPT TO: que envía el usuario remoto durante el diálogo SMTP. En este caso, la transmisión se permite si:

• permit_mynetworks: el usuario está en la red local (mynetworks) o
• permit_sasl_authenticated: si el usuario está autentificado o
• reject_unauth_destination: el mensaje se destina a un usuario de un dominio que es local o virtual en este sistema (mydestination, virtual_alias_domains or virtual_mailbox_domains).

Hay unas cuantas restricciones (smtpd_client_restrictions, smtpd_helo_restrictions, smtpd_sender_restrictions) que se tienen que comprobar durante los diferentes estados del diálogo SMTP (conexión IP, comando HELO/EHLO, comando MAIL FROM), pero, por ahora, debes poner todas las restricciones en smtpd_recipient_restrictions.

Intenta autentificar durante una sesión SMTP:

$>telnet localhost smtp

El servidor te lo permitirá:

Di hola:

ehlo example.com

Postfix te mostrará una lista de características disponibles durante el diálogo SMTP:

Envía la cadena de autentificación con una contraseña cifrada en base 64:

auth plain am9obkBleGFtcGxlLmNvbQBqb2huQGV4YW1wbGUuY29tAHN1bW1lcnN1bg==

El servidor debería aceptar la autentificación:

235 2.0.0 Authentication successful

Desconéctate de Postfix:

quit

Hasta luego:

221 2.0.0 Bye

La autentificación funciona. Bien hecho.

Nota:
Si has establecido la contraseña de John a una distinta de "summersum" tienes que cifrarla en base 64. Puedes hacerlo con:

$>perl -MMIME::Base64 -e \
'print encode_base64("john\@example.com\0john\@example.com\0password")';

Ahora puedes probar a enviar un mensaje con la autentificación habilitada. Para hacer tu red local no confiable temporalmente:

$>postconf -e mynetworks=
$>postfix reload

Reinicia Postfix (/etc/init.d/postfix restart). Inicia tu programa de correo y mira tu mail.log (tail -f /var/log/mail.log) mientras envías un mensaje a un dominio de internet. Te recomiendo que envíes un mensaje de prueba a devnull@workaround.org que es una dirección que rechazará tu mensaje. Si todo funciona bien, tu archivo de registro mostrará:

En caso de error, tu archivo de registro podría parecerse a este:

No te olvides de ajustar "mynetworks" a las características de tu red:

$>postconf -e mynetworks=192.168.50.0/24
$>postfix reload

Tu programa de correo puede haberte advertido que el servidor de correo usa un certificado SSL no confiable. Cuando instalaste Postfix, Debian creó automáticamente para ti un certificado SSL autofirmado. El certificado por defecto es suficiente para hacer pruebas, pero, como hiciste con Dovecot, puedes crear un certificado SSL personalizado. El certificado por defecto se almacena en /etc/ssl/certs/ssl-cert-snakeoil.pem y la clave privada por defecto se almacena en /etc/ssl/private/ssl-cert-snakeoil.key. Esto creará una nueva clave y certificado:

$>openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/postfix.pem \
-keyout /etc/ssl/private/postfix.pem

Tienes que seguir el mismo procedimiento que realizamos para Dovecot. Acuérdate de ajustar el "Common Name" al nombre del host totalmente cualificado. También podrías usar el mismo certificado que has creado para Dovecot si el nombre del servidor es el mismo. En ese caso, usa los siguientes archivos /etc/ssl/certs/dovecot.pem y /etc/ssl/private/dovecot.pem.

No te olvides de ajustar los permisos de la clave privada pues gente no autorizada puede leerlos:

$>chmod o= /etc/ssl/private/postfix.pem

Tendrás que decirle a Postfix dónde encontrar tu certificado y la clave privada:

$>postconf -e smtpd_tls_cert_file=/etc/ssl/certs/postfix.pem
$>postconf -e smtpd_tls_key_file=/etc/ssl/private/postfix.pem

Cuando vuelvas a retransmitir a través de Postfix, puede que nunca más vuelvas a obtener la advertencia del certificado.

Por defecto, Postfix permitirá que los datos de inicio de sesión para la autentificación SMTP sean enviados en texto plano. Es mejor que sólo permitas transmisiones cifradas ajustando los siguientes parámetros:

$>postconf -e smtpd_use_tls=yes
$>postconf -e smtpd_tls_auth_only=yes

Lo que hacen estos parámetros es requerir cifrado por autentificación SASL para ser usados, de modo que si estás usando los métodos PLAIN o LOGIN SASL tus claves no se transmitirán sin protección. Inicialmente, cuando el cliente se conecta al servidor, el servidor no ofrece el comando AUTH. Si el cliente ha enviado el comando STARTTLS y logra negociar una conexión TLS, luego el cliente enviaría el comando EHLO y, ahora, el servidor ofrece el comando AUTH. Esto no necesitará ninguna clase de cifrado por parte de los clientes que no necesitan autentificarse (por ejemplo: servidores que se conectan para enviar un mensaje a los dominios de tu servidor, en contraposición a tus usuarios que intentan transmitir mensajes a través de tu servidor a dominios externos).

Si realmente quieres prohibir las conexiones SMTP sin cifrado (yo lo hago en los puertos 587 y 465), tendrías que usar "smtpd_tls_security_level = encrypt" (para STARTTLS, generalmente en el puerto 587) o "smtpd_tls_wrappermode = yes" (para cifrado SSL desde el principio de la conexión inicial, generalmente para el puerto 465). También podrías ajustar "smtpd_tls_security_level = may" pues ofrece ese cifrado TLS pero no es obligatorio (también denominado TLS oportunista).

Una vez hecho esto, probarías si tu servidor de correo está configurado de forma segura para prevenir intentos de transmisiones ilegales. Escribe en una consola de superususario:

$>telnet relay-test.mail-abuse.org

Esto contacta con un servicio muy conveniente en internet que intenta enviar mensajes a tavés de tu servidor de correo. Dale un momento mientras revisa tu servidor. Si al final ves algo como "System appeared to reject relay attempts", indica que todo está bien.

---

14. AMaViS: filtrando spam y viruses

Dos cuestiones molestas cuando usas el correo son los mensajes no deseados y los viruses. Afortunadamente puedes luchar contra ellos usando AMaViS (A Mail Virus Scanner). AMaViS es una interfaz entre Postfix, SpamAssassin (popular por sus capacidades bayesianas de filtrado de correo no deseado) y, opcionalmente, un buscador de virus. AMaViS contiene una parte de filtrado de correo basura pero no tiene incorporado un buscador de virus, y para eso has instalado ClamAV; que es un escáner de virus libre y de alta calidad que se actualiza con frecuencia.

La configuración de AMaViS se extiende por varios archivos en el directorio /etc/amavis/conf.d. Afortunadamente el escáner de virus "ClamAV" viene totalmente configurado por defecto, aunque lo tienes que habilitar en el archivo /etc/amavis/conf.d/15-content_filter_mode borrando el carácter "#" de las líneas que comienzan por @bypass_... y así habilitas los filtros de correo basura y virus. (Es un poco confuso que habilitando la opción "bypass", realmente habilites el escáner de virus y correo basura.)

También te aconsejo que le eches un cuidadoso vistazo a /etc/amavis/conf.d/20-debian_defaults, pero no cambies nada. Si quieres cambiar opciones hazlo en el archivo /etc/amavis/conf.d/50-user.

• $sa_spam_subject_tag: Si esta línea está sin comentar, de cada mensaje que AMaViS sospeche que es basura tendrá esta cadena insertada en el asunto. Si no quieres alterar el asunto tendrás que ponerla así: "$sa_spam_subject_tag=undef". Los usuarios pueden seguir enterándose de si AMaViS sospecha del mensaje comprobando la cabecera X-Spam-Status.
• $sa_tag_level_deflt: El correo basura con una puntuación mayor o igual a este nivel será marcado como correo basura. Generalmente el valor por defecto es razonable. Si lo bajas demasiado el correo basura se colará y si lo subes demasiado tendrás muchos más correos normales marcados como basura.
• $sa_kill_level_deflt: Debería tener el mismo valor que $sa_tag2_level_deflt.
• $final_spam_destiny: La opción por defecto "D_BOUNCE" aquí está clara. El enfoque usual es etiquetar el mensaje como basura. Pero si lo rechazas podrías afectar a una persona inocente porque los mensajes basura nunca contienen la dirección del remitente correcto. Deja que el usuario decida qué hacer con los mensajes no deseados. Por tanto, es muy recomendable que pongas en esta opción "D_PASS".
• $banned_filename_re: Comprueba con cuidado esta lista porque estos patrones le indican a AMaViS cuando rechazar un mensaje porque contienen datos que no quieres recibir en un mensaje.

Un archivo sensato de 50 usuarios sería:

Reinicia AMaViS si has hecho cambios en los archivos de configuración:

$>/etc/init.d/amavis restart

Asegúrate de que AMaViS está escuchando el puerto TCP 10024:

$>netstat -nap | grep 10024

Deberías obtener esta salida:

tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 12345/amavisd

Si obtienes ese resultado indica que AMaViS se está ejecutando y esperando por las sesiones SMTP entrantes. Si obtienes otra distinta, revisa el archivo /var/log/mail.log, porque puede que hayas cometido algún error en los archivos de configuración.

Unas cuantas palabras de cómo AMaViS se integra en Postfix. Si una persona te envía un mensaje desde internet, será recibido por Postfix (el proceso smtp) en el puerto TCP 25 (SMTP). Si Postfix acepta el mensaje será enviado a AMaViS por el puerto TCP 10024 (SMTP). Si AMaViS está contento con el contenido del mensaje se lo devolverá a Postfix por el puerto TCP 10025 (SMTP). Finalmente Postfix entrega el mensaje a su destinatario real. Revisa el capítulo <2. Visión general para las ilustraciones.

El hacer que Postfix le envíe el mensaje a AMaViS viene determinado por la opción content_filter. También viene determinado por la opción "receive_override_options" como explicaremos más tarde:

$>postconf -e content_filter=smtp-amavis:[127.0.0.1]:10024
$>postconf -e receive_override_options=no_address_mappings

Primero necesitamos definir el servicio smtp-amavis en /etc/postfix/master.cf. Y también necesitamos que Postfix escuche en el puerto TCP 10025 para los mensajes que son devueltos por AMaViS. Así que añade estas secciones a tu /etc/postfix/master.cf:

Primero reinicia Postfix:

$>postfix reload

Ahora hay dos opciones que necesitan una explicación. Primero el receive_override_options está ajustado a no_address_mappings. Esto deshabilita todas las asignaciones de direcciones. Por ejemplo, al principio no se consideran tus sobrenombres virtuales. Luego el mensaje se envía a smtp-amavis y al final retorna al servicio 127.0.0.1:10025 que ajusta un montón de opciones. Una de estas opciones es, otra vez, receive_override_options. Pero esta vez, la opción no_address_mappings no se tiene en cuenta. Finalmente así, en esta etapa, Postfix revisa tus sobrenombres virtuales. ¿Parece complicado? Bien, puede hacerse de esta forma o, por el contrario, tus sobrenombres serían evaluados dos veces, lo que ocasionaría enviar dos veces los mensajes. Las otras opciones se usan para no realizar comprobaciones que Postfix ya ha hecho durante la primera etapa.

Nota: receive_override_options=no_address_mappings hace que Postfix no considere los sobrenombres nunca más. Por tanto, si quieres deshabilitar AMaViS como filtro, ¡también tienes que deshabilitar este parámetro!

Otra pequeña advertencia, el usuario "clamav" tiene que ser un miembro del grupo del sistema "amavis" para que los dos servicios puedan intercambiar información:

$>adduser clamav amavis
$>/etc/init.d/clamav-daemon restart

Y otra cuestión a tener en cuenta: AMaViS intenta descubrir si un cierto mensaje está entrando (enviado desde internet a tus dominios) o saliendo (enviado desde tu sistema a internet) mirando la opción @acl_local_domains. Necesitas decirle a AMaViS dónde comprobar si un cierto dominio es uno de los tuyos. La razón es que tu normalmente no quieres revisar tus mensajes salientes. Imagina que un mensaje es accidentalmente considerado como basura y tu cliente obtiene avisos por sus mensajes. Éso no lo necesitas.

Así que edita el archivo /etc/amavis/conf.d/50-user y, antes del "1;", pon estas líneas:

@lookup_sql_dsn define cómo AMaViS puede acceder a tu base de datos, y $sql_select_policy ajusta la consulta SQL que se ejecuta cuando AMaViS quiere determinar si el dominio destinatario de ese mensaje es uno de tus dominios virtuales. %k es una lista de cadenas que AMaViS espera encontrar. La consulta real se parecerá a esta:

Esto puede parecer un poco extraño, pero al final, se busca la cadena "@example.com". Reinicia AMaViS:

$>/etc/init.d/amavis restart

Ahora intenta enviar un mensaje a john@example.com. Si examinas la cabecera del mensaje deberías encontrar líneas que fueron añadidas por AMaViS:

Tus usuarios podrán filtrar el correo basura dependiendo de esta información. La línea X-Spam-Status se pondrá a "Yes" si la puntuación de correo basura está por encima de la requerida ($sa_tag2_level_deflt). La línea X-Spam-Level contiene un número de "*" que menguan la puntuación de correo basura. Si tu programa de correo busca una cabecera X-Spam-Level: ***** entonces podrá capturar correo basura con, por lo menos, una puntuación de 5. Un ejemplo de la vida real:

Ahora todos los mensajes entrantes deben ser comprobados por si tienen virus o son basura. Inténtalo. SpanAssassin viene con un ejemplo de correo basura conteniendo el GTUBE (Generic Test for Uncolicited Bulk Email) que contiene una firma que se supone hace saltar a los filtros de correo basura, así como EICAR.COM para los escaners de virus. Envíale a John ese correo basura:

$>sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt

Entre otra información, tu /var/log/mail.log ahora contendrá una línea escrita por AMaViS:

amavis[13001]: (13001-02) Passed SPAM, <...> -> , ...

Así que el mensaje fue detectado como correo basura y pasó a John. Muy bien. Finalmente, corrige los permisos de los archivos de configuración de AMaViS pues los usuarios no autorizados pueden leer la contraseña de la base de datos:

$>chmod o= /etc/amavis/conf.d/50-user

---

15. Gestionando tus cuentas de correo

En estos momentos no tengo ninguna herramiento para ayudarte a administrar tus dominios, usuarios y sobrenombres. Se está trabajando en este tema y, probablemente, estará listo para finales de Julio del 2009. Seguramente será una de estas dos:

• ispwebadmin: Una interfaz web basada en Pylons.
• ispshelladmin: Una herramiente de consola basada en Python para gestión rápida de usuarios.

15.1. ISPwebAdmin (interfaz web)

He creado una interfaz web sencilla para administrar dominios, usuarios y alias; llamado ISPwebAdmin. La versión 1.0 se ha liberado el 15-09-09. Si encuentras algún fallo envíalo a la lista de correo.

Descarga e instrucciones de instalación. Los siguientes apartados son las instrucciones de instalación.

15.2. Autentificación de usuarios

Además de las tablas de SQL, necesitarás crear una tabla adicional para almacenar los nombres de usuario y las contraseñas de los administradores, a los que se les permite gestionar las cuentas de correo. Por lo que deberás ejecutar el siguiente código SQL para crear la tabla:

Ahora crea un administrador que pueda iniciar sesión a través de la interfaz web. El campo pwhash almacena un hash MD5 de la contraseña para evitar tener que almacenarla como texto plano.

Ejemplo SQL:

15.3. Instalación en el servidor de (correo) destino

Ejecuta como superusuario:

Inicia una sesión en vmail:

Acondiciona la aplicación:

Puedes usar esta solución rápida para ejecutar tu aplicaicón web. Pero para mantener el servicio en segundo plano e iniciarlo automáticamente con el arranque del sistema se recomienda el mecanismo daemontools.

15.4. Autoinicio usando runit

Ejecuta como superusuario:

Crea un archivo "/etc/sv/ispwebadmin/run" con el siguiente contenido:

Dale permisos de ejecución:

Crea un enlace simbólico para indicarle a runit que quieres usar este servicio:

El servicio debería inicarse automáticamente. Para comprobar que funciona:

Para detenerlo:

Para iniciarlo:

Si quieres obtener un archivo de registro para este servicio web puedes crear un archivo "/etc/sv/ispwebadmin/log/run" con el siguiente contenido:

Luego deberías obtener la salida en el archivo "/var/log/runit-ispwebadmin".

15.5. Configurando del archivo INI

El archivo ini que has creado con "paster make-config something.ini" contiene una configuración específica para la instalación de tu servidor de correo. Antes de ejecutar la interfaz web revisa las siguientes opciones:

[server:main] -> host

La dirección IP que escucha el servidor web en "0.0.0.0" se puede usar para todas las interfaces.

[server:main] -> port

El puerto TCP que escucha el servidor web.

[app:main] -> ispwebadmin.maildir_location

La ruta de tu directorio donde se almacenan las cuentas de correo de usuarios virtuales. Si has seguido este turorial, debería ser "/var/vmail".

[app:main] -> ispwebadmin.postmaster

La dirección de correo que se usa como dirección abuse@ y postmaster@ para los dominios creados recientemente. Necesitas tener esas cuentas para cada dominio.

Esto es opcional:

[app:main] -> sqlalchemy.url

La cadena de acceso que define cómo acceder a tu base de datos. Por ejemplo:

---

16. DNS

DNS es el acrónimo de "domain name system" y es la magia de internet que cambia nombres como "www.workaround.org" por direcciones IP como "212.12.58.129". Si quieres recibir mensajes para un cierto dominio, necesitas estar a cargo de su "zona" que contiene sus "registros" reales. El archivo de zona para "workaroun.org" contiene un registro A (dirección; address) por el cual puedes ver este sitio web. Entre otros registros contiene el MX (intercambiador de correo, mail exchanger) indicando qué servidore deberían usarse cuando alguien envía un mensaje a devnull@workaround.org. Esta es una pequeña muestra del archivo de zona:

El "IN" es la class en los registros. En internet siempre está "IN". La segundo columna designa los registros type:

• TXT = Registro de texto (puede contener cualquier texto hasta 255 caracteres), usado para filtros de correo no deseado.
• MX = Registro de intercambio de correo (designa el servidor de correo responsable de este dominio).
• A = Registro de dirección (entrada por defecto).

16.1. Cómo otros servidores de correo van a encontrar tu servidor de correo

Imagina que un servidor de correo en internet tiene un mensaje para tu dominio en su cola. Ahora necesita enontrar la dirección IP a la cual conectarse para enviar el correo a través del protocolo SMTP. Primero busca una DNS en el registro MX del dominio usado en la dirección de correo. Si encuentra varias direcciones probará con esos servidores, empezando con los servidores que tengan asignada la prioridad más alta (el número más pequeño). Si no es capaz de conectarse a ellos probará con los siguientes servidores, en orden. Si el servidor de correo no encuentra ninguna entrada MX probará buscando otra DNS para el registro A y enviar allí el mensaje.

Probemos con un ejemplo. Puedes enviar un mensaje a devnull@workaround.org. Aparentemente el dominio es la parte "workaround.org", ¿Hay algún registro MX? puedes probarlo usando la herramienta dig. ("host" o "nslookup" también funcionarán. Instala dig usando "aptitude install dnsutils" si no lo tienes.)

$>dig +short workaround.org mx
30 mx3.workaround.org.
40 mx4.workaround.org.
10 mx1.workaround.org.
20 mx2.workaround.org.

Vemos que existen cuatro servidores. El de prioridad más alta (10) es mx1.workaround.org. Encontremos sus direcciones IP preguntando en el registro A:

dig +short mx1.workaround.org
212.12.58.158

Ahora el servidor de correo intentará conectarse al otro servidor con esta dirección IP, en el puerto TCP 25 (SMTP) e intentará enviar el mensaje. Por casualidad (o no) parece que no te puedes conectar al servidor de correo. No hay más servidores de correo con prioridad 10 y lo intentará con el siguiente de mayor prioridad, mx2.workaround.org con prioridad 20. ¿Qué dirección IP tiene?

$>dig +short mx2.workaround.org
212.12.58.129

Este servidor funciona mejor, se establece la conexión SMTP y se entrega el mensaje.

Para que un dominio reciba un mensaje tienes que establecer, por lo menos, una entrada MX en su zona para apuntar a tu servidor de correo. Ten en cuenta que una entrada MX apunta a un monbre de host, nunca a una dirección IP. Si no puedes añadir entradas MX, prueba con el registro A que también te servirá.

---

17. Cuotas

Tu servidor de correo no tiene espacio infinito. Especialmente si usas IMAP, los usuarios aprecian la comodidad de dajar sus mensajes en el servidor, y hay usuarios IMAP que no se preocupan de los mensajes marcados para borrar pero que siguen ocupando espacio en el servidor. Dovecot puede almacenar el tamaño del buzón de un usuario y el número de mensajes que contenga con la carpeta virtual.

17.1. Habilitando las cuotas en Dovecot

Hay tres secciones en el archivo /etc/dovecot/dovecot.conf donde necesitas habilitar el añadido "quota" (sacado de la documentación de Dovecot):

17.2. Configurando cuotas globales

El caso más simple es un límite general de cuota para todos los usuarios. Le garantizas a cada usuario 1GB de espacio con no más de 1000 mensajes. Esta podría ser la configuración en tu archivo /etc/dovecot/dovecot.conf:

Ten en cuenta que el parámetro storage está en KB. También puedes omitir el parámetro messages si no quieres limitar el número de mensajes.

17.3. Configurando cuotas por usuario

Si tienes ciertos usuarios que tienen cuotas diferentes a la configuración de cuota global, puedes almacenar la configuración de esas cuotas en la tabla virtual_users. Usa esta sentencia SQL para añadir columnas a la tabla virtual_users:

mysql>
ALTER TABLE `virtual_users` ADD `quota_kb` INT NOT NULL,
ADD `quota_messages` INT NOT NULL ;

Y tendrás que habilitarla user_query en tu /etc/dovecot/dovecot-sql.conf. Este tutorial siempre te sugirió que usases el acceso "userdb static" en tu /etc/dovecot/dovecot.conf. Pero esto implica que todos los usuarios tienen las mismas características. Así que, en esta situación de cuotas por usuario necesitarás deshabilitar, otra vez, "userdb static" y habilitar "userdb sql" para obligar a que Dovecot haga una consulta extra y que extraiga los datos de los usuarios de la base de datos:

Y añadir esto es tu archivo /etc/dovecot/dovecot-sql.conf:

Esta consulta puede parecer un poco extraña pero hace lo mismo que la anterior y además, obtiene la información de quota_kb y quota_messages:

args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes

17.4. Qué pasa si un usuario no cumple las cuotas

Las cuotas en Dovecot no son demasiado amigables. Por ejemplo, el destinatario no recibe un aviso de un límite de cuota. Simplemente, el remitente recibe un mensaje con el asunto "Automatically rejected mail" y el mensaje "Your message to was automatically rejected: Quota exceeded".

---

18. Ofreciendo acceso desde la web

Este paso es opcional pero la mayoría de los proveedores de servicios de correo ofrecen a sus usuarios una forma de leer mensajes en un navegador. Afortunadamente eso es fácil. El paquete que necesitas es "squirrelmail", un sistema de acceso al correo a través de la web que puede usar cualquier servidor IMAP, uno como nuestro servidor IMAP de Dovecot. Para ajustarlo, primero necesitas añadir su configuración a tu configuración de Apache:

$>ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail.conf
$>apache2ctl restart

Necesitas cambiar por lo menos una opción de configuración, por lo que ejecuta la utilidad de configuración:

$>squirrelmail-configure

Selecciona la opción 3 (Folder Defaults) y establece a opción 1 (Default Folder Prefix) a "none". También podrías querer navegar a través de otras opciones del menú, por ejemplo poner el nombre de tu organización.

Escribe en tu navegador http://YOUR-MAIL-SERVER/squirrelmail y deberías ver la interfaz de acceso web. Entra con el nombre de usuario "john@example.com" y contraseña "summersun" y deberías de poder leer los mensajes de John. No podría ser más simple.

En caso de no estar satisfecho con la URL http://my.server/squirrelmail y prefieras usar otra en su lugar (estilo http://my.server) deberías leer la sección users will prefer a simple URL en el archivo /etc/squirrelmail/apache.conf.

---

19. Filtros por parte del servidor: Sieve

19.1. ¿Qué son los filtros basados en el servidor?

Ya tienes un servidor de correo totalmente funcional que incluso marca el correo basura. Pero, por ahora, le dejas la tarea de clasificación del correo basura al usuario. Lo podemos hacer mejor configurando filtros por parte del servidor. La siguiente tarea es mover todos los correos basura a la carpeta "Spam" del usuario. Vamos a usar la característica Sieve de Dovecot, que es un filtro de mensajes como procmail (que no funciona en buzones virtuales). Sieve tiene un lenguaje simple de scrips que nos permite enviar automáticamente todos los mensajes marcados por SpamAssassin a la carpeta "Spam". Al final del archivo /etc/dovecot/dovecot.conf encontrarás la sección "plugin". Allí puedes definir un "sieve_global_path" apuntando al archivo del filtro por defecto que actúa si el destinatario no tiene definido ningunha regla de filtrado por usuario.

De todas formas, el término "filtros por parte del servido" ("server-side filtering") significa que el servidor ejecuta las reglas automáticamente. En contraposición a los "filtros por parte del cliente" ("client-side filtering") que están configurados en el programa de correo del ordenador del usuario. Aparentemente, se prefieren los filtros por parte del servidor porque actúan aunque el ususario no esté conectado y, te da opciones interesantes como la autorrespuesta por vacaciones o filtrado basado en los campos de cabecezas.

19.2. El script de filtrado global de Sieve

Una receta básica que clasificará el correo basura. Crea el archivo /var/vmail/globalsieverc conteniendo las siguientes líneas:

Define este archivo como un archivo de filtro global dentro de la sección "plugin{}" de tu archivo /etc/dovecot/dovecot.conf:

sieve_global_path = /var/vmail/globalsieverc

Y reinicia Dovecot:

$>/etc/init.d/dovecot restart

Envíale a John otro correo basura:

$>sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt

Y luego mira el archivo /var/vmail/dovecot-deliver.log. La última línea debería ser:

Esto indica que el mensaje se ha guardado en la carpeta "Spam". Si vas a ver el correo, verás que el mensaje se muestra automáticamente en esa carpeta.

Ten en cuenta que las diferentes carpetas sólo funcionan cuando estás usando IMAP. POP3 no tiene la capacidad de funcionar con carpetas y sólo mostrará los mensajes en el buzón de entrada. El usuario se tendrá que suscribir a la carpeta "Spam" manualmente. Como alternativa, puedes añadir "Spam" al archivo /var/vmail/example.com/john/Maildir/subscriptions que contiene la lista de carpetas que John quiere ver en su programa de correo.

19.3. El servidor ManageSieve

Estuvimos hablando sobre los scripts de filtrado por parte del usuario. ¿Cómo un usuario puede gestionar algo como un script? Esto se hace con una interfaz de bajo nivel llamada managesieve. Antes, "managesieve" necesitaba software adicional como "pysieved". El Dovecot de Lenny ya lo soporta por defecto.

Para habilitarlo tienes que añadir "managesieve" a la línea "protocols" de tu archivo /etc/dovecot/dovecot.conf. En su sección "protocol managesieve" ya debería tener la línea "sieve=~/.dovecot.sieve". Esto significa que un script de filtrado sieve de un usuario se podrá almacenar en su "home directory" virtual. El script sieve de John podría acabar en /var/mail/example.com/john/.dovecot.sieve.

19.4. El cliente ManageSieve

Probablemente, tus usuarios no quieren apender el lenguaje de filtrado de sieve. Necesitan una forma cómoda de administrar sus reglas de filtrado. Esto puede conseguirse añadiendo "avelsieve" al software de correo web "squirrelmail". Asumo que has configurado squirrelmail como se describe en este capítulo. Instala el plugin "avelsieve":

$>aptitude install avelsieve

Afortunadamente eso es todo lo que necesitas hacer. Si entras vía squirrelmail verás encima de todo un nuevo enlace llamado "Filters". Haz click en él y podrás añadir reglas de cualquier tipo.

Ten en cuenta que en estos momentos avelsieve tiene un fallo en Debian Lenny (Debian #516198, Avelsieve #241) (NdT: parece que ya está corregido en la versión de avelsieve 1.9.7-8) que hace que desaparezcan las reglas cuando usas Dovecot y TLS. He preparado un parche que puedes instalar con "dpkg -i" si te encuentras con el mismo problema.

---

20. Características adicionales

Ahora tienes un servidor de correo totalmente funcional, pero hay algunas características más que puede que quieras usar. Coge la que necesites.

20.1. Búsqueda y filtrado con Fetchmail y Sieve

Mathias Geat escribió un artículo sobre la integración entre fetchmail y sieve que se ajusta a nuestra configuración.

20.2. Eliminando los mensajes borrados más antiguos

Con IMAP puedes marcar los mensajes como borrados y algunos clientes no los vuelven a mostrar. Pero los mensajes siguen ahí ocupando espacio. Generalmente hay una opción para purgar todos los mensajes marcados pero a muchos usuarios no les importa. Así que Michael Weisgerber sugiere ejecutar este comando a través de crontab con frecuencia para remover tales mensajes:

$>find /var/vmail/ -name '*,ST' -ctime +7 | xargs rm -f

Dovecot renombra todos los mensajes borrados y les añade un ",ST" al final del nombre del archivo. Ajusta este parámetro a tu gusto en -ctime. En el ejemplo se purgan los mensajes borrados de más de 7 días de antigüedad.

---

21. Resolución de problemas

Si estás teniendo problemas enviando o recibiendo mensajes puedes probar a seguir estos pasos:

• Revisa tu /var/log/mail.log, el 93,7% :) de todos los problemas tienen un mensaje de error más o menos claro que puedes encontrar en ese registro.
• Ejecuta postfix check. Si no obtienes ninguna salida es que todo va bien.
• Pregunta en el canal IRC #postfix de irc.freenode.net. Generalmente estoy con el sobrenombre de Signum pero pregunta y espera a que la gente te ayude. Especialmente léete las sugerencias en el tema del canal y mis sugerencias en cómo conseguir ayuda útil en IRC.
• Pregunta en la lista de correo workaround chitchat (en ingleś por favor).
• Este tutorial está hecho para Debian 5.0 "Lenny". Si pruebas esta configuración en otra distribución no puedo ayudarte.

.

• Lista los contenidos de la cola del correo (añade "-v" para tener más detalles, añade múltiples "-v" para aumentar los detalles):

  mailq o postqueue -p

• Calendario de entrega inmediata de todos los mensajes que están en cola:

  mailq -q

• Amavis:

  /etc/init.d/amavisd-new stop
  /etc/init.d/amavisd-new debug

Enviarle un mensaje directamente al autor pidiéndole ayuda es la peor elección. Enviarle un mensaje directamente al autor con sugerencias o con realimentación es una buena elección. :)

---

22. Contribuyendo a este documento

Se han probado, investigado y documentado muchas partes de este tutorial con la ayuda de los lectores. Si quieres estás invitado a contribuir. Usa el enlace de "Add new comment" que se encuentra al final de cada página. Si es posible, se añadirán tus contribuciones en el lugar apropiado de este tutorial. (NdT: Se refiere a su sitio original.)

---

23. Agradecimientos

Se está manteniendo este tutorial desde los tiempos de Debian Woody y mucha gente lo ha traducido, ha contribuido con sugerencias y ha ayudado a encontrar errores. Gracias:

• Alexander Stielau
• Axel Zöllich
• Cameron Jones de vpslink por patrocinar un servidor virtual de root para probar estas configuraciones
• Christian Garling
• Christian Kurz
• Christof Gruber
• Claus C. Pförtner
• Colleen Hatfield
• Daniel Hackenberg
• Daniel Wladow
• Devdas "f3ew" Bhagat
• Eicke Kemm
• Florian Fritsch
• Jasper Slits
• Jesper Krogh
• Jon Cox
• Kay-Michael Voit
• Lucas Baltes
• Malte Simon
• Mark Phillips
• Mario Duve
• Matthias Quade
• Michael Dürgner
• Michael Weisgerber
• Mikael Tokarev
• Oliver Ladner
• Patrick Blitz
• Patrick Jäger
• Pete Boyd
• Ricardo Arguello
• Simon Kammerer
• Thomas "Balu" Walter
• Tim Weippert
• Tobias Scheeper
• ...y todos aquellos que enviaron sus sugerencias a la lista de correo workaround-chitchat

Puedes encontrar más contribuciones que aún no he añadido en la página wiki de contribuciones. También estoy agradecido a todos los lectores que enviaron realimentación al tutorial, tanto técnica como emocional. Quizás estás interesado en leer lo que otros piensan. Si quieres ayudar al autor a mejorar el tutorial puedes considerar hacer una donación. :)