8

FTP has a USER command for sending the user name and a PASS command for sending the password. It also has an ACCT command, as RFC 959 page 26 explains:

ACCOUNT (ACCT)

   The argument field is a Telnet string identifying the user's
   account.  The command is not necessarily related to the USER
   command, as some sites may require an account for login and
   others only for specific access, such as storing files.  In
   the latter case the command may arrive at any time.

   There are reply codes to differentiate these cases for the
   automation: when account information is required for login,
   the response to a successful PASSword command is reply code
   332.  On the other hand, if account information is NOT
   required for login, the reply to a successful PASSword
   command is 230; and if the account information is needed for
   a command issued later in the dialogue, the server should
   return a 332 or 532 reply depending on whether it stores
   (pending receipt of the ACCounT command) or discards the
   command, respectively.

Few systems ever implemented ACCT; most FTP servers ignore it, and many FTP clients don't support sending it.

My question is – can anyone give examples of historical FTP server implementations which actually accepted or required ACCT? I would assume those implementations were most likely on non-mainstream platforms (mainframes and minicomputers), not Linux/Windows/etc.

Some contemporary uses I can find:

  • Unisys ClearPath MCP supports a user having multiple associated CHARGECODE, which a user can switch between dynamically during their session – if they work on different projects, their computer usage can be charged to the appropriate project by changing the charge code. And MCP's FTP server supports the ACCT command to specify which chargecode to charge the FTP operations to
  • Some FTP proxy servers support "Raptor login syntax" in which ACCT is used to send the proxy password (see here and here)
  • VM/CMS FTP server uses ACCT to specify minidisk password (source)
  • The documentation for the old Cisco Interlink FTP server for OS/390 reports that it supports ACCT (see Table 5-1 here), but it is unclear what it actually did with it. The documentation for the FTPLOGIN user exit mentions than it is called when the user executes either PASS or ACCT, so it is possible the ACCT info would only be used if a site wrote their own code to validate it. Note Cisco was just reselling Interlink's TCP/IP stack (for a few years starting in 1996); in 1999, they were acquired by Sterling Software; then in 2000, CA bought Sterling, and the Interlink TCP/IP stack was renamed CA Unicenter TCPaccess; and then in 2018 Broadcom bought CA, and now Unicenter TCPaccess is a Broadcom product, and you'll still find FTPLOGIN in their docs. By contrast, the FTP server in IBM's TCP/IP stack for z/OS appears to ignore ACCT as most Un*x/Windows/etc FTP servers do.

I assume historically there would have been more. MCP's use seems aligned with the original intention whereas its use by proxies seems more of a hack (which relies on the fact that most FTP servers don't use ACCT–it would break any FTP server which actually needed it.)

1

2 Answers 2

8

My question is – can anyone give examples of historical FTP server implementations which actually accepted or required ACCT?

FTP on BS2000 for example (*1).

I would assume those implementations were most likely on non-mainstream platforms (mainframes and minicomputers),

Mainstream is not exactly a qualification usable across classes.

not Linux/Windows/etc.

No, as those systems do not support accounting as a base feature. They usually operate resource based charging on a per user base.


Reverse "Hack"

MCP's [...] use by proxies seems more of a hack (which relies on the fact that most FTP servers don't use ACCT–it would break any FTP server which actually needed it.)

In fact, BS2000 facilitates nowadays a reverse hack by allowing to append an account-id to a user name to enable work of ftp clients not offering a way to enter ACCT as intended. Here the account-id is to be send wit the user name, separated by a comma.


What is it good for?

To stay with BS2000 (*2), here each job (*3) "could" (*4) specify a 1..8 character account identifier. Each accounting relevant resource use, like disk, processing time, lines printed, etc. was recorded in the OS accounting file. Using that identifier those records could be selected and either printed as summary, or, more common, directly inputted into an accounting system, used to print and send out billing to each customer/department.

By having the ability to use dedicated accounts for example for development, maintenance and production enables either to run in the very same environment (user) but still be charged different.


*1 - Maybe with exception of still being alive and maintained.

*2 - Likewise any other TSOS offspring.

*3 - Interactive Login being just a special case of job.

*4 - Quotation marks used as it was rather unlikely that the guys from accounting would let anyone slip by without :))

1
2

On Multics, users often had multiple accounts. The (extremely elaborate!) login command allowed you to specify a Project_id when logging in. Home directories were organized by project and person, so the Project_id you chose determined your home directory as well as your file access and billing. However, as @davidbak has pointed out, it did not use the ACCT command to implement this, even though ACCT would seem applicable.

5
  • Extremely elaborate? Might depend on PoV :))
    – Raffzahn
    Commented Feb 23 at 21:28
  • "must have used it", because reasons, is awfully strong. I'm not so sure. See here, in the current multics source repository the list of supported FTP commands - ACCT is not there. This is Multics R12.7 - the one that you can run today (in 6180 emulation) - but shows that if it was ever there it's been stripped out, if you think that's likely.
    – davidbak
    Commented Feb 24 at 2:24
  • @davidbak Good research. I suppose it may have used the person.project style for the USER. I'll delete the answer.
    – John Doty
    Commented Feb 24 at 2:33
  • 2
    Please don't delete this. No need to be embarrassed. The detail of the separation between user and billling project in Multics is interesting.
    – davidbak
    Commented Feb 24 at 2:47
  • 1
    @JohnDoty yes please don't delete it. you've made a valuable contribution even though your (highly reasonable) speculation turned out to be incorrect Commented Feb 24 at 3:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .