Lenguas: es fr

Auto-alojamiento de mails con OpenSMTPD

Fecha : última revisión en Febrero del 2015.

El objetivo de este tutorial es servir de guía para alojar uno mismo los mails de forma bastante simple. El servidor mail usado, elegido por su sencillez, es OpenSMTPD y se supone ya instalado.

Supondremos desde ahora que toto y titi son dos usuarios del sistema en el servidor que albergará los mails y éste se denominará example.com.

1 Auto-alojamiento minimalista de los mails

1.1 Paso a paso

Queremos permitir a toto enviar mails a otros usuarios del servidor, pero también hacia otros servidores, e igualmente que pueda recibir mails.

La configuración de OpenSMTD (smtpd) se realiza principalmente en el fichero smtpd.conf que se encuentra en la ruta /etc/mail/smtpd.conf en OpenBSD, y probablemente en una ruta similar en otros sistemas. La página man smtpd.conf(5) describe todas las posibilidades de configuración pero aquí no necesitamos más que una pequeña parte. Vamos a detallar poco a poco las líneas que va a contener smtpd.conf y que necesitaremos.

Primero, hay que decirle a smtpd que escuche en la interfaz local loopback para que los usuarios locales del servidor puedan comunicar con smtpd.

listen on lo0

Después queremos que otros servidores puedan enviar mails a nuestro usuario. Para ello el servidor debe estar escuchando en la interfaz de red conectada a la pasarela por defecto, el "gateway".

listen on egress

Podemos remplazar el nombre de grupo egress por el nombre exacto de la interfaz de red.

Ahora nos ocupamos de la entrega de los mails. Para ello primero necesitamos definir la distribución de los mails hacia los usuarios y lo haremos con la ayuda del fichero /etc/mail/aliases. En este fichero escribiremos por ejemplo :

toto: toto
titi: toto, titi

para especificar que los mails destinados a toto@example.com deben llegar al usuario toto, y los mails con destino titi@example.com serán recibidos tanto por el usuario titi como por toto. La página man aliases(5) describe otras posibilidades más avanzadas que ofrece el fichero aliases.

El comando newaliases permite después generar una base de datos /etc/mail/aliases.db a partir del fichero aliases.

Ahora ya podemos definir dentro de smtpd.conf una tabla aliases.

table aliases db:/etc/mail/aliases.db

Queremos que el buzón mail del usuario toto se encuentre en la ruta /home/toto/mail/inbox y que sea del tipo maildir.

Primero, permitimos a los usuarios locales (entre ellos toto) recibir mails de los demás usuarios locales usando la configuración dada en la tabla <aliases> Usamos la sintaxis entre < y > para referirse a la tabla. La sintaxis %{user.uername} permite recuperar el nombre del usuario que debe recibir el mail.

accept from local for local alias <aliases> deliver to maildir "/home/%{user.username}/mail/inbox"

Por defecto, smtpd acepta únicamente las peticiones locales, luego la línea anterior puede simplificarse como :

accept for local alias <aliases> deliver to maildir "/home/%{user.username}/mail/inbox"

Después queremos que otros servidores puedan entregar mails a nuestros usuarios :

accept from any for domain example.com \\
    alias <aliases> \\
    deliver to maildir "/home/%{user.username}/mail/inbox"

Y por último queremos que los usuarios locales puedan enviar mails no sólo a los usuarios locales sino también hacia otros servidores :

accept for any relay

Igualmente el from local es implícito aquí también.

1.2 Recapitulativo

Al final nuestro fichero smtpd.conf se parecerá a esto :

listen on lo0
listen on egress
table aliases db:/etc/mail/aliases.db

accept for local alias <aliases> deliver to maildir "/home/%{user.username}/mail/inbox"
accept from any for domain example.com \\
    alias <aliases> \\
    deliver to maildir "/home/%{user.username}/mail/inbox"
accept for any relay

y lo único que queda es (re)iniciar el servicio.

2 Pero también me gustaría enviar y leer mails desde donde quiera !

La configuración propuesta hasta aquí permite a los usuarios locales del servidor enviar y recibir mails sin problemas, pero no permite usar el servidor para hacerlo desde otra máquina.

Son posibles varias alternativas. La más simple, y que no requiere configuración particular, es quizás usar OpenSSH para loguearse como usuario local del servidor utilizando un cliente mail en modo texto como mutt. Es el método que utilizo yo y que no necesita poner en marcha otro servicio servidor (ssh probablemente ya esté en corriendo) y que facilita el intercambio al abrigo de orejas indiscretas con los demás usuarios del servidor.

Existe también la posibilidad de permitir al servidor smtpd entregar los mails del servidor hacia el exterior autentificándose como usuario local con la ayuda del argumento auth-optional de la directiva listen, lo que soluciona el problema del envío. También podemos crear usuarios virtuales para la autentificación usando una tabla de autentificación. Para acceder a los mails desde el exterior es más complicado y habrá que pasar por configurar un servidor pop/imap como dovecot, por ejemplo, lo cual sobrepasa el objetivo de este tutorial.

3 Acerca del cifrado y los certificados

En la configuración propuesta más arriba los mensajes recibidos desde los demás servidores transitarán en claro, sin cifrado, y cualquiera que los interceptara podría leerlos. Para protegerse de los indiscretos, habitualmente, se cifran los mails de una manera u otra.

Podemos, por ejemplo, desear usar un certificado en el servidor, lo cual no es muy difícil a poner en práctica, aunque sí quizás más delicado de entender. Hay otras posibilidades, de dificultad similar, como cifrar los mails con PGP, lo cual es útil con personas con quienes ya hemos intercambiado las llaves de cifrado a tráves de un medio seguro.

Hay que aclarar, sin embargo, que usar un certificado no es una obligación y que añadir funcionalidades al servidor es añadir posibles errores humanos o agujeros de seguridad. El método con PGP no tiene este inconveniente.

Para que un certificado sea fiable para un servidor externo tiene que estar firmado por una autoridad de certificación (cf. wikipedia sobre el tema ), en la cual tenga una confianza razonable. El caso es que no es tan fácil de obtener ni está exento de complicaciones por lo que vamos a contentarnos con un certificado auto-firmado, es decir, sin pasar por una autoridad que certifique su autenticidad. Por tanto, a menos que por algún medio seguro se haya hecho con la llave pública (en un intercambio seguro, en mano) el servidor que quiera entregar un correo no podrá estar seguro de que nadie se haga pasar por nosotros. Los mensajes no irán en claro por defecto por lo que alguien que quiera interceptarlos tendrá un poco más de trabajo para ello. Algo es algo.

Para crear el certificado la página man smtpd.conf(5) muestra ejemplo de los comandos :

# openssl genrsa -out /etc/ssl/private/mail.example.com.key 4096
# openssl req -new -x509 -key /etc/ssl/private/mail.example.com.key \\
          -out /etc/ssl/mail.example.com.crt -days 365
# chmod 600 /etc/ssl/mail.example.com.crt
# chmod 600 /etc/ssl/private/mail.example.com.key

lo que creará una llave pública /etc/ssl/smtpd.example.com.crt y una llave privada /etc/ssl/private/mail.example.com.key. Después, en smtpd.conf, podemos añadir las líneas :

pki mail.example.com certificate "/etc/ssl/mail.example.com.crt"
pki mail.example.com key "/etc/ssl/private/mail.example.com.key"

Aquí, mail.example.com es sólo un nombre, puede remplazarse por cualquier cosa.

Y por último, cambiamos la línea :

listen on egress

por

listen on egress tls pki mail.example.com

para que el servidor use un cifrado utilizando el certificado definido como mail.example.com. En este caso el cifrado está habilitado (pero es opcional) gracias a la opción tls. El hecho de elegir un cifrado opcional es lo más razonable porque todos los servidores de correo en internet no usan cifrado y lo importante en este caso es recibir mails de cualquier fuente. De todas formas para un intercambio particular, en el que queramos estar al abrigo de cualquier escucha, este método no es probablemente el mejor.

4 ¿Y qué pasa con el spam ?

No me he preocupado por el tema, ya que apenas recibo, y por tanto no hablaré de ello en este tutorial.

5 Conclusión

Aunque este tutorial recrea un servidor mail un poco minimalista, que puede parecer poco práctico al basarse en la utilización de ssh para el usuario distante, puede ser suficiente y útil según mi experiencia. No hay que olvidar que, a menos que seamos un administrador aguerrido, es mejor tender hacia la simplicidad del lado del servidor, lo que evita errores. Cuantos menos servicios haya arrancados y más simple sea la configuración, menos posibilidades de olvidar detalles que se transformen en agujeros de seguridad, y menos posibilidades igualmente de que al de un año no entendamos nada de lo que hayamos hecho.


Escrito por Anaseto. Traducido por dornoj.