MTA-STS y TLS-RPT explicados brevemente
MTA-STS y TLS-RPT son dos configuraciones para su dominio relacionadas con el cifrado del correo que le llega. Las encontrará en pruebas como internet.nl o en un informe de un escaneo de seguridad. En este artículo descubrirá qué hacen, qué aspecto tienen y si las necesita. Respuesta corta por adelantado: para la mayoría de los clientes no es necesario.
¿Qué problema soluciona?
Cuando un servidor de correo entrega correo al servidor de correo del destinatario, cifran la conexión si es posible (STARTTLS). Si no es posible, el correo suele enviarse sin cifrar. Además, el certificado del servidor receptor a menudo no se comprueba de forma estricta. Alguien que pueda manipular el tráfico por el camino puede así desactivar el cifrado o redirigir el correo a su propio servidor.
Con MTA-STS, usted indica como destinatario que el correo dirigido a su dominio debe cifrarse siempre, y solo puede entregarse a estos servidores de correo con un certificado válido. Un remitente que admita MTA-STS respetará esto.
Los dos componentes de MTA-STS
1. Un registro TXT en el nombre _mta-sts, que indica que existe una política:
_mta-sts.sudominio.nl. TXT "v=STSv1; id=20261108T120000;"
El id es un número de versión que usted mismo elige. Si modifica la política, cambie también el id, para que los remitentes obtengan la nueva política.
2. Un archivo de política ubicado exactamente en esta dirección, a través de https con un certificado válido:
https://mta-sts.sudominio.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Línea | Significado |
|---|---|
mode: testing | Los remitentes entregan el correo como siempre, pero notifican los problemas mediante TLS-RPT. Con esto se empieza. |
mode: enforce | Los remitentes solo entregan el correo mediante una conexión cifrada con un certificado válido, a uno de los servidores de correo mencionados. Si no es posible, el correo permanece en la cola del remitente. |
mode: none | No hay política (ya no). |
mx: | El nombre de su servidor de correo, exactamente como aparece en su registro MX. Si tiene varios registros MX, coloque cada nombre en una línea propia. En un paquete de WebOké, suele ser el nombre del servidor de su paquete, como en el ejemplo; el certificado de nuestro servidor de correo figura en ese nombre. Si su MX apunta a su propio nombre de dominio, es posible que el certificado no coincida y no debería usar enforce. |
max_age: | Cuánto tiempo puede un remitente recordar la política, en segundos. 604800 es una semana. |
Un remitente recuerda la política. Por ello, MTA-STS no protege la primerísima vez que un remitente le envía correo, pero sí lo hace después.
TLS-RPT: informes sobre el cifrado
Con TLS-RPT solicita a los remitentes un informe diario sobre fallos de cifrado, por ejemplo debido a un certificado caducado o a un nombre de servidor de correo que no figura en su política. Es un único registro TXT en el nombre _smtp._tls:
_smtp._tls.sudominio.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@sudominio.nl"
Los informes son archivos técnicos (JSON). Al igual que con los informes DMARC, utilice un buzón de correo independiente para ellos. Consulte Leer un informe DMARC.
El orden es: primero TLS-RPT, después MTA-STS en modo testing, unas semanas leyendo informes, y solo entonces enforce.
¿MTA-STS o DANE?
DANE hace lo mismo de otra manera: la huella digital del certificado de su servidor de correo se encuentra en el DNS (un registro TLSA), protegida con DNSSEC. DANE también protege la primera conexión, pero solo funciona si DNSSEC está activado. MTA-STS no necesita DNSSEC, pero sí un sitio web con un certificado. Puede utilizar ambos a la vez; un remitente que admita DANE dará entonces prioridad a DANE.
Si su correo está alojado en WebOké, puede activar DANE en Mi WebOké en el mismo lugar que DNSSEC. WebOké se encargará después de mantener los registros TLSA por usted. Lea DNSSEC y DANE y Lista de comprobación de Internet.nl: alcanzar el 100% con su sitio web y correo electrónico.
¿Lo necesita?
Para la mayoría de los clientes no. Hoy en día, el correo entre grandes servidores de correo casi siempre se cifra, y si desea proteger aún más su correo en WebOké, DANE es el paso más sencillo. MTA-STS resulta útil sobre todo si su organización lo exige, o si espera destinatarios que utilicen MTA-STS pero no DANE. Para su propio correo saliente no necesita configurar nada: eso lo determina el servidor que envía su correo.
Configurarlo usted mismo en un paquete de alojamiento
Los dos registros TXT se configuran en Gestión DNS en DirectAdmin o en la pestaña DNS de Mi WebOké. Consulte Gestionar registros DNS en Mi WebOké (con ejemplos para CNAME, TXT y servicios externos).
El archivo de política debe ubicarse en el subdominio mta-sts. En su paquete, puede crear ese subdominio en Gestión de subdominios; DirectAdmin solicitará entonces automáticamente un certificado SSL para él. Consulte Crear y eliminar subdominios y Certificado para www, subdominios y comodín. En la carpeta del subdominio, cree una carpeta .well-known que contenga el archivo mta-sts.txt.
enforce sin más. Si un nombre de servidor de correo es incorrecto, o si el certificado del servidor de correo no coincide con ese nombre, dejará de recibir correo de los remitentes que siguen MTA-STS. Además, el archivo de política debe poder abrirse directamente: los remitentes no siguen redirecciones a otra dirección. Empiece con testing, lea los informes de TLS-RPT y, en caso de duda, póngase primero en contacto con nosotros.Referencias: RFC 8461 (MTA-STS) y RFC 8460 (TLS-RPT).