Resumen

  • El TURN opcional de RFC 821 invertía los papeles de cliente y servidor en el canal SMTP abierto. Ayudaba a los sitios intermitentes, pero permitía que un nombre no autenticado controlara el destino del correo guardado.
  • RFC 1985 redujo la concesión con ETRN: el cliente pide activar una cola; el servidor conserva la autorización local, abre otra conexión saliente y responde antes de conocer la entrega.

Una conexión escasa tenía que servir en ambos sentidos

Un sitio pequeño no siempre podía mantener una ruta entrante. Al marcar a su proveedor quería depositar correo y aprovechar la misma ventana para recibir lo acumulado durante la desconexión. Esperar el reintento ordinario podía perder ese intervalo de alcance.

RFC 821 ofreció TURN. Si el proveedor contestaba 250, el emisor SMTP se convertía en receptor y el receptor en emisor sobre el mismo canal. El primero enviaba un nuevo saludo de servicio y esperaba la cola. El servidor podía negarse con 502; la función era opcional.

Se reutilizaba el enlace, pero también se daba por reutilizada una confianza que nunca se había establecido.

Decir un nombre en HELO no probaba la custodia

El servidor debía decidir qué mensajes entregar al nuevo receptor. El SMTP temprano no autenticaba el nombre pronunciado por el par. Un sistema hostil podía usar el nombre de otro sitio, pedir TURN y obtener su correo pendiente.

No era sólo una cabecera falsa: la custodia de mensajes enteros podía cambiar. RFC 1985 llamó al defecto una gran brecha de seguridad y explicó que muchas implementaciones evitaron TURN porque no existía una comprobación estipulada del nombre remoto.

La transición era demasiado grande. Una afirmación controlaba identidad supuesta, intercambio de papeles, dirección del canal y destino de la cola mediante un solo 250.

ETRN solicitó trabajo sin recibirlo

RFC 1985 mantuvo la necesidad y redujo el poder. El servidor anuncia ETRN tras EHLO; el cliente nombra un nodo y pide iniciar su cola. La orden puede emitirse durante una sesión, pero no dentro de una transacción entre MAIL FROM y el cierre de DATA.

El servidor examina el alcance y decide localmente si lo admite. Al aceptarlo, activa sus reintentos y usa otra conexión SMTP hacia el sitio nombrado. El solicitante conserva su papel en el canal de control. Conocer el nombre no le entrega un solo sobre.

La nueva conexión no autentica mágicamente una organización. Crea otra frontera de evidencia: DNS, ruta, conexión y transacción receptora determinan adónde llega cada intento y si se acepta, con independencia del nombre afirmado en el disparo.

Un disparo aceptado no era un recibo

Procesar una cola puede tardar un tiempo indeterminado. RFC 1985 no exige que se abra una conexión ni fija cuándo debe ocurrir. Por eso ETRN responde de inmediato.

El 250 común indica que la solicitud fue satisfactoria y comenzó el procesamiento. No demuestra que hubiera mensajes, que el enlace saliente funcionara ni que un destinatario aceptara nada. Los códigos opcionales 251, 252 y 253 exponen más información de la cola, pero siguen siendo informes locales, no evidencia de entrega extremo a extremo.

Registrar 250 como «entregado» elimina una incertidumbre necesaria. Aceptar el disparo, intentar conexión, transferir un mensaje y completar la entrega son hechos distintos.

El servidor conservó el significado de la cola

El parámetro normal es un nombre completo. @dominio puede activar el dominio y sus subdominios; #nombre puede seleccionar una cola local, como una de UUCP.

Esas abreviaturas amplían el alcance. @com podría desatar una carga enorme y congestión. Los nombres # no pertenecen a un diccionario global y el cliente no puede enumerarlos mediante el protocolo. Cada servidor debe autorizar combinaciones sensatas de solicitante y alcance.

IANA coordina la palabra ETRN; no concede acceso a colas.

La obsolescencia redujo el presupuesto de confianza

RFC 2821 dejó TURN obsoleto y RFC 5321 mantuvo el límite: no usarlo salvo que el servidor pueda autenticar fuertemente al cliente que exige el intercambio. Cifrar no basta; la identidad autenticada debe estar autorizada a recibir esos mensajes concretos.

RFC 5321 añadió una optimización aún menor. Recibir correo desde un host puede servir como señal local para adelantar los reintentos hacia ese host. Cambia el calendario sin entregar la cola a quien dio la señal.

El registro IANA actual conserva TURN y ETRN, pero marca ambos como inadecuados para el servicio de envío. Autenticarse como usuario en el puerto 587 no concede el derecho a activar colas de entrega SMTP.

La evolución no negó las conexiones intermitentes. Dividió el poder: el cliente propone trabajo, el servidor autoriza y programa, y otra conexión prueba la entrega. Ninguna etapa se presenta como prueba de las demás.

Fuentes