Correo

Cada capa de la seguridad del correo está diseñada para volver a funcionar en vez de fallar de forma segura. Arranca la línea de STARTTLS de un saludo y un emisor oportunista sigue en claro, cosa que el RFC 3207 describe como un ataque y, en un servidor público, te prohíbe defenderte de ella. Este post captura ese man-in-the-middle en un laboratorio, luego recorre los siete ajustes que protegen un mensaje en tránsito, mostrando de cada uno qué protege, qué no, y cómo falla en abierto cuando está mal. De ahí a DANE: por qué un registro TLSA no vale nada sin DNSSEC debajo, por qué importan el 3 1 1 y la reutilización de clave, y cómo un registro caducado es el único fallo que cierra en vez de abrir. Luego un censo de solo lectura de los bancos del Reino Unido, los grandes proveedores de correo y las autoridades de certificación, contando cuántos hacen algo de esto de verdad.

De fábrica Postfix envía en claro cuando el otro extremo no ofrece TLS y acepta correo de cualquiera que diga ser cualquiera. Esta es la otra construcción: Postfix 3.10.13 con Dovecot para los logins, Rspamd para SPF, DKIM y DMARC, y postfix-tlspol para DANE y MTA-STS. Sin texto plano a la entrada ni a la salida, el puerto 25 nunca retransmite, un login es dueño de sus direcciones en el sobre y en la cabecera From, los dominios de remitente que no existen se rechazan, y un mensaje manipulado o falsificado nunca pasa de DATA. Cada respuesta se capturó en un laboratorio sobre IPv4 e IPv6, junto a los cinco ajustes que no hacen nada en silencio hasta que algo más también está puesto, el valor por defecto de certbot que rompe DANE en la renovación, y lo que todo ello te cuesta en correo reenviado.

Casi ninguna organización monta su propio servidor de correo. Pagan a Microsoft, y Exchange Online hace el trabajo. Así que este post somete a Microsoft 365 exactamente a las reglas de la casa que cumplieron los montajes de Postfix y Stalwart, sin usar nada más que la propia documentación de Microsoft y DNS de solo lectura contra inquilinos reales. Algunas reglas las cumple bien: DANE y MTA-STS salientes vienen activos por defecto, y el DANE entrante con DNSSEC por fin pasó a disponibilidad general. Varias no las puede cumplir en absoluto. No hay forma documentada de exigir TLS entrante a cada remitente, ni de rechazar un fallo rotundo de SPF en la puerta, nada que rechace por una firma DKIM fallida por sí sola, y ningún control que descarte el correo de un dominio de remitente que no existe. DNSSEC no está previsto para el host de correo que de verdad usa cada inquilino. El despliegue de IPv6 que debía tardar seis meses ha dejado el propio buzón del NCSC inalcanzable por IPv6 dos años después. Y la documentación se contradice sobre comodines, sobre SPF y sobre DNSSEC. Esta es la plataforma sobre la que corre casi todo el correo del país, y esto es lo que te deja hacer y lo que no.

Stalwart es un servidor de correo entero en un binario: SMTP e IMAP y JMAP, SPF, DKIM, DMARC, ARC, DANE, MTA-STS, el informe de TLS, un filtro antispam y el almacén de correo, sin ningún milter que conectar ni demonio de políticas que ejecutar al lado. Este post lo somete a las mismas reglas de la casa que el montaje con Postfix y captura cada respuesta en el laboratorio. Las reglas se activan todas, pero la historia está en el detalle: los ajustes viven en una base de datos en vez de en un archivo, los valores por defecto de fábrica aceptan texto plano y una factura manipulada, cada regla cae en uno distinto de cuatro mecanismos de configuración, el rechazo por fallo de DKIM necesita un script Sieve porque la comprobación integrada informa de un cuerpo manipulado como neutral, la comprobación de remitente desconocido solo se ejecuta tras entrar el mensaje entero y falla-abierto ante un error de DNS, y el emisor MTA-STS rebota al primer intento donde el estándar dice que debería aplazar. Integrado es, de verdad, menos cosas que ensamblar. No es lo mismo que seguro por defecto.