Resumen

  • STARTTLS aseguraba una conexión, pero el correo permanecía en colas y pasaba por nuevas conexiones con políticas distintas. RFC 8689 hizo que una exigencia de TLS autenticado acompañara al mensaje y se repitiera en cada relevo compatible.
  • Si todos los MX fallan la validación o no anuncian REQUIRETLS después de STARTTLS, el emisor debe abstenerse de transmitir y generar una notificación de no entrega. No es cifrado de extremo a extremo: cada MTA sigue viendo el contenido.

Una cola de correo no elige una ruta una sola vez. Consulta los MX del dominio, prueba el de menor preferencia numérica, espera o avanza al siguiente cuando algo falla. Esa capacidad de rodear averías es una de las razones por las que SMTP entrega incluso en redes imperfectas.

Ahora entra una carta con una condición: no debe cruzar ningún relevo compatible si el siguiente servidor no puede demostrar identidad, cifrado y continuidad de la regla. La lista de MX sigue siendo útil, pero ya no es una escalera hacia cualquier entrega posible. Se convierte en una búsqueda de un camino autorizado.

Antes de REQUIRETLS, la decisión de usar cifrado tendía a pertenecer a la conexión o a la política del dominio. Una vez aceptado el mensaje y cerrada la sesión, la intención del remitente podía desaparecer. RFC 8689 hizo que el criterio durara tanto como el objeto en la cola.

STARTTLS resolvió el cambio de canal, no la memoria del mensaje

El RFC 2487 añadió STARTTLS en 1999. El correo público tenía un conflicto particular: exigir de golpe la nueva capacidad a todos los MX habría roto la interoperabilidad. El diseño dejó que los servidores siguieran privilegiando la entrega cuando la protección no estaba disponible.

En 2002, el RFC 3207 sustituyó aquella especificación. El servidor anuncia STARTTLS en EHLO, el cliente lo solicita y la respuesta 220 abre la negociación TLS. Después, ambos olvidan lo aprendido en claro y el cliente presenta un segundo EHLO dentro de TLS. Así, una declaración manipulable anterior no manda sobre la fase protegida.

Esa limpieza crea confianza entre dos pares en un momento concreto. SMTP, sin embargo, es almacenamiento y reenvío. El receptor guarda el mensaje, puede cerrar la conexión y horas después convertirse en cliente de otro MTA. El segundo enlace no hereda mágicamente la decisión tomada en el primero.

El lado receptor obtuvo políticas más duraderas. El RFC 7672 usa DNSSEC y TLSA para DANE en SMTP. El RFC 8461 define MTA-STS, una política obtenida por HTTPS y almacenada en caché que identifica MX aceptables y exige validación del certificado. Ambas expresan autoridad del dominio de destino. No permiten por sí solas que el originador distinga una carta de las demás.

La orden viajó en MAIL FROM

El RFC 8689, publicado en 2019, registró REQUIRETLS como capacidad EHLO. No creó un verbo nuevo. Añadió un parámetro sin valor a la orden que abre la envoltura:

MAIL FROM:<sender@example> REQUIRETLS

No basta con ver la palabra en el primer EHLO. El cliente debe usar TLS, verificar que el MX pertenece al destino mediante DNSSEC o MTA-STS, validar el certificado por una cadena aceptada o DANE y comprobar que REQUIRETLS aparece en el segundo EHLO, ya protegido.

Cuando el servidor acepta la envoltura, marca internamente el mensaje. El estándar no decide si la marca vive en una base de datos, un archivo o memoria. Decide su efecto: al volver a enviar, el MTA debe reconstruir el canal seguro y repetir el parámetro.

Los alias locales no pueden diluir la decisión. Si una dirección se expande en varias, todas las instancias reciben la misma marca. La condición no pertenece a la conexión inicial ni a un destinatario elegido al azar; pertenece al tratamiento de la carta.

Cifrado, identidad, ruta y continuidad eran pruebas distintas

Un indicador “TLS activo” no demuestra la cadena completa. El MTA sigue las reglas de RFC 5321 para localizar el siguiente servidor. Si la respuesta MX no viene autenticada por DNSSEC, consulta MTA-STS para limitar los nombres válidos. Negocia TLS y valida la identidad del certificado. Después exige REQUIRETLS dentro del EHLO protegido.

El cifrado evita que un observador pasivo lea el enlace. La validación de certificado o DANE ata la clave a un servidor. DNSSEC o MTA-STS impide que cualquier nombre con un certificado válido se haga pasar por el MX. La última publicidad indica que el próximo guardián conservará la obligación al poner la carta en su propia cola.

Omitir una prueba cambia el significado. Se puede cifrar hacia un atacante. Se puede autenticar el MX correcto que no sabe propagar la marca. Se puede ver una capacidad en claro que desaparece tras STARTTLS. REQUIRETLS trató esas diferencias como decisiones, no como detalles de registro.

La lista de MX no terminaba en una degradación

Si el primer servidor no cumple, el cliente emite QUIT y prueba otro MX. Puede entregar mensajes sin marca al servidor rechazado antes de salir. Dos correos para el mismo dominio pueden así seguir resultados distintos sin convertir un problema parcial en prohibición total.

Cuando se agota la lista, la carta marcada no se transmite al dominio. El RFC recomienda el código mejorado 5.7.30 cuando falta soporte REQUIRETLS y 5.7.10 cuando no se puede establecer la sesión cifrada necesaria. Entonces se produce una notificación de no entrega para la ruta de retorno.

Aquí aparece el giro central. En un esquema oportunista, el fracaso de seguridad podía abrir una opción menos segura para conservar la entrega. Con REQUIRETLS, ese fracaso elimina la autorización para mandar. El protocolo considera que un fallo explicado respeta mejor la intención que una llegada conseguida con condiciones nuevas.

No es una decisión gratuita. Un certificado caducado o un MX secundario sin actualizar puede detener correo que técnicamente podría alcanzar el buzón. La extensión no esconde la tensión entre disponibilidad y confidencialidad; permite que el originador la resuelva por mensaje.

La devolución también transportaba información sensible

Una notificación de no entrega suele copiar cabeceras del original. Puede revelar asunto, direcciones y parte del trayecto. Si el envío principal exige protección pero el diagnóstico vuelve en claro, la cadena filtra por el camino de regreso.

Por eso, cualquier aviso de no entrega producido por un mensaje REQUIRETLS debe usar REQUIRETLS, aunque la causa del fallo no sea TLS. Además se comporta como si DSN RET=HDRS estuviera presente; una petición RET=FULL se ignora para no devolver el cuerpo completo.

La ruta de retorno del aviso está vacía, regla que evita bucles infinitos de errores. El camino de vuelta puede tener capacidades diferentes del de ida. RFC 8689 advierte que el diagnóstico seguro puede perderse y flexibiliza el tratamiento del mensaje con retorno vacío cuando el próximo salto no anuncia REQUIRETLS.

La falta de aviso no acredita entrega. Puede ser el segundo fallo: el mensaje original se retuvo, pero la evidencia no encontró una ruta protegida hasta el remitente.

TLS-Required: No no pedía texto claro

La especificación añadió una excepción con forma de cabecera. TLS-Required: No pide que el MTA no deje que la política DANE o MTA-STS del destinatario bloquee el correo. Sirve, por ejemplo, para avisar de un certificado roto sin que ese mismo certificado impida el aviso.

El cliente todavía debe intentar STARTTLS si está disponible. No cambia la consecuencia del fallo, no la primera preferencia. Y el servidor receptor puede rechazar sesiones no cifradas según su propia política; el emisor no obtiene poder para obligarlo.

Si la envoltura ya lleva REQUIRETLS, esa señal gana y la cabecera se ignora para el tratamiento. Sólo puede existir una instancia de la cabecera. Un dato dentro del contenido no puede rebajar la obligación acordada en un canal protegido.

Los mediadores podían crear una carta nueva

Un relevo conserva el objeto. Una lista de correo, un filtro Sieve, un reenviador o una respuesta automática puede originar otro mensaje. Cambian destinatarios, cabeceras y responsabilidad. El RFC pide trasladar la elección REQUIRETLS en la medida viable.

La frase reconoce límites. Una lista con muchos dominios quizá no pueda llegar a todos si mantiene la condición. Un filtro del usuario puede no conocer la marca SMTP. La cuestión deja de ser sólo técnica: ¿sigue actuando el sistema como transportista o se ha convertido en un nuevo originador?

REQUIRETLS no elimina esa frontera institucional. Hace visible el punto en el que la continuidad automática termina y alguien debe decidir si la nueva carta hereda la obligación.

Los MTA seguían viendo el contenido

El mecanismo protege cada enlace, no el contenido de extremo a extremo. Un MTA termina TLS, procesa texto claro y abre otra sesión. Un relevo malicioso puede anunciar soporte y borrar la marca. RFC 8689 lo deja fuera de su modelo de amenaza porque ya fue confiado con el mensaje.

La extensión reduce escucha pasiva, eliminación de STARTTLS, sustitución de MX y degradación accidental entre implementaciones honestas. No autentica al autor, no cifra la cola en reposo, no oculta la carta a los servidores de relevo y no demuestra saltos futuros.

El registro SMTP de IANA prueba que REQUIRETLS tiene nombre y referencia normalizados. No prueba adopción, volumen ni cumplimiento actual.

El legado es una forma de memoria. Las conexiones desaparecen; la carta permanece. Para que la preferencia del remitente sobreviva, debe guardarse, verificarse y emitirse de nuevo. REQUIRETLS dio a SMTP una manera de decir que no toda llegada es éxito y que, para una carta concreta, detenerse puede ser el único final autorizado.