Fuente : http://indesweb.graficaselabra.es/index.php/infor/proyecto-asi3/instalacion-de-un-servidor-smtp-pop3-en-linux-postfix-dovecot
vamos a explicar paso a paso cómo instalar y configurar el servidor de correo con Postfix/Dovecot para que funcione sobre una distribución CentOS de Linux.
Acerca de Postfix.
Postfix, originalmente conocido por los nombres VMailer e IBM Secure Mailer, es un popular agente de transporte de correo (MTA o Mail Transport Agent), creado con la principal intención de ser una alternativa más rápida, fácil de administrar y segura que Sendmail. Fue originalmente escrito por Wietse Venema durante su estancia en el Thomas J. Watson Research Center de IBM.
URL: http://www.postfix.org/.
Acerca de Dovecot.
Dovecot es un servidor de POP3 e IMAP de fuente abierta que funciona en Linux y sistemas basados sobre Unix™ y diseñado con la seguridad como principal objetivo. Dovecot puede utilizar tanto el formato mbox como maildir y es compatible con las implementaciones de los servidores UW-IMAP y Courier IMAP.
La mayor parte de las personas estamos familiarizados con el correo electrónico. Pero, ¿qué ocurre exactamente cuando se envía un email desde un cliente de correo o MUA? El proceso no es complicado si tenemos claros unos cuantos conceptos.
Introducción al servidor de correo
En primer lugar, el cliente de correo o MUA -Mail User Agent- (como puede ser el Thunderbird/MS Outlook) de la persona que envía el correo envía el email al servidor SMTP o MTA -Mail Transport Agent- correspondiente al usuario logueado con sus credenciales STMP en el MUA. Una vez el email está en este servidor SMTP “saliente”, el servidor comprueba a qué otro servidor SMTP tiene que enviar el correo consultando los registros MX mediante una consulta DNS. En este momento, este primer servidor SMTP envía el email al segundo servidor SMTP donde se encuentra el buzón de correo de la dirección de correo electrónico a la que iba dirigido el email. Finalmente, el cliente de correo o MUA de la persona a la que va dirigido el correo recupera el email del buzón de este segundo servidor SMTP.
Resumiendo:
El cliente de correo (MUA) “A” envía el email al servidor SMTP “1″.
El servidor SMTP (MTA) “1″ comprueba los registros MX mediante una consulta DNS y envía el email al servidor SMTP (MTA) “2″, donde se encuentra el buzón de correo de la persona a la que va dirigida el correo electrónico.
El servidor SMTP (MTA) “2″ recibe el email y lo almacena en el buzón de correo electrónico del usuario correspondiente a la persona a la que va dirigido el correo electrónico.
El cliente de correo (MUA) “B” recupera el email del buzón desde el servidor SMTP “2″ mediante IMAP o POP, permitiendo así la lectura del correo electrónico.
Una vez introducidos los conceptos básicos del funcionamiento del correo electrónico, vamos a disponernos a instalar y configurar un servidor de correo nosotros mismos. Allá vamos.
Paso 1: Comprobar si los paquetes están ya instalados
El primer paso que vamos a hacer es comprobar si los paquetes correspondientes están o no instalados en el sistema. Para esto instroducimos los siguientes comandos:
$ sudo rpm -q postfix dovecot
En caso de que los paquetes no estén instalados en el sistema se nos devolverá la siguiente salida:
package postfix is not installed
package dovecot is not installed
Bien, con esto hemos comprobado que los paquetes correspondientes a Postfix y Dovecot no están instalados en nuestro sistema Linux.
Paso 2: Instalación de los paquetes Postfix y Dovecot
Una vez hecha la comprobación vamos a proceder a instalar los paquetes utilizando el gestor de paquetes yum de CentOS. Para esto introducimos los siguientes comandos:
$ sudo yum install postfix dovecot
Y pulsamos “y” cuando nos pregunte si queremos descargar los paquetes.
El comando anterior nos instalará también las depencias en caso de que no las tengamos ya instaladas. Las dependencias de que se instalarán serán mysql y perl-DBI.
Paso 3: Seleccionar Postfix como MTA por defecto
Ahora necesitamos decirle a CentOS que Postfix es el MTA por defecto, esto lo haremos empleando el comando system-switch-mail (conmutador del agente de transporte del correo). Introducimos el comando:
$ sudo system-switch-mail-nox
Si CentOS no ha encontrado el comando porque no está instalado el paquete, tendremos que instalarlo. Para esto, tendríamos que introducir los comandos:
$ sudo yum install system-switch-mail
# ahora sí, ejecutaremos system-switch-mail exitosamente
$ sudo system-switch-mail-nox
En la pantalla que nos saldrá, seleccionamos Postfix en lugar de Sendmail que es el MTA por defecto en CentOS. De esta forma, nuestro sistema CentOS empleará CentOS como MTA a partir de ahora.
Paso 4: Iniciar el servicio Postfix
Iniciamos el servicio con el siguiente comando:
$ sudo service postfix restart
Con esto ya tenemos Postfix instalado e iniciado en nuestro servidor.
Paso 5: Logs de Postfix
Podremos ver los logs que genera el servicio Postfix en el siguiente fichero:
/var/log/maillog
Podemos ver la actividad de los logs en tiempo real con los comandos tail y tail -f.
$ sudo tail -f /var/log/maillog
Para saber que Postfix se ha iniciado correctamente deben de aparecer las siguientes líneas en el log de postfix:
Jan 9 12:12:44 localhost postfix/postfix-script: starting the Postfix mail system
Jan 9 12:12:44 localhost postfix/master[9379]: daemon started -- version 2.3.3, configuration /etc/postfix
Paso 6: Configuración de Postfix
Los dos archivos principales de configuración de Postfix son los siguientes:
/etc/postfix/main.cf
/etc/postfix/master.cf
El fichero main.cf contiene un subconjunto de la mayoría de las opciones de configuración que puede utilizarse para personalizar Postfix. Puedes añadir aquí más parámetros de configuración adicionales si lo necesitas.
Por su parte, el fichero master.cf controla cómo se conectan los clientes al servidor. La mayoría de veces no necesitarás cambiar mucho este fichero. En este fichero podemos ver una lista de los demonios, servicios y procesos que pueden configurarse en Postfix.
El fichero main.cf: configuraciones generales de Postfix
Como hemos comentado, el fichero mail.cf es donde se almacenan los valores de configuración de Postfix. Puedes ver los valores actuales de configuración de su Postfix (fichero main.cf) mediante el siguiente comando:
$ sudo postconf
Para ver los valores que han cambiado en relación a los valores de configuración por defecto de la instalación de Postfix, emplea el siguiente comando:
$ sudo postconf -n
Lo primero es decirle a Postfix qué dominios debe de utilizar para administrar su correo. Para ello modificamos la opción mydestination del archivo main.cf. Para hacer el cambio podemos usar el siguiente comando:
$ sudo nano /etc/postfix/main.cf
Dejamos la variable mydestination como se muestra:
mydestination = mail.mi-dominio.com, localhost.localdomain, localhost, mi-dominio.com
Ahora Postfix sabe que si el servidor de correo recibe un email destinado a una dirección de email perteneciente a uno de estos dominios (el campo para es una cuenta de correo de uno de estos dominios), el servidor de correo debe de aceptar el email y procesarlo. Por ejemplo, si recibe un correo que se debe enviar a la dirección de correo Esta dirección de correo electrónico está protegida contra spambots. Usted necesita tener Javascript activado para poder verla. (el campo para del email de Esta dirección de correo electrónico está protegida contra spambots. Usted necesita tener Javascript activado para poder verla. ).
Si queremos que Postfix también acepte correos dirigidos a otros dominios, deberemos de agregarlo al mydestination. Es importante que se encuentre localhost en mydestination para que Postfix acepte y procese el correo local utilizado por procesos del servidor.
A continuacion necesitamos añadir las redes a la que está conectado el servidor en la variable de configuración mynetworks. En este punto estableceremos las interfaces de red del servidor desde las cuales se aceptarán y procesarán correos:
mynetworks = 127.0.0.0/8, 192.168.1.0/24
Después de esto, reniciamos postfix con el siguiente comando:
$ sudo service postfix reload
y comprobamos que se haya reiniciado correctamente leyendo la salida del comando.
Paso 7: Abrir el puerto 25 en el firewall
Lo que tenemos que hacer ahora es abrir el firewall para que acepte conexiones en el puerto 25. Este el puerto que emplea SMTP para enviar correo, por lo que tenemos que habilitarlo para que el servidor de correo sea útil y pueda enviar y recibir correo. Para ello, usamos el siguiente comando:
$ sudo iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
Ahora para comprobar que Postfix está funcionando, podemos enviarnos un mail de prueba desde línea de comandos:
$ echo "cuerpo del mensaje" > body.txt
$ mail -s "Asunto de prueba" Esta dirección de correo electrónico está protegida contra spambots. Usted necesita tener Javascript activado para poder verla. < body.txt
Si tratamos de enviar un mail con un usuario que no esté creado en el sistema, Postfix lo rechazará con un mensaje 550 como el siguiente:
Recipient address rejected: User unknown in local recipient table
El comando mail conectará con localhost por el puerto 25 y enviará el email. Podemos tratar de enviar otro email cambiando el asunto y el cuerpo del mensaje usando el mismo comando.
Paso 8: Cambiar el formato de buzón de Mailbox a Maildir
Una vez enviado el email de prueba del paso anterior, vamos a analizar el email en:
/var/spool/mail
y veremos que en esta carpeta existe un fichero por cada usuario (dirección de correo electrónico) que emplea el servidor de correo.
Si miramos el contenido del fichero al que hemos enviado un email veremos que aparecen todos los mails del usuario en el mismo fichero. Esto es así porque se está empleando el formato de buzón Mailbox(también llamado Mbox). Este formato de buzón es poco práctico y puede corromperse con facilidad si se dan una serie de situaciones.
Para un mejor desempeño, cambiaremos al formato de buzón a Maildir, que utiliza un fichero diferente por cada email. Para ello editamos otra vez el fichero main.cf. Modificamos las siguientes líneas de esta manera:
home_mailbox=Maildir/
mailbox_command =
y reiniciamos postfix:
$ sudo service postfix restart
Después de cambiar el formato de buzón, si volvemos a ejecutar el comando mail como anteriormente, deberiamos ver que se ha creado el siguiente directorio:
/home/usuario/Maildir
Dentro de este directorio vemos los directorios new, cur y tmp. En el directorio new se alamcenan los emails no leidos, y en el directorio cur se almacenan los emails una vez se han leido. En el momento en que un email se lee, éste se mueve de la carpeta new a la carpeta cur en el buzón del usuario.
Paso 9: Autenticación
Ahora vamos a configurar la autenticación de nuestro servidor de correo. En este punto del tutorial, los usuarios no podrán enviar correos desde redes que no estén configuradas en mynetworks del archivo main.cf. Para que los usuarios puedan enviar correos desde cualquier red manteniendo la seguridad del sistema, es necesario incluir un sistema de autenticación, que es lo que estamos viendo en este apartado.
Tendremos que comprobar que Postfix soporta autenticación SASL con Dovecot. Para ello ejecutamos el siguiente comando:
$ sudo postconf -a
La salida del comando deberá de ser la siguiente:
cyrus
dovecot
Este comando devuelve todos los plugins de autenticación SASL soportados por Postfix. Deberemos de buscar el plugin dovecot en la salida del comando anterior. En este caso si que aparece, ya que en el paso 2 del tutorial instalamos el paquete correspondiente.
Ahora tenemos que editar el fichero de configuración de Dovecot:
$ sudo nano /etc/dovecot.conf
Tenemos que configurar las siguientes opciones tal como se muestran aquí:
auth default{
mechanisms=plain login
passdb pam{
}
userdb passwd{
}
socket listen{
client{
path=/var/spool/postfix/private/auth
mode=0660
user=postfix
group=postfix
}
}
}
Después reiniciamos el servicio Dovecot:
$ sudo service dovecot restart
Para confirmar que Dovecot se está ejecutando, hay que emplear los siguientes comandos. Este es el primero:
$ sudo tail -f /var/log/maillog
# y verificar que en la salida del comando aparecen las líneas:
Jan 9 18:12:24 localhost dovecot: Dovecot v1.0.7 starting up
Jan 9 18:12:24 localhost dovecot: Generating Diffie-Hellman parameters for the first time. This may take a while..
y este es el segundo:
$ sudo ps -A | grep doveco
# verificamos que en la salida del comando aparecen las siguientes líneas
11698 ? 00:00:00 dovecot
11700 ? 00:00:00 dovecot-auth
Ahora tendremos que volver a configurar el fichero main.cf de Postfix para que utilice el servicio SASL de Dovecot. Editamos el fichero main.cf para añadir las siguientes líneas:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = no
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
Reiniciamos Postfix para que los cambios tengan efecto:
$ sudo service postfix restart
Hasta ahora, nuestro servidor solamente permitía enviar correo a direcciones que no estuvieran dentro de mydestination si la IP desde donde se mandaba el mail venía de una red situada en mynetworks, una vez implementada la autenticación SASL, cualquier usuario que se haya autenticado podrá hacer relay.
Con estos pasos tendríamos configurada la autenticación en nuestro servidor de correo.
Paso 10: Creación de buzones para direcciones de correo electrónico
Como configuraciones previas para la correcta creación de los buzones de correo, deberemos ejecutar los siguientes comandos:
sudo rpm -Uvh ftp://ftp.silfreed.net/repo/rhel/5/i386/silfreednet/RPMS/maildrop-2.0.4-1.el5.i386.rpm
$ sudo maildirmake /etc/skel/Maildir
$ sudo maildirmake -f Sent /etc/skel/Maildir
$ sudo maildirmake -f Trash /etc/skel/Maildir
$ sudo maildirmake -f Drafts /etc/skel/Maildir
$ sudo maildirmake -f Spam /etc/skel/Maildir
El primer comando instala maildrop, que es un MDA que se encarga de almacenar los emails en su correspondiente buzón. De momento no utilizaremos maildrop como MDA, en futuros artículos veremos como implementar maildrop y como realizar filtros para ordenar nuestro email por carpetas y aplicaciones algo más avanzadas, como filtros antispam, etc…
Los siguientes comandos crean una estructura de buzón de correo que servirán como plantilla para los bozones que se creen a partir de este momento. Según los comandos que hemos ejecutado, los buzones que se creen tendrán las carpetas Sent, Trash, Drafts y Spam.
En el sistema que estamos implantando, los buzones de los usuarios del servidor de correo estarán en la carpeta /home de cada usuario. Tal como hemos comentado en puntos anteriores del tutorial, la carpeta home de cada usuario del servidor de correo estará compuesta de una carpeta Maildir (el buzón de correo) con las siguientes subcarpetas:
carpeta new: aquí se almacenan los emails que no han sido leídos.
carpeta cur: aquí se almacenan los emails que ya han sido leídos. Cuando un email se lee se mueve de la carpeta new a la carpeta cur.
carpeta tmp: esta carpeta la utiliza el servidor de correo internamente.
Recuerda que para crear usuarios del sistema en CentOS (Linux) hay que ejecutar el siguiente comando:
$ sudo useradd nombre-de-usuario
En el momento que creemos el usuario se creará una carpeta en /home con el nombre de usuario, y el buzón con la estructura que acabamos de definir. El propietario de cada Maildir debe de ser sólo el usuario al que pertenece, y los permisos deben de ser 700. Recuerda que puedes usar los comandos chown y chmod para establecer el propietario y los permisos de los archivos y carpetas.
Bueno, pues con esto está todo listo para poder usar nuestro servidor de correo. En futuras entregas veremos aspectos más avanzados sobre la base de este mismo servidor de correo que hemos instalado y configurado mediante los pasos de este tutorial.
Para instalar el servidor de correo primero deberemos instalar el DNS bind9 en Ubuntu. Para ello os mostramos un pequeño resumen de cómo hacerlo.
La aplicación que hace de servidor DNS en Linux se denomina bind9. Para instalarla, podemos hacerlo con apt-get desde una consola de root:
// Instalación del servidor DNS
# apt-get install bind9
De esta forma instalaríamos los programas necesarios para disponer de un servidor DNS. Tan solo será necesario configurarlo y ponerlo en marcha.
Por defecto, al instalar el paquete bind está preconfigurado como servidor caché DNS. Tan solo será necesario editar el archivo /etc/bind/named.conf.options y en la sección forwarders añadir las IPs de dos servidores DNS donde redirigir las peticiones DNS:
// Configuración como caché DNS // Añadir IPs de los DNS de nuestro proveedor en /etc/bind/named.conf.options
forwarders {
80.58.0.33; 80.58.32.97;
};
CONFIGURACIÓN DNS MAESTRO
Por razones de accesibilidad y organizativas, deseamos asignar un nombre a todos los equipos de nuestra red, para lo que instalaremos un servidor DNS privado con un dominio ficticio, por ejemplo 'solosillueve.com'. Todos los PCs de nuestra red pertenecerán a dicho dominio ficticio que funcionará solo en nuestra red interna, no en Internet. En tal caso el nombre completo de los PCs terminará con 'solosillueve.com', por ejemplo: aula5pc2.solosillueve.com. Lo ideal en una situación así es disponer de un servidor DNS que sea maestro de nuestro dominio, es decir, maestro del dominio interno 'solosillueve.com'.
Nuestro servidor DNS maestro para nuestro dominio ficticio interno 'solosillueve.com' será capaz de resolver peticiones internas de nombres de este dominio, tanto de forma directa como de forma inversa, es decir, si recibe una consulta acerca de quién es aula5pc7.solosillueve.com deberá devolver su IP, pongamos por ejemplo 192.168.0.107. Si la consulta es una consulta DNS inversa acerca de quién es 192.168.0.107, deberá responder aula5pc7.solosillueve.com. Por ello deberemos añadir en el archivo /etc/bind/named.conf.local la especificación de maestro para el dominio y para la resolución inversa, por ejemplo:
// Añadir en /etc/bind/named.conf.local
// Archivo para búsquedas directas
zone "saija.com" {
type master;
file "/etc/bind/saija.db";
};
// Archivo para búsquedas inversas
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/192.rev";
};
Evidentemente será necesario crear los archivos solosillueve.db y 192.rev que especificarán la asociación entre nombres y direcciones IP de nuestra red en un sentido y en otro respectivamente.
Archivo de zona de búsqueda directa
Supongamos que en nuestra red local tenemos un aula llamada aula5 con 12 PCs con IPs que van desde la 192.168.0.101 hasta 112 y cuyos nombres van desde aula5pc1 hasta aula5pc10, luego un servidor web (pc11) y un servidor de correo electrónico que además es servidor DNS (pc12). El archivo de configuración DNS de nuestro dominio podría ser así:
// Archivo /etc/bind/saija.db
; ; BIND data file for saija.com ; @ IN SOA saija.com. root. saija.com. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Default TTL IN NS dns. saija.com. IN MX 10 mail. saija.com. aula5pc9 IN A 192.168.0.109 aula5pc10 IN A 192.168.0.110 www IN A 192.168.0.111 dns IN A 192.168.0.112 mail IN A 192.168.0.112
Las primeras líneas son unos parámetros relacionados con la actualización del DNS (número de serie y periodos de actuación). Las dos siguientes líneas indican quién es el servidor primario (NS = Name Server) y quien procesa el correo electrónico del dominio (MX = Mail eXchange). Las siguentes líneas especifican las IPs de los distintos PCs componentes del dominio (A = Address).
Si olvidamos algún punto y coma, dará errores y no funcionará correctamente. Para revisar los archivos disponemos de los comandos named-checkconf y named-checkzone que analizan que esté correcta la sintaxis de los mismos.
Si olvidamos algún punto y coma, dará errores y no funcionará correctamente. Para revisar los archivos disponemos de los comandos named-checkconf y named-checkzone que analizan que esté correcta la sintaxis de los mismos.
Archivo de zona de búsqueda inversa
Para poder realizar consultas inversas (de IP a nombre) será necesario crear el siguiente archivo:
// Archivo /etc/bind/192.rev
; ; BIND reverse data file for 192.168.0.0 ; @ IN SOA saija.com. root. saija.com. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Default TTL IN NS dns. saija.com. 109 IN PTR aula5pc9.saija.com. 110 IN PTR aula5pc10.saija.com. 111 IN PTR www.saija.com. 112 IN PTR dns.saija.com. 112 IN PTR mail.saija.com.
Una vez configurado nuestro servidor DNS, debemos indicar a nuestro servidor Linux que el servidor DNS es él mismo, lo cual se especifica en el archivo /etc/resolv.conf.
// Indicamos que nosotros mismos somos servidores DNS // y por defecto buscamos en nuestro dominio // Editar /etc/resolv.conf del servidor DNS
nameserver 127.0.0.1 search saija.com
En el resto de PCs de la red, indicaremos que el servidor DNS es 192.168.0.112
// En el resto de PCs de la red indicamos quién es el DNS // Editar /etc/resolv.conf del resto de PCs de la red
nameserver 192.168.0.112
Tan solo nos faltará poner en marcha nuestro servidor de nombres ejecutando en el servidor el script de inicio correspondiente:
// Arranque del servidor DNS
# /etc/init.d/bind9 restart
y, mediante el comando host, el comando dig o el comando nslookup hacer alguna consulta de prueba:
# host aula5pc4. saija.com
Aula5pc4. saija.com has address 192.168.0.104
# host 192.168.0.112
112.0.168.192.in-addr.arpa domain name pointer dns. saija.com
112.0.168.192.in-addr.arpa domain name pointer mail. saija.com
Insertaremos en la terminal sudo apt-get install postfix y lo instalaremos y configuraremos.
Ahora insertaremos sudo dpkg-reconfigure postfix para configurar nuestro servidor de correo
Con el siguiente comando configuraremos el soporte de los buzones de correo tipo Maildir: sudo postconf –e “home_mailbox=maildir/”
Comentarios
Publicar un comentario