Resumen

  • RFC 1440 propuso que un emisor sin cuenta en el host receptor enviara un archivo no tratado como correspondencia.
  • El servidor podía aceptar comandos y terminar la recepción, mientras el objeto seguía en una zona compartida a la espera de la decisión del destinatario.
  • El protocolo no implementó autenticación; tampoco convirtió el nombre de un usuario o servicio en autorización para abrir o ejecutar el contenido.

Un envío que no esperaba una petición

FTP organizaba la transferencia alrededor de un usuario que abría el control y pedía una operación. SIFT/UFT probó otra dirección. “Unsolicited” no quería decir indeseado: significaba que el receptor no había iniciado la transacción. El remitente tampoco necesitaba una cuenta o un registro previo en el sistema de destino.

La referencia cultural era NJE y BITNET, donde era posible mandar un archivo fuera del correo. La RFC lo comparaba con un paquete, no con una carta. Así se podía diferir la recogida y mantener el objeto fuera del agente de usuario de correo.

Lo que parecía una reducción de pasos era, en realidad, una redistribución. El emisor ganaba una operación breve. El receptor debía mantener un demonio, decidir a quién reconocía, reservar almacenamiento, conservar objetos pendientes y eliminarlos cuando nadie actuara.

Control y cuerpo compartían el socket

El servicio escuchaba TCP 608. Por una sola conexión circulaban líneas de mando ASCII y ráfagas de datos binarios. El flujo completo podía verse como la unión de dos archivos: uno de control y otro con el cuerpo.

FILE declaraba tamaño y emisor; USER indicaba el destinatario; TYPE fijaba la representación. Los tres eran obligatorios antes de DATA. NAME y DATE podían describir el objeto. EOF lo cerraba, ABORT pedía descartar una copia parcial y QUIT acababa la sesión.

El servidor podía guardar control y datos por separado para no interpretar formatos ajenos dentro del listener. Esa decisión limitaba trabajo inmediato, pero obligaba a mantener su relación. Perderla dejaba bytes sin destinatario o instrucciones sin cuerpo.

Cada ACK tenía un único antecedente

La confirmación positiva era mínima: un paquete cuya primera posición contenía un octeto nulo. Ese NULL ACK aceptaba un comando. No certificaba todos los comandos anteriores ni el destino final del archivo.

El tamaño de FILE servía para preguntar si había espacio, pero podía ser aproximado. Por eso, aceptar FILE no reservaba necesariamente cada byte futuro. El host aún podía descubrir que USER no existía, que la escritura fallaba o que el cuerpo excedía su estimación. Una fila de respuestas positivas no era una promesa indivisible.

Al conectar, el servidor enviaba un saludo con host, nivel de UFT y versión de implementación. Permitía sincronizar y negociar el nivel entendido. No demostraba criptográficamente la identidad del host. El token auth de FILE estaba sin implementar y la especificación admitía que la autenticación no estaba asegurada.

El archivo esperaba en tierra de nadie administrada

La RFC proponía una zona compartida como /usr/spool/uft. Allí permanecía el objeto hasta que el destinatario lo aceptara o rechazara, o hasta que el sistema lo borrara por antigüedad. Compartida no significaba abierta a cualquiera. Los límites de tamaño y permanencia eran decisiones locales.

La recepción de red, la custodia del host y la aceptación del usuario eran tres eventos. Podían tener minutos o días de separación. También podían acabar de modo distinto: transferencia completa, custodia temporal y expiración sin intervención.

Por eso, la desaparición del spool no prueba consumo. Puede significar rechazo, caducidad, cuarentena, limpieza o error. Y la presencia tampoco prueba aceptación: solo demuestra que el host conserva una copia en un momento concreto.

El texto recomendaba procesar lo mínimo hasta que el destinatario actuara. Un tipo desconocido debía preservarse como binario. Esa prudencia protegía la forma recibida, no afirmaba que el contenido fuera íntegro frente a un atacante, seguro o útil.

El tamaño de la ráfaga era también un punto de gobierno

DATA podía incluir el número de octetos de la siguiente ráfaga. El receptor leía esa cantidad y regresaba al modo de comandos. Un archivo podía componerse de muchas ráfagas y una conexión transportar varios archivos. Entre ráfagas volvía a existir una oportunidad clara de acusar, abortar o continuar.

El modo rápido omitía el tamaño. Entonces el flujo terminaba cuando el cliente cerraba TCP. No aparecían EOF ni QUIT, y no se podía enviar ABORT durante la lectura. La conexión era el delimitador.

Ahorrar intercambios eliminaba controles. Una desconexión voluntaria y una rotura inesperada tenían la misma forma exterior. Para saber si el objeto estaba completo hacían falta bytes esperados, bytes escritos, huella y causa de cierre; el estado del socket por sí solo no bastaba.

Un pseudo-usuario podía ser una máquina

USER podía apuntar a un motor de servicio o a una cola de trabajos. Así, el archivo no quedaba necesariamente esperando a una persona; podía alimentar automatización.

Pero reconocer el nombre local no autorizaba esa consecuencia. Identidad del emisor, permiso para usar el servicio, validación del formato, cuota, cuarentena, ejecución y resultado seguían siendo decisiones independientes. Una entrada de spool no era un permiso de ejecución.

La omisión de seguridad era expresa. El documento no discutía esos problemas y posponía la autenticación a desarrollos ajenos. Eliminar la cuenta del emisor reducía fricción, pero también retiraba un control sin reemplazarlo por una confianza completa.

MIME ofrecía otra carretera

Un firewall podía admitir correo y negar un nuevo puerto; otros hosts carecían de IP directo o no querían otro servidor. RFC 1440 permitía encapsular UFT en MIME. Los comandos pasaban a parámetros de application/octet-stream y el cuerpo viajaba codificado en Base64.

Ese camino preservaba una representación a través del correo, pero sustituía la conversación directa por estados de almacenamiento y reenvío. La evidencia ya no era saludo, comandos y ACK en TCP. La autenticación, si existía, pertenecía al sistema de correo. La aceptación final continuaba siendo local.

El experimento no se convirtió por publicación en práctica universal. RFC 1499 siguió llamándolo Experimental. El registro IANA conserva sift-uft y el puerto 608, lo que demuestra un asiento administrativo, no una instalación activa.

La palabra entrega necesitaba apellidos

RFC 1440 dejó una secuencia verificable: el emisor inicia; el listener admite; el host recibe; el spool custodia; el destinatario acepta o rechaza; quizá una aplicación actúa. Saltar de cualquier peldaño al último produce una afirmación sin dueño.

Un registro útil conserva par y saludo, cada comando con su respuesta, tamaño declarado y real, tipo, huella, finalización, ubicación temporal, vencimiento, decisión y resultado posterior. Solo así puede decir qué llegó, dónde quedó y quién hizo real la siguiente acción.

Fuentes