Summary

  • RFC 1440 let a sender without an account on the target host push a non-mail file to a daemon, which stored it for later action by the recipient.
  • A NULL ACK accepted one command, while EOF or connection close ended a transfer; none of those events proved that the recipient accepted, opened or used the file.
  • The design lowered friction for the sender but made receiver admission, spool capacity, retention, authentication and executable pseudo-users separate local responsibilities.

A parcel reached the receiving room

The ordinary story of file transfer began with the receiver. A user connected to a remote system, identified an account, chose a file-system operation and initiated the movement. RFC 1440 reversed the first verb. Its Sender-Initiated File Transfer, also called Unsolicited File Transfer, allowed the sender to start. “Unsolicited” had a narrow technical meaning: the receiver had not initiated the transaction. The memo explicitly refused the stronger inference that the file was unwanted.

The inspiration came from NJE networks such as BITNET, where a file could be sent outside the machinery of electronic correspondence. The author compared the missing service to sending a parcel rather than surface mail. A recipient did not need to be present for the network transaction, and the sender did not need an account or prior registration on the destination host.

That bargain mattered because it relocated work. The sender gained a simple outbound act. The target acquired an always-available listener, an admission policy, temporary storage, a recipient namespace and a later handoff procedure. Convenience did not remove state; it moved the state to the receiving side.

One socket carried two different objects

The proposed daemon listened on TCP port 608. A client sent a sequence of text commands followed by binary data. RFC 1440 described the job stream as the concatenation of two files: a control file and a data file. They travelled through one socket, but they did not mean the same thing.

FILE declared a sender, an optional authentication token and an exact or approximate size. USER named a local recipient or service. TYPE described the representation. Those three commands were required before DATA. NAME, DATE and record-format parameters could add context. EOF finished the current file, ABORT requested disposal of a partial file, and QUIT ended the job.

Keeping commands and bytes together simplified the transport, yet the receiver could store them separately. That let the listener avoid interpreting every foreign file format. It also created a correlation duty: the host needed to preserve which commands belonged to which body, what had been received and which disposition later applied.

A zero byte made a deliberately small claim

After each command, the server accepted or rejected it. The positive signal was a NULL ACK: a reply packet beginning with octet zero. One ACK covered one command. It did not retrospectively bless the whole transaction.

That scope is operationally important. A server could accept FILE because the declared size appeared to fit, then reject USER because no such local recipient existed. It could accept the metadata and later fail while writing data. The size itself could be inexact, so the first capacity decision was provisional. A chain of positive command replies was a sequence of local decisions, not one guarantee about the final object.

The server's opening herald named a host, UFT protocol version and server implementation. It supported synchronization and version agreement. It was not an authenticated identity statement. The optional auth field in FILE was an unimplemented ticket, and the memo said authentication was not ensured.

The spool was custody, not consent

When a file arrived, the design placed it in a shared area, illustrated as /usr/spool/uft. There it waited until the recipient accepted or rejected it, or the system discarded it for age. The RFC was careful about the word public: shared space did not mean unrestricted access. Maximum size and retention time were local administrative choices.

This created at least three clocks. The transport clock ended when the bytes were framed and received. The custody clock ran while the host retained the object. The recipient clock began only when a user or service acted. A file could be successfully transferred, still present in the spool and nevertheless unaccepted.

Age deletion was a fourth result, not a disguised rejection by the recipient. It meant the host's retention policy expired. Likewise, a missing spool record after cleanup did not show that a user had consumed the file. Without a disposition event, disappearance remained ambiguous.

RFC 1440 urged the receiving host to process the body as little as possible before acceptance. An unknown representation should be kept as binary rather than transformed destructively. That restraint protected the recipient's later choice, but it did not establish integrity, safety or usefulness.

Burst boundaries bought a place to stop

In normal mode, DATA included a burst size. The receiver read exactly that many octets, wrote them, and returned to command interpretation. A file could use many bursts, and one connection could carry many files. ABORT remained meaningful after a burst completed because the protocol had regained a control boundary.

The memo also offered a mode “for the daring.” If DATA omitted the burst size, the receiver read until the client closed the connection. No EOF or QUIT followed. Closing the socket became the delimiter, and ABORT was unavailable while the unbounded stream was in progress.

The trade was not simply fast versus slow. Bounded bursts produced checkpoints at which the receiver could acknowledge, reject or discard. Close-delimited mode reduced exchanges but collapsed framing and connection lifetime into one event. An unexpected network break and an intended end arrived through the same physical signal and needed other evidence to distinguish them.

A recipient name could point at machinery

USER did not have to name a human. It could identify a software service engine, including a job-entry queue exposed as a pseudo-user. That made SIFT/UFT more than passive storage: a received object might become input to automation.

But the protocol token did not authorize execution. A listener accepting a syntactically valid USER proved only that its local namespace recognized the target under current policy. Safe dispatch still required separate evidence for sender identity, recipient authorization, quarantine, format validation, resource limits, execution, output and rollback. RFC 1440 supplied no general security solution for those steps.

The absence was explicit. Security issues were not discussed, and the authentication ticket was deferred to future work. Removing the need for a sender account therefore removed one friction point without replacing it with a complete trust model.

Mail could carry the object without becoming its judge

Not every host had direct IP connectivity, wanted another daemon or sat beyond a firewall that admitted port 608. RFC 1440 therefore allowed UFT to ride inside MIME. Commands became parameters on application/octet-stream; the data became a Base64-encoded mail body.

MIME solved a representation and carriage problem. It did not prove the UFT recipient accepted the file. It also changed the evidence chain. A direct TCP path could observe heralds, command ACKs, bursts and close. A mail path inherited store-and-forward states and whatever authentication the mail system provided. The RFC explicitly left authentication to that system when mail carried UFT.

The protocol remained Experimental. A later RFC summary retained that status, and today's IANA registry still lists the SIFT/UFT service name on port 608. Those records prove publication and registration. They do not prove that implementations were deployed, remained available or became common.

The final verb belonged to the recipient

RFC 1440's lasting interest is not a claim that the experiment won. It is the precision of its unfinished delivery. The sender could initiate. The daemon could admit a command. The host could receive bytes. The spool could hold an object. None of those actors could manufacture the recipient's acceptance.

A defensible record therefore preserves the herald and transport peer, every command reply, declared and received size, representation, body checksum, spool write and finalization, retention deadline, recipient lookup, disposition event and any later application result. Collapse them into “delivered,” and the cheapest signal acquires authority it never had.

Sources