El correo es uno de los servicios de Internet más antiguos y más complejos de configurar si queremos que queden reducidos al mínimo elementos como el spam, phishing y otros elementos maliciosos. Y de la misma forma que la web está comenzando a obligar a implementar servicios como el HTTPS por defecto, el correo necesita de lo mismo.
¿Por dónde empezar? Pues con elementos básicos de buenas prácticas. Lo inicial para el correo es que se pueda enviar y recibir correo desde el dominio en sí. Esto significa que hemos de configurar POP/IMAP y SMTP.
La configuración básica
El primer paso que hemos de hacer es que el dominio resuelva. Para todo el ejemplo usaré el dominio example.com. Así que, lo primero es añadir una entrada en las DNS con la entrada A apuntando a una IP. A ser posible, si existe, también una AAAA para el IPv6.
example.com A 10.0.0.1
example.com AAAA fd00::1Lo siguiente será configurar las entradas MX para poder recibir el correo en el servidor. Cada proveedor nos ofrecerá una serie de opciones, pero como ejemplo podemos tener algo tal que así:
example.com MX 1 10.0.0.1
example.com MX 5 10.0.0.2
example.com MX 10 10.0.0.3Con esto podremos crear ya cuentas de correo que nos permitan recibir correo. Todos los dominios deberían tener algunas cuentas de correo mínimas por defecto para que se puedan recibir correos cuando hay problemas. Las cuentas que deberían existir, como mínimo, son abuse@example.com y postmaster@example.com.
Ahora ya tenemos el correo como tradicionalmente ya existía. A partir de este momento podemos añadir ciertas novedades que han ido apareciendo en los últimos años. Entre ellas encontramos el SPF, DKIM, DMARC y MTA-STS.
SPF – Sender Policy Framework
El SPF (Sender Policy Framework) es un sistema de protección que puede reducir la falsificación de los servidores que permiten el envío de correo de un dominio. Básicamente lo que permite es indicar, mediante DNS, qué direcciones IP tienen permiso para enviar correo para ese dominio. Esto, bien configurado, permite reducir el envío de spam en nombre de otros.
Un ejemplo podría ser este:
example.com. IN TXT "v=spf1 a mx ptr -all" Todo comenzó con el RFC 4408, que se sustituyó con los RFC 7208 y RFC 6652, además de complementarse con el RFC 7273.
Básicamente, de todas las configuraciones que podemos revisar, lo importante sería configurar este sistema de manera estricta, por lo que el -all al final, siempre debería ser un «guión all» y no un «tilde all«. Con este sistema, si el correo no está 100% seguro de haber sido enviado desde una dirección válida, se marcaría como FAIL y por tanto sería rechazado.
DKIM – DomainKeys Identified Mail
El DKIM (DomainKeys Identified Mail) es lo segundo que haremos, y será configurar el sistema para autenticar el correo y que pueda ser validado por el receptor. Es un sistema comparable a lo que sería el HTTPS en la web. El objetivo es verificar que el contenido de los mensajes no puedan ser modificados en ningún momento de la cadena.
La idea básica es un sistema de claves de forma que cuando el correo se recibe, se verifica que ha sido codificado correctamente y que no se ha modificado.
Lo más habitual es encontrar algo del estilo a esto:
default._domainkey.example.com TXT "k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4su"En este caso tenemos documentación en los RFC 6376, que es la base, complementado con los RFC 8301 o el RFC 8463.
Si tu proveedor de correo no te permite el uso de DKIM, cambia de proveedor.
DMARC – Domain-based Message Authentication, Reporting and Conformance
El DMARC (Domain-based Message Authentication, Reporting and Conformance) viene a ser el sistema que verifica que todo se cumple y que permite que se reciba información de cómo se están comportando los sistemas. Viene a ser una expansión complementaria del SPF y DKIM.
Un ejemplo podría ser similar a este:
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:hello@example.com; ruf=mailto:hello@example.com; pct=100; adkim=s; aspf=s"El sistema se estableció en el RFC 7489 y se ha complementado con el RFC 8553 y el RFC 8616.
Este sistema, además, pemite que se manden una serie de informes sobre qué está ocurriendo en cuanto al cumplimiento del SPF y del SKIM, y que llegará en un formato establecido a la dirección de correo que le indiquemos.
BIMI – Brand Indicators for Message Identification
El BIMI (Brand Indicators for Message Identification) es uno de los estándar más novedosos y al que se han unido empresas de correo importantes. Básicamente su función es mostrar una imagen de forma que los correos estén verificados visualmente.
default._bimi.example.com TXT v=BIMI1;l=https://www.example.com/logo.svgDe esta manera, cuando se mande un correo desde tu dominio, se verificará que existe un logo, y s e mostrará por los sistemas de correo de forma mejorada, para dar confianza a los usuarios.
SMTP-TLS – SMTP TLS Reporting
De la misma manera que con DMARC podemos recibir información de problemas de otra gente que está intentando enviar correo de forma abusiva, con este sistema podremos recibir información de problemas a la hora de enviar correo nosotros.
El sistema es bastante sencillo, ya que lo único necesario es una cuenta de correo donde queramos recibir los informes.
_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:hello@example.com"Este sistema está documentado en el RFC 8640.
MTA-STS – MTA Strict Transport Security
Este seguramente sea el protocolo más actual relacionado con el correo. El MTA-STS (MTA Strict Transport Security) viene a ser la versión HSTS de la web llevada al correo, y básicamente lo que hace es forzar que sólo se puedan usar protocolos seguros a la hora de gestionar el correo. Esto significa que los puertos del correo deberán ser obligatoriamente los puertos seguros.
La información de este sistema se encuentra en el RFC 8641.
Para procesar este sistema se deben realizar distintos pasos. No es complicado, pero sí es algo engorroso de gestionar.
Lo primero que hace falta será la creación del subdominio mta-sts, que deberá ser un hosting real donde podamos subir ficheros. Además debe ser un sitio web que soporte HTTPS.
mta-sts.example.com A 10.0.0.1Una vez tengamos el alojamiento creado, deberemos crear el siguiente fichero:
https://mta-sts.example.com/.well-known/mta-sts.txtEn este fichero deberemos indicar la configuración de servidores de entrada de correo válidos. Básicamente deberemos indicar los servidores MX que tenemos ya configurados en nuestras DNS. Un ejemplo podría ser similar al siguiente:
version: STSv1
mode: enforce
max_age: 604800
mx: mail.example.comUna vez tengamos todo esto, deberemos añadir una entrada en las DNS que indique la existencia de este fichero y un identificador único a modo de hash que permita saber si ha cambiado. Lo habitual podría ser usar un identificador numérico que indique la fecha de última actualización, o por ejemplo un CRC32 del contenido del fichero.
_mta-sts.example.com TXT "v=STSv1; id=28d002f4"Con esto obligaremos a que los lectores de correo deban usar los protocolos seguros a la hora de descargarse el correo.
¿Qué implicaciones tiene?
¿Significa todo esto que voy a dejar de recibir spam o phising? La respuesta más probable es no, pero sí que mejorarán algunos sistemas de detección, como por ejemplo en Google Mail o en herramientas de detección como SpamAssasin.
Al fin y al cabo estos sistemas están basados en RFC, por lo que son estándar y lo único que pueden hacer es ayudarte a mejorar la seguridad y a compatibilidad de todos los sistemas.
Responder a Danna Ramirez Cancelar la respuesta