Fecha : última revisión en Octubre del 2023 (OpenBSD 7.3).
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á
mail.example.com.
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@mail.example.com
deben llegar al usuario
toto,
y los mails con destino
titi@mail.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.
action "local" maildir "/home/%{user.username}/mail/inbox" alias <aliases>
match from local for local action "local"
Por defecto,
smtpd
acepta únicamente las peticiones locales, luego la línea
anterior puede simplificarse como :
action "local" maildir "/home/%{user.username}/mail/inbox" alias <aliases>
match for local action "local"
Después queremos que otros servidores puedan entregar mails a nuestros usuarios :
action "fromout" maildir "/home/%{user.username}/mail/inbox" alias <aliases>
match from any for domain mail.example.com action "fromout"
Y por último queremos que los usuarios locales puedan enviar mails no sólo a los usuarios locales sino también hacia otros servidores :
action "toout" relay match for any action "toout"
Igualmente el
from local
es implícito aquí también.
Al final nuestro fichero
smtpd.conf
se parecerá a esto :
listen on lo0
listen on egress
table aliases db:/etc/mail/aliases.db
action "local" maildir "/home/%{user.username}/mail/inbox" alias <aliases>
action "fromout" maildir "/home/%{user.username}/mail/inbox" alias <aliases>
action "toout" relay
match for local action "local"
match from any for domain mail.example.com action "fromout"
match for any action "toout"
y lo único que queda es (re)iniciar el servicio.
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.
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.
Es relativemente fácil hoy en día con Let’s Encrypt (ver la página man
acme-client(1) en OpenBSD, por ejemplo), aunque lo era menos
antes.
En este tutorial 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 cert "/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.
No me he preocupado por el tema, ya que apenas recibo, y por tanto no hablaré de ello en este tutorial.
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.