Correo electronico

De Taquiones


Correo electrónico

Guía de ayuda para configurar un servidor de correo electrónico en un servidor Linux.

Mecanismos principales

SPF (Sender Policy Framework)

SPF es una normativa que permite establecer y comprobar qué máquinas están autorizadas para enviar correos electrónicos para un dominio de Internet.

La normativa exige que se defina un registro en el DNS del dominio con una estructura flexible que pueda ser consultado por aquellos servidores que reciben el correo para dar por válido el origen.

Un registro SPF tiene el siguiente aspecto:

bovalo.org.        10800    IN    TXT    "v=spf1 a include:_mailcust.gandi.net ?all"

El registro contiene lo siguiente:

  • Indicador de versión del SPF: v=spf1
  • Cero o más mecanismos que declaran direcciones IP y máquinas que pueden enviar el correo. Los mecanismos pueden estar prefijados con un calificador que altera su significado en caso de fallo. Los principales los detallo a continuación. Hay algunos más pero no los estoy contemplando.
    • a define un servidor de correo
    • mx los servidores de correo del dominio
    • ipv4 dirección IP (versión 4) o rango CIDR
    • ipv6 dirección IP (versión 6) o rango
    • include evalúa el registro SPF de los servidores incluídos (no expande a su contenido, los evalúa)
  • Los calificadores indican cómo considerar el que la IP de origen del mensaje coincida con un mecanismo:
    • + pass
    • - fail
    • ~ softfail
    • ? neutral

La evaluación de un registro SPF, que se lleva a cabo mecanismo tras mecanismo, puede resultar en alguno de los siguientes resultados:

Resultado Explicación Acción prevista
Pass El registro designa al servidor como autorizado para enviar correo Mensaje aceptado
Fail El registro designa al servidor como no autorizado Mensaje rechazado
SoftFail El registro designa al servidor como no autorizado para enviar pero considera que está en tránsito Mensaje aceptado pero marcado
Neutral El registro especifica que no puede decir nada sobre la validación Mensaje aceptado
None El dominio no tiene un registro SPF o lo tiene pero no evalúa a ningún resultado Mensaje aceptado
PermError Hay un error permanente (como un registro SPF mal formado) No se especifica
TempError Hay un error transitorio Mensaje aceptado o rechazado

Así pues para implementar SPF en un servidor de correo como exim4 es necesario actuar en dos sitios:

  1. Configurar el registro DNS del dominio para indicar al exterior que está autorizado para enviar mensajes en su nombre.
  2. Configurar el servidor para que valide los correos entrantes consultando los registros DNS de los que proceden.
Referencias
Herramientas

La validación del registro DNS (una vez que exista y se ha propagado) puede realizarse por varios medios:

DKIM (DomainKeys Identified Mail)

DKIM es el acrónimo de Domain Keys Identified Mail y es un mecanismo que también consta, como el SPF, de dos partes; ambas deben comenzar con la creación de un par de claves pública/privada que se utilizarán en:

  • La parte pública en un registro del DNS con formato especial.
  • La parte privada en el servidor que envía el correo y con la que firmará todos los que emita.

De esta manera aquél servidor que reciba nuestro correo firmado podrá descargar la clave pública de los registros del DNS y efectuar la verificación sobre los mensajes.

Los pasos a seguir son:

  1. Elegir un texto breve como selector que se utilizará en ambos lados: DNS y servidor de correo. Vale cualquier cosa pero emplear algo estándar como exim o default es buena idea para no tener que recordar nombres extraños cuando verificamos lo que hemos hecho.
  2. Crear un par de claves pública/privada con openssl teniendo en cuenta las limitaciones de espacio del registrador (gandi.net por ejemplo sólo admite 1024 bytes de longitud).
  3. Configurar el servidor de correo para que emplee la clave privada para firmar los mensajes salientes.
  4. Crear y publicar un registro TXT en el DNS con la parte pública.
  5. Verificar (una vez todo se ha actualizado) que los mensajes están correctamente firmados:
    1. Emplear un servicio en línea como DKIM Key Checker
    2. Enviar un correo a check-auth@verifier.port25.com o similar para obtener resultados desde el punto de vista del receptor.

Esta configuración para el servidor exim está explicada en su página.

Registro DNS para DKIM

Se emplea un registro tipo TXT cuyo valor es un nombre DNS ficticio formado por el selector de clave definido antes, el literal _domainkey y el nombre del dominio completo (empresa.net por ejemplo).

Así pues quedaría de la siguiente forma:

default._domainkey.empresa.net 10799 IN TXT "v=DKIM1;p=..." 

donde el valor númerico es el TTL del registro y la clave pública va como valor del parámetro p, toda junta sin saltos de línea ni espacios.

Creación del par de claves DKIM

Empleando el programa opensll se crea primero la clave RSA:

$ openssl genrsa -out clave.pem 2048

Y se extrae de ella la clave pública:

$ openssl rsa -in clave.pem -pubout -outform der 2>/dev/null | openssl base64 -A

El resultado es el que debe almacenarse en el registro DNS bajo el selector elegido.

Referencias:

DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC es un protocolo creado para intentar paliar las debilidades de los otros dos mecanismos (SPF y DKIM) de autentificación del correo electrónico, especialmente cuando hay discrepancias entre la cabecera From del mensaje y lo que se muestra como campo From. Su operativa es algo más compleja que los anteriores porque es parte de un proceso activo que está siempre basado en los dos anteriores.

La forma de proceder debería ser la siguiente:

  1. Publicar un registro DMARC para el dominio
  2. Monitorizar los informes DMARC para comprobar qué emisores de correo legítimos han fallado y por qué
  3. Modificar SPF, DKIM y DMARC para asegurarse de que esos emisores de correo tengan vía libre
  4. Ajustar las restricciones DMARC
  5. Volver a monitorizar los informes DMARC para legitimar los emisores que fallan y descubrir los emisores maliciosos que intentan suplantar tu identidad.
Registro DMARC

El registro DNS para DMARC es de tipo TXT y su estructura es la siguiente:

  1. Nombre del registro: _dmarc.empresa.net o _dmarc.smtp.empresa.net dependiendo de si es un dominio o un subdominio.
  2. En el contenido hay campos separados por un punto y coma:
    1. Literal "v=DMARC1"
    2. Campo "p=normativa" siendo normativa alguna de las siguientes:
      1. p=none indica que el servidor no llevará a cabo ninguna acción contra correos no cualificados.
      2. p=quarantine indica que el servidor debe aislar estos correos, generalmente enviándolos a una carpeta de spam.
      3. p=reject indica que el servidor receptor de correo debe rechazar todos los mensajes no cualificados por el dominio; sólo los mensajes firmados por tu dominio pueden intentar alcanzar los buzones de entrada de los receptores y todos los demás serán descartados.
    3. Campo "rua=" define la dirección de correo a la que enviar informes de fallos DMARC que se han recibido y que afectan a tu dominio. La síntaxis es "rua=mailto:dmarc@empresa.net". La dirección, obviamente, puede ser cualquiera.
    4. Campo "ruf=" define la dirección de correo a la que enviar informes forenses de fallos DMARC. La síntaxis es similar a la de rua: "ruf=mailto:dmarc@empresa.net".
    5. Campo "aspf=TAG" determina la alineación de DMARC con SPF en el caso de las cabeceras From. Más abajo puede verse una tabla con los posibles valores y resultados, pero los valores de TAG pueden ser r para modo relajado y s para modo estricto.
    6. Campo "adkim=TAG" hace lo mismo pero para la firma DKIM. Los valores pueden ser s para modo estricto y r para modo relajado. El modo estricto se asegura que el test de firma DKIM se dará por válido sólo si el campo d= en la firma coincide con el dominio en from. El modo relajado, en cambio, hará que el test DKIM se dé por válido en todos los casos donde el campo d= coindica con el dominio raíz de la dirección from.
    7. Campo "fo=LEVEL" que determina cuándo enviar un informe sobre la validación DMARC. El valor predeterminado es 0 y se puede elegir entre:
      • 0 Se envía un informe si el correo falla los alineamientos SPF y DKIM
      • 1 Se envía un informe si el correo falla alguno de los dos test de alineación
      • 2 Se envía el informe si falla el test de alineación DKIM
      • 3 Se envía el informe si falla el test de alineación SPF

El registro típico para DMARC en un dominio sencillo sería el siguiente:

v=DMARC1;p=none;rua=mailto:dmarc@exampledomain.com;ruf=mailto:dmarc@exampledomain.com;apsf=r;adkim=r;
Alineación SPF en DMARC
Dominio en campo From Dominio SPF Chequeo relajado Chequeo estricto
example.org example.org Aceptado Aceptado
example.org mail.example.org Aceptado Rechazado
mail.example.org mail.example.org Aceptado Aceptado
mail.example.org example.org Aceptado Rechazado
example.mail.org example.org Rechazado Rechazado
ARC - Authenticated Received Chain

Resumen de registros DNS para un servidor de correo

No todos los registros son obligados pero para un servidor más o menos completo lo que hay que definir en el DNS es lo siguiente:

  • Información general:
    • Registro A: con la IP del servidor de correo
    • Registro MX: para indicar qué servidor gestiona el correo del dominio.
    • Registro PTR: para comprobar que el servidor de correo resuelve efectivamente a esa IP. Difícil de conseguir a menos que se tenga un servidor DNS propio o el proveedor del servidor lo permita.
  • Medidas de seguridad:
    • Registro SPF: para indicar qué máquinas (nombre o IP) pueden enviar correo para el dominio y qué hacer en caso de que no se cumpla.
    • Registro DKIM: conteniendo la clave pública para comprobar si los mensajes están cifrados con la clave privada del dominio.
    • Registro DMARC: indica qué hacer con el correo si fallan los mecanismos SPF y DKIM y proporciona una dirección de correo a la que enviar informes de fallos.
  • Descubrimiento de servicios:
    • Envío de correo: registro de tipo SRV (_submission._tcp.) indicando donde encontrar el servidor SMTP.
    • Acceso al correo IMAP: registro de tipo SRV (_imap._tcp o _imaps._tcp) donde encontrar el servidor IMAP.
    • Acceso al correo POP3: registro de tipo SRV (_pop3._tcp o _pop3s._tcp) donde encontrar acceso POP3 a los mensajes.
Ejemplos

Para un dominio llamado empresa.net que disponga de servidor de correo completo sus registros DNS quedarían de la siguiente manera:

# Registros generales
@ 10800 IN A ###.###.###.###
@ 10800 IN MX 10 smtp.empresa.net.

# Seguridad del correo: SPF, DKIM, DMARC
@ 10800 IN TXT "v=spf1 a:smtp.empresa.net -all"
default._domainkey 10800 IN TXT "v=DKIM1; p=MIGfMA0GCSqGSIb3....."
_dmarc.empresa.net 10800 IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; sp=none"

# Descubrimiento de servicios
_imap.tcp 10800 IN SRV 10 10 143 imap.empresa.net.
_imaps._tcp 10800 IN SRV 10 10 995 imap.empresa.net.
_submission._tcp 10800 IN SRV 0 1 25 smtp.empresa.net.
Referencias

Recetario

Herramientas de validación en línea
SPF para dominios sin correo

Si se tiene un dominio de Internet que no envía correo electrónico alguno es conveniente protegerlo para que pueda ser usado por terceros definiendo el SPF como sigue:

empresa.net. 10800 IN TXT "v=spf1 -all"
Reescribiendo el asunto del mensaje

Cuando necesitamos reescribir el campo asunto de un mensaje de correo podemos utilizar una mezcla de herramientas que trabajan bien entre sí:

  • reformail (en el paquete maildrop) para quitar y poner cabeceras al mensaje.
  • Perl y el módulo Encode por si es necesario manipular textos codificados.
  • maildrop o algo similar para filtrar el correo justo antes de su entrega.

Todo ello envuelto en un programa como el siguiente ...

#!/bin/sh

#   Como ayuda para depurar fijamos un valor 
#   predeterminado para la etiqueta 
LABEL=${1:-LABEL}

#   Tenemos que salvar todo el mensaje entrante en un archivo temporal
#   porque las operaciones posteriores se llevan en dos fases
TMPMSG=/tmp/$(basename $0).$$ 
cat > $TMPMSG

# La primera fase es leer el campo 'Subject' y almacenarlo en una 
# variable,
SUBJECT=$(reformail -x Subject: < $TMPMSG)

# a la que añadimos el etiquetado entre corchetes,
NEWSUBJECTPARAM="Subject: [${LABEL}] ${SUBJECT}"

# y la segunda fase consiste en sustituir el campo 'subject' por el que hemos
# formado y renombrar el anterior con el prefijo 'old-' para no perder
# contenido.
reformail -i "${NEWSUBJECTPARAM}" < $TMPMSG

... y situado en el filtro de correo de la cuenta o cuentas de correo que necesitamos; lo siguiente es un ejemplo de cómo añadir una etiqueta especial a aquellos mensajes que contengan notificaciones de Correos y Telégrafos y está situado dentro del archivo $HOME/.mailfilter:

#
#   Notificaciones e correos.es
#
if (/^From:.*correos.es/) 
{
    xfilter "/usr/local/bin/add2subject CORREOS"
}
Testear autentificación IMAP
  • Ref: How to test an IMAP server by using telnet

Si utilizamos una conexión plana con un servidor IMAP lo podremos hacer así:

 $ telnet taquiones.net imap
 Trying 80.68.92.119...
 Connected to taquiones.net.
 Escape character is '^]'.
 * OK [CAPABILITY IMAP4rev1 ... AUTH=PLAIN] Dovecot ready.
 a1 LOGIN victor PASSWORD
 a1 OK [CAPABILITY IMAP4rev1 ... SPECIAL-USE] Logged in
 a2 LOGOUT
 a3 LOGOUT
 * BYE Logging out
 a3 OK Logout completed.
 Connection closed by foreign host.

Y si necesitamos una conexión segura tendremos que utilizar openssh en lugar de telnet variando el puerto según el servidor esté configurado:

 $ openssl s_client -connect taquiones.net:995 -quiet
 depth=1 C = ES, ST = Madrid, O = Taquiones, OU = CA, CN = taquiones.net, emailAddress = postmaster@taquiones.net
 verify error:num=19:self signed certificate in certificate chain
 verify return:0