Resumen

  • El RFC 1090, de febrero de 1989, propuso abrir un circuito virtual X.25 bidireccional para cada sesión SMTP, usarlo durante el intercambio y liberarlo al final.
  • Al liberar el circuito, X.25 podía descartar paquetes todavía en tránsito. Por eso el extremo que llamaba esperaba la respuesta SMTP de cierre del servicio, normalmente tras QUIT, antes de cortar la conexión.

Una carta quedó entre dos mesas

El RFC 821 ya había considerado X.25 como transporte en 1982. Su apéndice D sugería colocar encima un protocolo fiable de extremo a extremo, como TCP. En 1989, R. Ullmann presentó en el RFC 1090 una ruta directa por el circuito virtual. Según el propio documento, el procedimiento se había usado en producción en 24 redes públicas de datos repartidas por 22 países. La cifra describe la experiencia que su autor comunicó entonces y sitúa la pequeña especificación en una sala de operaciones, con líneas reales que abrir y cerrar.

La secuencia básica cabe en una servilleta. Se abre un circuito X.25 para la sesión SMTP, se aprovecha su canal dúplex y se libera al terminar, por lo general desde el lado que hizo la llamada. Los comandos, respuestas y datos de correo conservan su gramática SMTP. El problema aparece cuando alguien confunde «ya lo envié» con «el otro extremo ya lo recibió».

RFC 1090 señalaba la peculiaridad decisiva: una solicitud de liberación X.25 no entregaba de forma síncrona los datos que seguían en camino. Los paquetes podían desaparecer. Si el emisor acababa de escribir el último octeto y cortaba el circuito, la frase final podía quedarse sin suelo. El documento ordenó al lado llamante esperar el mensaje SMTP Service Closing, habitualmente la respuesta a QUIT, y entonces liberar la línea. Hasta el sobre más ligero merece llegar al otro escritorio antes de apagar la oficina.

En un intercambio de correo hay varios momentos de confirmación. La respuesta después de los datos del mensaje corresponde a la transacción SMTP. La respuesta Service Closing cierra la sesión. La liberación X.25 acaba con el circuito. La gestión posterior del mensaje por el sistema receptor viene después. El RFC 1090 se ocupó de un borde muy preciso: conservar el camino hasta que el servicio lejano hubiera pronunciado su última respuesta. La señal para cortar llegaba del otro extremo.

La llamada también necesitaba una presentación. Los cuatro primeros octetos de Call User Data debían usarse preferentemente como identificador de protocolo: C0F70000 en hexadecimal. Al mismo tiempo, las implementaciones debían permitir configurar esos datos, incluido el identificador, por dirección de destino. Un acuerdo común podía convivir con las particularidades de cada red y de cada llamada.

Dentro del circuito, quien enviaba decidía cómo partir el flujo SMTP en paquetes. El RFC alentaba secuencias con el bit M, «hay más datos», de hasta 2.048 octetos en total. Recomendaba que cada comando o respuesta viajara en un solo paquete o en una sola secuencia para que una captura de depuración resultase legible. Era una comodidad para quien investigaba averías, no un requisito que alterara los comandos. Los paquetes de datos cualificados con bit Q y los de interrupción quedaban fuera del uso previsto y debían ignorarse. El texto viajaba en ASCII de ocho bits, con líneas terminadas en CRLF y reconocimiento de LF solo cuando fuese posible.

Los fallos del circuito tenían su propio procedimiento. Un reinicio de nivel 3 pedía liberar el circuito virtual e intentar otra conexión SMTP, quizá después de un tiempo o con otras facilidades de llamada. Esas facilidades podían configurarse para cada dirección llamada. El nuevo intento empezaba con una nueva conexión y un nuevo saludo, no con la vieja conversación mágicamente recompuesta.

Los temporizadores mostraban cuánta paciencia se consideraba razonable. El documento concedía 100 segundos a la aceptación de la llamada y otros 120 al saludo Service Ready. Una sesión establecida podía cerrarse después de diez minutos sin respuesta. Tras QUIT, el plazo bajaba a veinte segundos. Esa salida podía ser brusca, pero el RFC afirmaba que no afectaba a las transacciones SMTP ya completadas. Eran cifras de la práctica descrita por el autor: suficientes para escuchar al otro extremo y limitadas para no ocupar la línea para siempre.

La imagen de esta historia es una mano suspendida sobre el interruptor. El llamante controla el circuito, pero la última palabra pertenece al servicio remoto. SMTP pudo cruzar X.25 porque el final de la conversación se acordaba antes del final de la línea.