Resumen

  • El id del TXT es un aviso de recaptura. No contiene ni firma la política, no acredita que todos los emisores la hayan obtenido y no revoca cada caché aún vigente. Para un MTA concreto, la regla con autoridad es un cuerpo autenticado por HTTPS, unido a una hora de captura y a un vencimiento local por max_age.
  • Una decisión reproducible enlaza descubrimiento DNS, certificado del host de política, bytes y linaje de caché, recorrido MX, STARTTLS, certificado receptor, cola, reintento y disposición final. enforce controla un salto SMTP; no prueba entrega, secreto extremo a extremo, identidad humana ni permiso empresarial.

Dos emisores pueden discrepar correctamente

La escena inicial es una prueba construida, no un incidente. A observa el ID nuevo, autentica mta-sts.<dominio>, obtiene el cuerpo actualizado e inicia otra vida de caché. El respaldo aparece entre sus MX permitidos.

B no logra refrescar. Si conserva una política válida y no caducada, RFC 8461 exige aplicarla aunque fallen el DNS o HTTPS en vivo. El MX nuevo no figura en ese estado antiguo; B lo descarta temporalmente y difiere el mensaje. Si no existiera una caché válida, el mismo fallo de captura haría que el emisor actuase como si el dominio no hubiera desplegado MTA-STS.

La página actual del receptor no reconstruye ninguna de esas decisiones. La pregunta útil es qué bytes autenticados podía aplicar cada emisor en el momento del intento.

El ID anuncia un cambio; no es la política

MTA-STS separa el descubrimiento del contenido. El TXT _mta-sts.<dominio-de-política> ofrece versión e identificador de instancia. IANA registra los nombres, lo que unifica semántica sin certificar el registro ni la adopción de un producto.

El ID no es el hash del archivo y no vincula mode, mx o max_age. Tampoco prueba que el cuerpo nuevo estuviera desplegado antes del cambio DNS, que todas las vistas autoritativas respondieran igual, que todos los nodos HTTPS entregaran los mismos bytes o que todos los emisores terminaran la descarga.

El orden produce consecuencias. Cambiar el cuerpo sin cambiar el ID deja legítimamente a muchos emisores con la caché anterior. Cambiar primero el ID permite que algunos vuelvan a capturar el cuerpo viejo y le asignen otra vida completa. Un panel que sólo conserva el TXT más reciente registra intención, no realidad ejecutada.

HTTPS autentica un cuerpo determinado

El archivo vive en el host de política mta-sts.<dominio>, en la ruta fija /.well-known/mta-sts.txt. El emisor valida el certificado del host de política: vigencia, cadena hacia una raíz que él confía e identidad DNS correspondiente. El SNI de esa conexión lleva el host de política, no el MX posterior.

El cuerpo contiene versión, modo, max_age y, salvo none, al menos una entrada mx. La prueba debe guardar respuesta y hash, Content-Type, hora, cadena, resultado de nombre, época del almacén de confianza, valores analizados y vencimiento. Un indicador de “configurado” no conserva la regla aplicada.

Existe un límite en el primer contacto. Si el TXT aparece pero HTTPS falla y no hay caché, el emisor sigue como si no hubiera MTA-STS. La resistencia a bloquear actualizaciones nace después de una captura autenticada; el protocolo no convierte la ausencia en DNS sin firma en una inexistencia autenticada.

max_age crea varios presentes válidos

La vida empieza en la captura exitosa de cada emisor, no en un reloj global. Resolver regional, acceso HTTPS, reinicio, réplica y actualización anticipada producen vencimientos distintos para el mismo cuerpo.

Esa dispersión mantiene continuidad y prolonga errores. Borrar la caché ante un fallo de actualización permitiría desactivar enforce bloqueando el host de política. Una política errónea de larga duración puede seguir mandando después de que el receptor arregle lo que ve públicamente.

La retirada limpia publica mode: none con vida corta, cambia el ID y espera todas las vidas antiguas superpuestas antes de quitar TXT y HTTPS. El borrado directo no revoca; puede dejar políticas enforce activas y eliminar la vía que permitiría liberarlas.

El objeto permitido es un MX en una conexión

El MTA recorre los candidatos en el orden SMTP ordinario. El nombre debe coincidir con un patrón mx de la política aplicada. El comodín sólo ocupa la etiqueta izquierda completa; no cubre el apex ni dos niveles.

Después, el servidor ofrece STARTTLS y un certificado PKIX vigente, encadenado a una raíz de confianza del emisor y válido para el nombre MX que también viaja en SNI. El éxito acredita un siguiente salto autenticado para ese intento. No autentica al autor visible, al usuario del buzón o al contenido.

Un candidato inválido se trata como temporalmente inaccesible y continúa el recorrido normal. Un respaldo omitido puede no verse hasta la caída del primario. Una prueba verde sólo contra el principal no acredita failover.

La cola da consecuencias a la política

enforce impide entregar a un candidato que falle nombre, STARTTLS o certificado, pero no habilita un rebote final inmediato. Antes del fallo permanente, el emisor debe comprobar en DNS si existe un ID actualizado; mientras tanto se aplican los fallos transitorios y reintentos de SMTP.

El aplazamiento conserva tiempo de reparación. El fallo permanente cierra la transacción. Por eso se guardan ID de cola, hash y vencimiento aplicados, secuencia de candidatos, fallo exacto, próximo intento, comprobación final de ID y disposición. Un registro TLS sin transición de cola no explica el destino del mensaje.

TLSRPT es testimonio agregado

RFC 8460 permite reportar políticas detectadas, volúmenes y clases de fallo. Las interfaces actuales de Microsoft y Google muestran consumidores reales de validación y reportes.

La cobertura depende de quién implementa y entrega el reporte. Un agregado diario no es acuse de recibo de un mensaje. No acredita lectura, conservación, secreto en todos los intermediarios o tratamiento comercial.

La auditoría reconcilia tres superficies: publicación del receptor, estado ejecutado por el emisor y observación del reportero. Ninguna debe convertirse por comodidad en la única verdad.

DANE y REQUIRETLS delimitan otras decisiones

SMTP DANE usa DNSSEC y TLSA para otra ruta autenticada. Un fallo DANE no puede ser sobrescrito por un éxito MTA-STS. PKIX no sirve de salida para degradar una validación más fuerte.

REQUIRETLS expresa intención del originador por mensaje y viaja por relés compatibles. MTA-STS es política del dominio receptor aplicada por emisores compatibles; no expresa sensibilidad individual. Ninguno crea cifrado de contenido extremo a extremo sólo porque los saltos SMTP usen TLS.

“MTA-STS pasó” no equivale a “el remitente exigió secreto”, “el receptor aceptó”, “el usuario recibió” ni “la operación está autorizada”. La prueba termina donde termina el control.

Una decisión que pueda repetirse

La unidad de evidencia se indexa por dominio, emisor, intento y hora. Une bytes TXT, ID, TTL y DNSSEC; respuesta HTTPS y certificado; hash, modo, MX, captura y vencimiento; RRset y orden MX; SNI, STARTTLS y certificado SMTP; DANE; cola, actualización y último control ID; TLSRPT y disposición.

Los canarios cambian cuerpo sin ID, adelantan ID al cuerpo, bloquean HTTPS con y sin caché, dejan caducar, fuerzan el respaldo, presentan certificados incorrectos, publican none e intentan usar MTA-STS después de un fallo DANE.

La norma fija un lenguaje mínimo; el receptor propone; PKIX autentica un cuerpo; cada emisor le da vida local; el SMTP real lo prueba; la cola crea el efecto. La cadena DNS más nueva no posee una autoridad mayor.

Fuentes