Summary

  • FTP carried USER, PASS and ACCT as separate access-control identifiers. A successful password step did not necessarily complete login or authorize every later file operation.
  • 332 was a positive intermediate reply. After a file command, it also meant the server retained that command while awaiting account information; 532 meant the command had been discarded and would need to be sent again after ACCT.
  • The protocol did not define account as money, a second password or a global identity. It preserved a slot for local resource and authorization policy, plus evidence about whether the server still held the caller's intent.

The answer after a password was not always a verdict on the password

A user process sent USER. The server requested PASS. The client supplied a password that satisfied that stage. If the site required nothing else for login, RFC 959 allowed the server to return 230 User logged in, proceed.

Another site could return 332 Need account for login.

The leading digit made the distinction machine-readable. A 3yz reply was positive and intermediate: the preceding command had been accepted, but the requested action was held pending more information. Repeating the password was not the repair. The next command was ACCT.

That branch exposed a fact a two-field login form cannot easily express. A system might have enough evidence about who was asking, yet still lack the local context under which the work should consume resources or receive authority. Password acceptance and session readiness were different propositions.

The third identifier came from a host, not a universal identity model

The command entered the record in August 1972. RFC 385 added ACCT to the FTP specification and named systems such as TENEX, which required an account specification in addition to user and password.

The memo distinguished the account command from the password. It was not necessarily tied to USER, could arrive at any time, and could differ across file transfers by the same user. Some servers might require it before declaring the user logged in; others might ask for it only when a particular access, such as storing a file, reached the front of the dialogue.

Nothing in that description turns the string into a bank account. The protocol specified a Telnet string and left its institutional meaning to the remote system. A project, resource allocation, authorization partition or cost centre could fit the mechanism. The evidence does not select one, and it does not make the identifier portable between sites.

FTP's bargain was pragmatic. Heterogeneous hosts did not have to abandon their local account structures. In return, the network conversation needed a third state that clients could not safely flatten into “bad password.”

Before 332 meant account, another number asked the question

RFC 542 incorporated ACCT in 1973. It already separated an account required for login from one required only for a particular access. Its reply vocabulary, however, was not the later one. 331 Enter account completed the login sequence; 433 said a transfer could not proceed without a valid account and instructed the user to enter one and resend the command.

RFC 640 redesigned FTP replies in 1974. Its aim was to let a user protocol interpreter discover outcome and next state from the digits instead of parsing server-dependent prose. A 3yz response became positive intermediate: the command was accepted but the action waited for more information. A 5yz response became a permanent negative completion of that exact request. Replies with 3 in the second position covered authentication and accounting.

The revised list assigned 331 User name okay, need password, 332 Need account for login and 532 Need account for storing files. The protocol question survived; its numeric grammar moved. A 1973 trace containing 331 therefore cannot be read with the 1985 dictionary. Historical numbers are evidence only inside the state machine that issued them.

One missing string produced two different custody outcomes

The deepest distinction appeared after login. RFC 765, retained by RFC 959, described a user who issued a later file command and then encountered an account requirement. The server had two choices.

If it stored the command pending receipt of ACCT, it returned 332. The caller's intent remained on the server. Supplying the missing account information could let that retained operation continue.

If it discarded the command, it returned 532. A later ACCT could establish the context, but it could not resurrect an operation the server no longer held. The client had to send the file command again.

Both replies could be rendered as “account required,” but that text would erase the operational contract. After 332, blindly replaying the file command risks creating a second intent where one is already pending. After 532, failing to replay guarantees that no operation begins. The reply was not merely a reason code. It was a receipt for custody of the request.

“For storing files” did not mean storage was exhausted

The wording of 532 invites a second collapse. Because it mentions storing files, a dashboard may group it with disk or quota failures. RFC 959 assigned those conditions different codes: 452 for insufficient storage space in the system, and 552 for an exceeded storage allocation in the current directory or dataset.

Missing account context, missing system capacity and an exhausted allocation are separate facts with separate owners. The first may be repaired by supplying context. The second needs capacity. The third may require a quota or policy change. Calling all three “storage failed” destroys the evidence needed to choose among them.

Nor does 532 prove that the account, once supplied, will authorize the operation. It says why this exact attempt was not retained. The pathname may still be unavailable, the allocation may still be exceeded, or the transfer may later fail. Account acceptance is one state transition, not a promise about the file.

A control connection could outlive its access-control identity

RFC 959 allowed a new USER command at any point. It flushed previously supplied user, password and account information and began the login sequence again. Transfer parameters remained unchanged, and a file transfer already in progress completed under the old access-control parameters.

That scope is deliberately uneven. The new identity did not reach backwards and take authority over bytes already moving. The old account did not leak forward into the next login. Transport continuity and access-control continuity were different surfaces.

REIN provided another boundary. It cleared the user and account state, restored other parameters to defaults and left the control connection open. A connection identifier is therefore not enough to attribute an operation. An audit must locate the latest USER, ACCT, REIN or reconnection before it can name the governing context.

This also limits what a successful ACCT proves. It establishes that the server accepted account information for the state then pending. It does not prove that the same context survived a later reset, governed a transfer already in progress, or authorized every command that followed.

Supporting the command was not the same as requiring an account

RFC 1123 placed ACCT in the command set that server-FTP and user-FTP implementations had to support, subject to its exception when the underlying file system or operating system did not allow a particular command. The interoperability obligation mattered because a client unable to represent the third step could not use a conforming site that required it.

The requirement did not compel every site to demand a nonempty account. FTP's reply grammar allowed a recognized command with no relevance to a particular system to receive positive 202 treatment as superfluous. Understanding a protocol state and activating it in every session are different commitments.

The current IANA FTP Commands and Extensions registry still records ACCT as the base Account command in the access-control class, with RFC 959 as its reference. The row establishes registered syntax and documentary authority. It does not count deployments, disclose local meanings or prove that a present server accepts the command.

The protocol preserved the right kind of incompleteness

FTP did not solve the institutional problem of accounts across unlike computers. It did something smaller and more durable. It let a server say that the user name was known and the password stage had succeeded while a separate local context remained unresolved. If that need surfaced after an operation, it also let the server declare whether it still possessed the request.

That design prevented one narrow success from acquiring broader authority. PASS did not become a universal grant. ACCT did not become an operation receipt. 230 did not authorize every pathname. 332 did not promise eventual execution. 532 did not diagnose disk capacity.

The old third field is not the recommendation. The recommendation is to preserve separate states for subject proof, resource-context selection and operation acceptance. When a modern API compresses all three into one authenticated boolean, the missing distinctions return as shared credentials, site-specific adapters and failures whose correct recovery can no longer be inferred.

Sources and evidence limits

The closed record is RFC 385, RFC 542, RFC 640, RFC 765, RFC 959, RFC 1123 and the IANA registry. These sources establish the command's semantics and documentary history. They do not establish current prevalence, any implementation's behavior, whether an account string was secret, whether money was charged, or whether a particular file operation completed.