Entrevista de Backend: ¿Cómo diagnosticarías fallos de TLS en SMTP con TLS-RPT?

Pregunta y escenario

Administras un dominio receptor con múltiples registros MX distribuidos en varios proveedores. Tras habilitar MTA-STS, algunos remitentes reportan fallos en el handshake de TLS. Explica cómo utilizarías SMTP TLS Reporting (TLS-RPT) para observar, diagnosticar e implementar la corrección de forma segura.

Qué está evaluando el entrevistador

• Distinguir la telemetría (TLS-RPT) de la aplicación de políticas (MTA-STS y DANE).
• Conectar DNS, certificados, STARTTLS, archivos de directivas HTTPS y rutas de MX de respaldo.
• Utilizar despliegues graduales, métricas, alertas y reversión (rollback) para proteger la entregabilidad.

Preguntas de clarificación antes de responder

Confirma el conjunto de MX del dominio, si MTA-STS o DANE está habilitado, el destino de TLS-RPT, la ventana de reporte y si los fallos son globales o se concentran en un remitente o MX de respaldo específico. Aclara si el objetivo es detectar degradaciones a texto plano, explicar fallos de entrega o validar un despliegue de políticas de cumplimiento.

Estructura de respuesta de 30 segundos

TLS-RPT, definido por el RFC 8460, es telemetría; no impone el cifrado. Publicaría un registro TXT _smtp._tls, recopilaría reportes agregados y agruparía los fallos por directiva, remitente, MX y motivo. Luego validaría STARTTLS, la identidad y cadena del certificado, el DNS y el archivo HTTPS de MTA-STS para cada MX. Tras corregir los problemas, observaría en modo testing antes de aplicar la exigencia (enforce) y mantendría una ruta de reversión probada.

Respuesta detallada paso a paso

1. Publicar un registro como v=TLSRPTv1; rua=mailto:tls-reports@example.org; autorizar el destino y verificar el parseo, la retención y la ofuscación de datos.
2. Parsear los agregados JSON de RFC 8460 para obtener la directiva, el MTA remitente, el MX, los éxitos y los motivos de fallo. Agrupar por tiempo, proveedor y MX de respaldo en lugar de depender de una única cifra de tasa de fallos.
3. Para cada MX, verificar DNS, puerto 25, STARTTLS, la cadena de certificados y el nombre. Comparar las observaciones del remitente con los registros de correo y un sondeo explícito de TLS en SMTP.
4. Para MTA-STS, verificar _mta-sts, el archivo HTTPS /.well-known/mta-sts.txt, su modo, los patrones de MX y el almacenamiento en caché. Para DANE, verificar la validación de DNSSEC y la alineación de TLSA con el certificado.
5. Probar cada MX, registro obsoleto y ruta de conmutación por error en modo testing antes de pasar a enforce. Alertar ante un aumento en la tasa de fallos o problemas en un proveedor/ruta crítico.
6. Volver a probar con la misma matriz tras corregir certificados, archivos de directivas, DNSSEC o la configuración del proveedor. Si la entrega se interrumpe, reducir el modo de MTA-STS o eliminar la entrada de directiva errónea manteniendo la recolección de TLS-RPT.

dig TXT _smtp._tls.example.org
dig TXT _mta-sts.example.org
curl https://mta-sts.example.org/.well-known/mta-sts.txt
openssl s_client -starttls smtp -connect mx1.example.org:25 -servername mx1.example.org

Ejemplo de respuesta de alta calidad

Trato a TLS-RPT como telemetría, no como el interruptor de cifrado. Primero publico _smtp._tls y envío los reportes a un destino controlado, luego construyo una línea base por remitente, MX de destino, directiva y motivo de fallo. Para cada ruta reportada verifico STARTTLS, la cadena y el nombre del certificado, el registro TXT y la directiva HTTPS de MTA-STS, o DNSSEC/TLSA de DANE; incluyo MX de respaldo y TTLs obsoletos. Tras la remediación, permanezco en modo testing durante una ventana de reporte completa y una prueba de conmutación por error antes de pasar a enforce. Si la entrega falla, revierto el modo de la directiva mientras retengo los reportes, en lugar de aceptar texto plano silenciosamente. Esto separa la observación, la reparación y la aplicación en etapas reversibles.

Errores comunes

• Tratar TLS-RPT como exigencia de TLS en lugar de monitoreo y reporte.
• Revisar únicamente el MX principal y omitir rutas de respaldo, registros DNS obsoletos o rutas específicas de proveedores.
• Revisar la expiración del certificado pero ignorar el SAN, la cadena, TLSA o los patrones mx del archivo de directivas.
• Cambiar a enforce sin una ventana de reporte completa, umbrales y un plan de reversión.
• Interpretar la ausencia de reportes como ausencia de fallos sin confirmar la cobertura de remitentes y la autorización de los endpoints.

Preguntas de seguimiento y respuestas

¿Cuál es el límite entre TLS-RPT y MTA-STS?

TLS-RPT agrega evidencia sobre los resultados de la negociación. MTA-STS utiliza una directiva HTTPS para exigir que los remitentes validen TLS. Trabajan juntos: los reportes validan el despliegue del cumplimiento de la directiva.

Un reporte indica certificate-mismatch. ¿Qué verificas primero?

Reproducir el handshake contra el MX reportado, inspeccionar el SAN, SNI, la cadena y el DNS, y luego verificar si un balanceador de carga o un nodo de respaldo todavía está sirviendo un certificado antiguo.

¿Por qué DANE requiere especial atención a DNSSEC?

La confianza de TLSA depende de la validación de DNSSEC. La rotación de certificados debe actualizar TLSA de forma atómica; de lo contrario, los remitentes compatibles con DANE pueden rechazar la conexión y reportar el fallo.

¿Cómo se realiza una reversión tras aplicar el cumplimiento (enforce)?

Mantén el DNS y los archivos de directivas bajo control de versiones, reduce MTA-STS de enforce a testing o elimina la entrada defectuosa, confirma que la entrega y los reportes se recuperen, y luego soluciona la causa raíz mientras TLS-RPT continúa recolectando datos.