Run Your Own Bulletin Board System

Another fine product © 2019 by Modern Pascal Solutions, LLC.

User Tools

Site Tools




Last Updated: January 1st 2020

This document is loosely based upon Simple File Transport Protocol, RFC913

Author: G.E. Ozz Nixon Jr.


This is the initial draft suggesting a proposed protocol for the ARPA-Internet community, and requests discussion of suggestions for improvements. Distribution of this memo is unlimited.


LEGACY/X TRANSPORT is a modified simple file transfer protocol. It fills the new of people wants a protocol that is more useful than SFTP but easier to implement than BinkP. LEGACY/X TRANSPORT uses only one TCP connection; consisting of null terminated communications; whereas BinkP requires a little more complex syntax and a state oriented workflow.


LEGACY/X TRANSPORT is basically backward compatible with SFTP; so we use the same port (115 decimal). You then send commands and wait for replies. LEGACY/X TRANSPORT commands sent to the remote server are always 4 ASCII letters (of any case) followed by a space, the argument(s), and a <NULL>. The argument can sometimes be null in which case the command is just 4 characters followed by <NULL>. Replies from the server are always a response character followed immediately by an ASCII message string terminated by a <NULL>. The message string consists of the server machine name and optional text.

<command> : = <cmd> [<SPACE> <args>] <NULL>
<cmd> : = USER | ACCT | PASS | TYPE | LIST | CDIR |
<response> : = <response-code> <message> <NULL>
<response-code> : = + | - | !
<message> may contain <CRLF>

Commands that can be sent to the server are listed below. The server replied to each command with one of the possible response codes list under each message. Along with the response, the server should optionally return a message explaining the error in more detail. Example message texts are listed but do not have to be followed. All characters used in messages are ASCII 7-bit with the high-order bit zero, in an 8 bit field.

The response codes and their meanings:

+	Success.
  1. Error.
	An error occurred while processing your command.
!	Logged in.
	You have sent enough information to be able to authenticate yourself.

To use LEGACY/X TRANSPORT you first open a connection to the remote LEGACY/X TRANSPORT server. The server replies by sending either a positive or negative greeting, such as:

+BBS SFTP Service
	(the first word should always be the machine name)
  1. BBS Out to Lunch

Is the server sends back a ‘-‘ negative response it will also close the connection, otherwise you must now send a USER command.

USER user-id
	Your user-id on the remote system.
	The reply to this command will be one of:
	!<user-id> logged in
		Meaning you do not need to transmit a password. This is valid for FREQ 					sessions.
	+<machine-name> <session-hash-string>
	The session-hash-string is unique per connection to the remote server. For
	security purpose the string is changed for each connection to avoid replay
	session hacking. This string is used to encode your password, see PASS.
  1. <machine name> invalid user-id, try again
	If the remote system does not have user-id’s then you should send an 					identification such as your personal name as the argument, and the remote 				system would reply with ‘+’.
PASS sha1-hash
	Your password on the remote system encoded.
	To produce your sha1-hash, you use the <session-hash-string> from the USER
	command combined with the sha1 of your password, as follows:
	sha1-hash := sha1(<session-hash-string>+sha1(<your password>));
	If sha1() of your password is: (sample is sha1(‘password’))
	and the remote server sent:
	sha1-hash should be:
	that is the sha1() of the remote server <session-hash-string>+sha1(‘password’).
	Valid replies are:
		!<machine-name> logged in.
  1. <machine-name> wrong password, try again.

You cannot specify any of the following commands until you receive a ‘!’ response from the remote system.

TYPE { A | B | C | U | X }
	The default is binary if the type is not specified.
	B - BINARY (raw 8bit stream)
	C - MIME/BASE64 Encoding
	X - XOR Encoding (new parameter is the decimal character number to use)
	Valid replies are:
		+<machine-name> Transfer Type <type-specified>
LIST <filename>
	A null directory-path will return the current connect directory listing.
	The directory listing uses the 2000+ directory standard for Windows.
	If the listing is a directory:
	2 spaces
	4 spaces
	either <DIR> or 5 spaces
	10 spaces
	directory name + <CRLF>
	If the listing is a file:
	2 spaces
	left padding, file size, 18 characters
	1 space
	file name + <CRLF>
	Followed by a 2 line summary:
	16 left padding, number of files displayed
	1 space
	15 left padding, total bytes of files displayed
	1 space
	‘bytes’ + <bytes>
	16 left padding, number of files displayed
	1 space
	1 space
	15 left padding, total bytes of files displayed
	1 space
	‘bytes free’ + <bytes>
CDIR <new-directory>
	This will change the current working directory on the remote server to the argument passed.
	+<machine-name> change to <new-directory>
  1. <machine-name> directory does not exist.
KILL <file-spec>
	This will delete the file from the remote system.
	+<machine-name> <file-spec> deleted.
  1. <machine-name> not deleted because <reason>
NAME <old-file-spec>
	Renames the <old-file-spec> to the <new-file-spec> on the remote server.
	Valid replies are:
	+<machine-name> File Exists
  1. <machine-name> cannot find <old-file-spec>
	If you receive a ‘+’ response, you then send:
	TOBE <new-file-spec>
	+<machine-name> <old-file-spec> renamed <new-file-spec>
  1. <machine-name> file was not renamed because <reason>
	Tells the remote server you are finished.
	Valid replies are:
	+<machine-name> <second> seconds used.
	The the remote server closes the connection.
RETR <file-spec>
	Request that the remote server queue the specified file for transfer.
	Valid replies are:
  1. <machine-name> invalid filename specified.
  1. <machine-name> file does not exist.
	If you receive a ‘+’ response, you then send:
	The file is then send as a stream of exact the number of bytes specified. When
	all bytes are civet control passes back to you (the remote server is waiting for
	the next command). If you do not receive a byte within reasonable amount of
	time you should abort the file transfer by closing the connection.
	You would send this instead of SEND if you do not have enough space available.
	Valid replies are:
	+<machine-name> aborted
STOR { APP } { <file-spec> }
	Tells the remote server to receive the file. If the <file-spec> is not specified, the remote server will automatically generate a unique file name. In the case of no <file-spec> the new file will be stored in the default INBOUND folder; this is applicable to MAIL solutions.
	If the APP parameter is specified, the system will attempt to append to the existing filename if permissions allow.
	Valid replies are:
	+<machine-name> will create new file named <file-spec>
	+<machine-name> will create new generation of file.
  1. <machine-name> system running low on free space
  1. <machine-name> invalid filename specified
	If appending:
	+<machine-name> will append to <file-spec>
  1. <machine-name> file does not exist
	If you receive a ‘+’ response, you then send:
	SIZE <number-of-bytes-that-will-be-sent>
	Valid replies are:
	+<machine-name> OK
  1. <machine-name> CANCEL
	If you receive a ‘+’ response, you send the stream.


Mark Lotter receives full create for the original protocol specification RFC-913. Legacy/X Transport is a deviation, providing a more secure technique for authentication over public Internet connections. Legacy/X Transport also introduces multiple encoding formats. As the author of this document and Legacy/X Transport, I have made a number of roman changes, a few wording changes, and a couple of technical changes.
mailhub.txt · Last modified: 01/02/2020 03:44 by Ozz Nixon