Résumé

  • La RFC 1440 proposait qu’un expéditeur sans compte sur l’hôte cible puisse y déposer un fichier non assimilé à du courrier.
  • Le démon pouvait accepter une commande, recevoir les octets et placer l’objet dans un spool sans que le destinataire l’ait accepté.
  • Le mode par rafales conservait des points d’arrêt ; le mode rapide gagnait des échanges mais confondait fin de fichier et fermeture de connexion.

Le dépôt n’était pas la remise en main propre

Au début des années 1990, transférer un fichier signifiait souvent que l’utilisateur du côté demandeur ouvrait une session vers le serveur et commandait une opération. SIFT/UFT inversait ce geste. « Unsolicited » ne qualifiait pas le fichier d’indésirable ; il indiquait seulement que le destinataire n’avait pas lancé la transaction.

L’idée venait notamment des réseaux NJE comme BITNET, où l’on pouvait envoyer un fichier hors de la messagerie. Le texte parlait d’un colis plutôt que d’une lettre. L’expéditeur n’avait besoin ni de compte ni d’inscription sur la machine cible. Le destinataire pouvait venir chercher l’objet plus tard.

La simplicité changeait donc de côté. Elle supprimait une étape pour l’expéditeur, mais imposait à l’hôte récepteur un service disponible, une politique d’admission, un espace temporaire, un annuaire de destinataires et une règle d’évacuation. Le protocole ne détruisait pas cette complexité : il la déposait avec le fichier.

Une connexion, deux dossiers

Le démon écoutait le port TCP 608. Dans la même connexion circulaient des commandes ASCII et des données binaires. La RFC décrivait l’ensemble comme deux fichiers concaténés : un fichier de contrôle et un corps de données.

FILE annonçait l’expéditeur, une taille exacte ou approximative et un éventuel ticket d’authentification. USER désignait un utilisateur local ou un service ; TYPE précisait la représentation. Ces trois commandes devaient précéder DATA. NAME et DATE ajoutaient du contexte. EOF clôturait un fichier, ABORT demandait de jeter un transfert partiel et QUIT terminait le travail.

Le récepteur pouvait conserver séparément les commandes et le corps. Cela évitait au processus d’écoute de comprendre chaque format étranger. En contrepartie, il fallait garder une liaison fiable entre les deux objets : quel contrôle décrivait quel corps, combien d’octets avaient été écrits et quelle décision finale s’y rapportait.

L’accusé le plus court avait la portée la plus étroite

Une réponse positive commençait par un octet nul. Ce NULL ACK validait une seule commande. Tout autre début pouvait être traité comme un refus et conduire le client à fermer la connexion.

Un tel accusé ne validait ni le fichier entier ni la décision du destinataire. FILE pouvait être accepté parce que la taille déclarée semblait tenir dans l’espace disponible, puis USER échouer faute de compte local. Les métadonnées pouvaient être reçues, puis l’écriture des données échouer. Puisque la taille pouvait être approximative, l’admission initiale restait une estimation.

Le message d’accueil du serveur annonçait un nom d’hôte, la version UFT et la version du logiciel. Il aidait à synchroniser le dialogue et à comparer les niveaux de protocole. Il n’authentifiait pas la machine. Le champ auth de FILE était un ticket non implémenté ; la RFC disait sans détour que l’authentification n’était pas assurée.

Le spool ouvrait une seconde temporalité

Après réception, le fichier demeurait dans un espace partagé, par exemple /usr/spool/uft. Il y attendait l’acceptation ou le refus du destinataire, ou bien sa suppression pour ancienneté. « Public » voulait dire commun, pas libre d’accès. La limite de taille et la durée de garde relevaient de l’administration locale.

Trois dates pouvaient ainsi diverger. La connexion se terminait à une première heure. L’hôte conservait l’objet pendant un intervalle. Le destinataire prenait sa décision plus tard, ou ne la prenait jamais. Afficher « livré » à la fermeture du socket aurait fusionné ces horloges.

Une suppression automatique n’était pas un refus exprimé par l’utilisateur. L’absence ultérieure du fichier ne prouvait pas davantage son acceptation : il pouvait avoir expiré, été placé en quarantaine ou perdu. Seul un événement de disposition explicite fermait cette incertitude.

Le document recommandait de transformer le moins possible le corps avant l’action du destinataire. Un type incompris devait être conservé comme binaire. Cette prudence protégeait la possibilité de traitement futur ; elle ne garantissait ni l’intégrité, ni l’innocuité, ni l’utilité du contenu.

Des rafales pour retrouver le contrôle

Dans le mode ordinaire, DATA portait une longueur. Le serveur lisait ce nombre d’octets, les ajoutait au fichier, puis revenait à l’interprétation des commandes. Plusieurs rafales formaient un fichier et une connexion pouvait en transporter plusieurs. Après une rafale complète, ABORT redevenait possible.

Le mode rapide supprimait la longueur. Le serveur lisait jusqu’à la fermeture de TCP ; ni EOF ni QUIT ne suivaient. La fermeture était à la fois la frontière des données et la fin de la transaction, et ABORT n’était plus utilisable pendant le flux.

Ce choix échangeait des points de reprise et de décision contre moins d’allers-retours. Il rendait aussi la preuve plus pauvre : une fermeture voulue et une rupture imprévue arrivaient par le même signal. Sans comptage, empreinte et état local, le récepteur ne pouvait pas déduire la complétude de la seule fin de connexion.

Le nom d’un service n’autorisait pas son exécution

USER pouvait viser non pas une personne, mais un moteur logiciel, par exemple une file de travaux présentée comme pseudo-utilisateur. Le fichier reçu pouvait donc devenir l’entrée d’une action automatique.

Reconnaître ce nom ne suffisait pourtant pas à autoriser le travail. Il fallait encore établir l’identité de l’expéditeur, la permission du destinataire, les limites de ressources, la validité du format, la quarantaine éventuelle, l’exécution et son résultat. La RFC ne fournissait pas cette chaîne et réservait sa section de sécurité à une absence de discussion.

Le détour par le courrier changeait les preuves

Certains hôtes n’étaient pas directement joignables, refusaient un démon supplémentaire ou se trouvaient derrière un pare-feu laissant passer le courrier. UFT pouvait alors être encapsulé dans MIME : les commandes devenaient des paramètres de application/octet-stream et le corps binaire était transporté en Base64.

MIME conservait une représentation à travers un transport de messagerie. Il ne transformait pas une arrivée en acceptation. La piste d’audit changeait aussi : plus de message d’accueil ni d’ACK de commande en direct, mais des états de relais et l’authentification éventuellement offerte par le système de courrier. La RFC confiait expressément cette question au transport mail.

SIFT/UFT resta Expérimental. La RFC 1499 le résuma encore ainsi, et le registre IANA conserve aujourd’hui sift-uft sur le port 608. Ce sont des preuves documentaires de publication et d’enregistrement, pas un recensement de logiciels en service.

Conserver les verbes séparés

L’intérêt historique du protocole tient à ses verbes : initier, admettre, recevoir, garder, accepter, rejeter, expirer, exécuter. Chacun appartenait à un acteur et à un instant différents. Le réseau pouvait terminer son verbe sans emprunter celui du destinataire.

Un dossier exploitable doit donc lier le pair de transport, le message d’accueil, chaque commande et son ACK, la taille déclarée et mesurée, le type, l’empreinte du corps, la finalisation du spool, l’échéance de garde, la décision du destinataire et le résultat applicatif. Le mot unique « livraison » efface précisément ce que la RFC 1440 avait rendu visible.

Sources