Desgooglearse (VI). Servidor de correo electrónico – Parte 1


Entradas anteriores

Correo electrónico

En esta entrada vamos a explicar los pasos para configurar nuestro propio servidor de correos y tener la posibilidad de dejar de utilizar Gmail. La situación ideal es tener un correo asociado a nuestro propio dominio (correo del tipo usuario@DOMINIO), independientemente de que ese correo se gestione directamente o a través de un servicio que contratemos. De esta forma se podría cambiar en el futuro de una situación a otra, o bien cambiar de proveedor de forma transparente y sin tener que notificar a ningún contacto ni modificar ninguna aplicación o servicio.

La configuración y mantenimiento de un servidor de correos es una tarea bastante más compleja que las anteriores explicadas, ya que hoy en día se enfrenta a dos problemas importantes: conseguir reducir lo máximo posible el correo no deseado que llegue a tus usuarios y que los mensajes que envía tu servidor a otros no se considere correo no deseado por estos. La alternativa a montar tu propio servidor de correos, es contratar el servicio de forma externa redirigiendo el registro MX de tu dominio a la misma; hay varias opciones, siendo quizás Protonmail el servicio que goza de más fama hoy en día, ya que fue creado con la privacidad como objetivo después de las revelaciones de Edward Snowden de vigilancia masiva por parte de diversas agencias estadounidenses.

IP estática y “limpia”

Tenemos un VPS con una dirección IPv4 pública estática y con una dirección IPv6 global. Esto es un aspecto importante ya que si hubiésemos optado por montar el servidor localmente, lo más probable es que tuviésemos una dirección IPv4 dinámica que cambiase cada cierto tiempo, lo que hace realmente complicado utilizar un servidor de correo hoy en día (En el caso de tener conexión a Internet con CGNAT no sería posible montar ningún servicio, ni correo, ni web ni nada).

Otra cosa que debemos comprobar antes de empezar es que nuestra IP no esté en ninguna lista de spam, porque hubiese estado asociada anteriormente a una máquina que hubiese sido categorizada como emisora de spam. Hay muchos sitios que ofrecen rápidamente esa información, como por ejemplo dnsbl-database-check. En el caso de que nuestra dirección IP estuviese en una o varias listas de spam, tendríamos que proceder a solicitar que la sacasen una a una, siguiendo el procedimiento que nos indicasen en cada caso. Afortunadamente no he tenido esta vez ese problema y la IP que estoy usando está “limpia como una patena” :).

Registro MX

Creamos en el DNS un registro MX al FQDN de nuestra máquina, indicando el nombre de la máquina que se va a encargar de gestionar el correo del tipo @DOMINIO. No estamos interesados en gestionar en principio otras direcciones de correo del tipo @algo.DOMINIO, solo @DOMINIO que se indica precisamente a través de este tipo de registro DNS.

La ensalada de protocolos y métodos

El correo electrónico es más complejo de configurar que otros servicios porque se trata de un conjunto de servicios y protocolos que hay que configurar, no uno solo y hay que tener claro en qué consiste cada uno de ellos.

SMTP

Simple Mail Transfer Protocol es la base de correo electrónico. SMTP es el protocolo que utilizan los servidores de correo para enviar y recibir correos. SMTP se comenzó a definir en 1982, cuando la seguridad de los protocolos no era ni mucho menos la principal preocupación y spam era un pedazo de carne de aspecto bastante dudoso distribuido en lata. El protocolo SMTP ha sido revisado y actualizado desde entonces, pero al ser un protocolo tan extendido, las modificaciones siempre han estado limitadas por la compatibilidad con versiones anteriores y siempre se está en la tesitura de si se es muy estricto se pueden rechazar mensajes legítimos que provengan de servidores con configuraciones básicas y si se es muy permisivo pueden llegar muchos correos no deseados. Buscar el equilibrio adecuado es la base a la hora de configurar el servidor SMTP.

Un aspecto importante que hay que notar es que un servidor de correos se comporta tanto como servidor (cuando recibe una conexión en el puerto 25/tcp para recibir un mensaje) como cliente (cuando se conecta al puerto 25/tcp del servidor destino para enviar un mensaje). Por lo que al configurar nuestro servidor de correos, tendremos que tener en cuenta directivas para cada uno de los casos.

Hay múltiples implementaciones de SMTP, y aunque comencé hace ya muchos años peleándome con sendmail, es postfix el servidor que configuro desde hace años en todos los servidores en los que tengo que montar SMTP. Postfix es un software muy completo y relativamente sencillo de configurar. Para instalar postfix basta con instalar el paquete postfix y contestar a las preguntas de debconf, en particular:

  • Tipo de servidor: Internet Site (vamos a recibir y enviar correo directamente)
  • Mailname: DOMINIO
  • Destinos para los que se acepta correo: DOMINIO, localhost
  • Redes desde las que se permite enviar correo: 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

Con esto tendremos el servidor con una configuración básica, aceptando correos @DOMINIO a través del puerto 25/tcp:

LISTEN    0         100                0.0.0.0:25               0.0.0.0:*
LISTEN    0         100                   [::]:25                  [::]:*

El problema es que con esa configuración básica los correos que enviemos pueden ser rechazados por el servidor SMTP remoto y aceptamos cualquier correo con destino @DOMINIO por lo que podríamos recibir grandes cantidades de spam.

SMTPS

SMTPS es SMTP + TLS, es decir, que se sigue utilizando entre cliente y servidor el mismo protocolo SMTP, pero la comunicación se cifra con TLS, consiguiendo que no sea posible leer el mensaje de correo en ningún punto intermedio. Obviamente es mucho mejor utilizar SMPTS que SMTP, pero eso no depende solo de nosotros sino también de la otra parte en cada conexión (servidor o cliente), por lo que lo habitual es configurarlo de manera opcional, tanto cuando postfix se comporta como servidor como cuando lo hace como cliente. En esta entrada vamos a explicar la configuración de postfix para que utilice SMTPS cuando envíe correo siempre que sea posible y dejamos la configuración de SMPTS en el servidor para la próxima entrada. Esta configuración es muy sencilla, porque basta con añadir en /etc/postfix/main.cf las directivas (la que especifica que el protocolo TLS sea >= 1.2 es opcional pero recomendable hoy en día):

smtp_tls_security_level = may
smtp_tls_protocols = >=TLSv1.2
smtp_tls_note_starttls_offer = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Podemos hacer una prueba enviando un correo a un servidor que soporte SMTPS y veremos que aparece una cabecera adicional con los detalles de la conexión SMTPS desde nuestro equipo cliente, algo como:

Received: from DOMINIO (X.red-X-X-X.staticip.rima-tde.net
        [X.X.X.X])
        (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
        key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
        (No client certificate requested)
        by x.x.x.x (Postfix) with ESMTPS id 70D46E9
        for ; Mon, 18 Jan 2021 13:51:06 +0100 (CET)

SPF

En principio cualquier máquina puede enviar mensajes de correo a cualquier destino utilizando cualquier remitente, esto es así en principio para permitir que podamos enviar mensajes con diferentes remitentes usando un mismo servidor de correos, pero esta característica del correo ha sido masivamente usada para inundar de mensajes no deseados los servidores de correo y para hacer suplantación del remitente (email spoofing), por lo que se ha generalizado la implementación de medidas complementarias para reducir al máximo este problema y hoy en día la mayoría de servidores de correo o rechazan o mandan a la bandeja de spam los mensajes que lleguen desde servidores que no implementen algún mecanismo adicional de autenticación.

Sender Policy Framework (SPF) es un mecanismo de autenticación que mediante un registro DNS de tipo TXT describe las direcciones IPs y nombres DNS autorizados a enviar correo @DOMINIO. Actualmente muchos servidores de correo exigen como mínimo tener un registro SPF para tu correo o en caso contrario los mensajes provenientes de tu servidor se clasifican como spam o se descartan directamente.

Se pueden especificar diversos campos en el registro, pero en este caso, que tenemos un solo equipo con una dirección IPv4, una dirección IPv6 y el nombre de dominio asociado a la IP, podemos poner como registro SPF el siguiente:

DOMINIO.    600 IN  TXT "v=spf1 a mx ip4:IPv4/32 ip6:IPv6/128 a:DOMINIO. -all"

Es importante comentar el signo que aparece antes de “all”, ya que podemos indicarle a los otros servidores lo que deben hacer si reciben correo desde otra dirección o máquina diferente a las que aparecen en el registro anterior:

  • -: Descartar el mensaje
  • ~: Clasificarlo como spam
  • ?: Aceptar el mensaje (sería como no usar SPF)

De esta forma el correo que enviemos desde nuestra máquina, pasará los filtros SPF en destino y la mayoría de nuestros correos llegarán a destino con poca probabilidad de que se clasifiquen como spam. Otra configuración diferente es modificar postfix para que haga la verificación de SPF de los correos recibidos, que haremos en la próxima entrada.

DKIM

DomainKeys Identified Mail o DKIM es un método de autenticación pensado principalmente para reducir la suplantación de remitente. DKIM consiste en que se publica a través de DNS la clave pública del servidor de correos y se firman con la correspondiente clave privada todos los mensajes emitidos, así el receptor puede verificar cada correo emitido utilizando la clave pública.

Para configurar DKIM en nuestro servidor instalaremos opendkim y opendkim-tools y realizaremos la siguiente configuración:

grep -v '^$\|^#' /etc/opendkim.conf

Syslog          yes
UMask           002
Canonicalization        relaxed/simple
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
Mode            sv
Socket          local:/var/spool/postfix/opendkim/opendkim.sock
PidFile         /var/run/opendkim/opendkim.pid
OversignHeaders     From
TrustAnchorFile     /usr/share/dns/root.key
UserID          opendkim

Donde hemos modificado el servicio para que se ejecute en un socket dentro del directorio postfix, porque a continuación vamos a conectar ambos servicios. Editamos el fichero /etc/opendkim/TrustedHosts e incluimos una lista de todos los nombres e IPs en los que se confía directamente (todos los posibles nombres de la propia máquina de momento):

127.0.0.1
::1
localhost
HOSTNAME
*.DOMINIO

Creamos el directorio /etc/opendkim/keys/DOMINIO/ y lo protegemos adecuadamente, ya que vamos a ubicar dentro la clave privada de DKIM:

mkdir  /etc/opendkim/keys/DOMINIO/
chown opendkim. /etc/opendkim/keys/DOMINIO/
chmod 0710 /etc/opendkim/keys/DOMINIO/

Usamos la aplicación opendkin-genkey para generar la clave privada y el registro para el DNS:

opendkim opendkim-genkey -D /etc/dkimkeys/keys/DOMINIO -d DOMINIO -s mail

Esto genera los ficheros mail.private y mail.txt, el primero con la clave privada y el segundo con el registro TXT que debemos agregar a nuestro DNS:

mail._domainkey IN  TXT ( "v=DKIM1; h=sha256; k=rsa; "
                                  "p=MIIBIjANBgkqhkiG9w...Klw"
                                   "va0hJE12...AQAB" )  ;

Modificamos los siguientes ficheros:

/etc/opendkim/SigningTable

*@DOMINIO mail._domainkey.DOMINIO

/etc/opendkim/KeyTable

mail._domainkey.DOMINIO DOMINIO:mail:/etc/opendkim/keys/DOMINIO/mail.private

Verificamos que la configuración del registro de DKIM es correcta utilizando alguna herramienta externa como https://mxtoolbox.com/dkim.aspx, que da los resultados de forma fácilmente interpretable:

Ahora queda configurar postfix para que firme los correos que envía, para lo que editamos el fichero /etc/postfix/main.cf y añadimos:

milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:/opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

DMARC

DMARC es el último mecanismo de autenticación que vamos a configurar, realmente lo hace DMARC es ampliar el funcionamiento de SPF y DKIM, mediante la publicación en DNS de la política del sitio, en el que decimos si usamos, SPF, DKIM o ambos, entre otras cosas.

La configuración de DMARC para el correo saliente es sencilla, consiste en un registro DNS TXT en el que se especifica si se está usando SPF y/o DKIM y qué hacer con el correo que no cumpla con los mecanismos de autenticación que estén habilitados, como en este caso están ambos, creamos un registro como el siguiente:

_dmarc.DOMINIO. 3600    IN  TXT "v=DMARC1; p=quarantine;adkim=r;aspf=r; rua=mailto:postmaster@DOMINIO"

Se pueden ver los detalles del formato en: https://mxtoolbox.com/dmarc/details/what-is-a-dmarc-record.

Dejamos la configuración de la verificación de DMARC del correo recibido para la próxima entrada.

Prueba de configuración

En https://www.mail-tester.com/ tenemos una herramienta completa y fácil de usar a la que podemos enviar un correo para que verifique y puntúe el correo que enviamos. Parece que ya tenemos bien configurado postfix para que envíe correo correctamente, sea aceptado por los destinatarios y no lo clasifiquen como spam.

En la siguiente entrada haremos énfasis en la configuración de postfix para recibir correo, lo que implica algunos protocolos que hemos visto aquí en parte y otras consideraciones adicionales.

Desgooglearse (VI). Servidor de correo electrónico – Parte 1

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s