RFC765 (FTP) [part 3 of 3]
Brian Kantor
brian at sdcc3.UUCP
Sun Jan 6 10:28:11 AEST 1985
June 1980 IEN 149
File Transfer Protocol RFC 765
APPENDIX ON MAIL
The basic commands transmitting mail are the MAIL and the MLFL
commands. These commands cause the transmitted data to be entered
into the recipients mailbox.
MAIL <SP> <recipient name> <CRLF>
If accepted, returns 354 reply and considers all succeeding
lines to be the message text, terminated by a line containing
only a period, upon which a 250 completion reply is returned.
Various errors are possible.
MLFL <SP> <recipient name> <CRLF>
If accepted, acts like a STOR command, except that the data is
considered to be the message text. Various errors are
possible.
There are two possible preliminary replies that a server may use to
indicate that it is accepting mail for a user whose mailbox is not at
that server.
151 User not local; Will forward to <user>@<host>.
This reply indicates that the server knows the user's mailbox
is on another host and will take responsibility for forwarding
the mail to that host. For example, at BBN (or ISI) there are
several host which each have a list of many of the users on
several of the host. These hosts then can accept mail for any
user on their list and forward it to the correct host.
152 User Unknown; Mail will be forwarded by the operator.
This reply indicates that the host does not recognize the user
name, but that it will accept the mail and have the operator
attempt to deliver it. This is useful if the user name is
misspelled, but may be a disservice if the mail is really
undeliverable.
Three FTP commands provide for "sending" a message to a logged-in
user's terminal, as well as variants for mailing it normally whether
the user is logged in or not.
58
IEN 149 June 1980
RFC 765 File Transfer Protocol
MSND -- SeND to terminal.
Returns 450 failure reply if the addressee is refusing or not
logged in.
MSOM -- Send to terminal Or Mailbox.
Returns 119 notification reply if terminal is not accessible.
MSAM -- Send to terminal And Mailbox.
Returns 119 notification reply if terminal is not accessible.
Note that for MSOM and MSAM, it is the mailing which determines
success, not the sending, although MSOM as implemented uses a 119
reply (in addition to the normal success/failure code) to indicate
that because the SEND failed, an attempt is being made to mail the
message instead. There are no corresponding variants for MLFL, since
messages transmitted in this way are generally short.
There are two FTP commands which allow one to mail the text of a
message to several recipients simultaneously; such message
transmission is far more efficient than the practice of sending the
text again and again for each additional recipient at a site.
There are two basic ways of sending a single text to several
recipients. In one, all recipients are specified first, and then the
text is sent; in the other, the order is reversed and the text is
sent first, followed by the recipients. Both schemes are necessary
because neither by itself is optimal for all systems, as will be
explained later. To select a particular scheme, the MRSQ command is
used; to specify recipients after a scheme is chosen, MRCP commands
are given; and to furnish text, the MAIL or MLFL commands are used.
Scheme Selection: MRSQ
MRSQ is the means by which a user program can test for
implementation of MRSQ/MRCP, select a particular scheme, reset its
state thereof, and even do some rudimentary negotiation. Its
format is like that of the TYPE command, as follows:
59
June 1980 IEN 149
File Transfer Protocol RFC 765
MRSQ [<SP> <scheme>] <CRLF>
<scheme> = a single character. The following are defined:
R Recipients first. If not implemented, T must be.
T Text first. If this is not implemented, R must be.
? Request for preference. Must always be implemented.
No argument means a "selection" of none of the schemes (the
default).
Replies:
200 OK, we'll use specified scheme.
215 <scheme> This is the scheme I prefer.
501 I understand MRSQ but can't use that scheme.
5xx Command unrecognized or unimplemented.
Three aspects of MRSQ need to be pointed out here. The first is
that an MRSQ with no argument must always return a 200 reply and
restore the default state of having no scheme selected. Any other
reply implies that MRSQ and hence MRCP are not understood or
cannot be performed correctly.
The second is that the use of "?" as a <scheme> asks the FTP
server to return a 215 reply in which the server specifies a
"preferred" scheme. The format of this reply is simple:
215 <SP> <scheme> [<SP> <arbitrary text>] <CRLF>
Any other reply (e.g. 4xx or 5xx) implies that MRSQ and MRCP
are not implemented, because "?" must always be implemented if
MRSQ is.
The third important thing about MRSQ is that it always has the
side effect of resetting all schemes to their initial state. This
reset must be done no matter what the reply will be - 200, 215, or
501. The actions necessary for a reset will be explained when
discussing how each scheme actually works.
Message Text Specification: MAIL/MLFL
Regardless of which scheme (if any) has been selected, a MAIL or
MLFL with a non-null argument will behave exactly as before; the
MRSQ/MRCP commands have no effect on them. However, such normal
MAIL/MLFL commands do have the same side effect as MRSQ; they
"reset" the current scheme to its initial state.
60
IEN 149 June 1980
RFC 765 File Transfer Protocol
It is only when the argument is null (e.g. MAIL<CRLF> or
MLFL<CRLF>) that the particular scheme being used is important,
because rather than producing an error (as most servers currently
do), the server will accept message text for this "null"
specification; what it does with it depends on which scheme is in
effect, and will be described in "Scheme Mechanics".
Recipient specification: MRCP
In order to specify recipient names (i.e., idents) and receive
some acknowledgment (or refusal) for each name, the following
command is used:
MRCP <SP> <ident> <CRLF>
Reply for no scheme:
503 No scheme specified yet; use MRSQ.
Replies for scheme T are identical to those for MAIL/MLFL.
Replies for scheme R (recipients first):
200 OK, name stored.
452 Recipient table full, this name not stored.
553 Recipient name rejected.
4xx Temporary error, try this name again later.
5xx Permanent error, report to sender.
Note that use of this command is an error if no scheme has been
selected yet; an MRSQ <scheme> must have been given if MRCP is to
be used.
Scheme mechanics: MRSQ R (Recipients first)
In the recipients-first scheme, MRCP is used to specify names
which the FTP server stores in a list or table. Normally the
reply for each MRCP will be either a 200 for acceptance, or a
4xx/5xx code for rejection; all 5xx codes are permanent rejections
(e.g. user not known) which should be reported to the human
sender, whereas 4xx codes in general connote some temporary error
that may be rectified later. None of the 4xx/5xx replies impinge
on previous or succeeding MRCP commands, except for 452 which
indicates that no further MRCP's will succeed unless a message is
sent to the already stored recipients or a reset is done.
Sending message text to stored recipients is done by giving a MAIL
or MLFL command with no argument; that is, just MAIL<CRLF> or
MLFL<CRLF>. Transmission of the message text is exactly the same
as for normal MAIL/MLFL; however, a positive acknowledgment at the
61
June 1980 IEN 149
File Transfer Protocol RFC 765
end of transmission means that the message has been sent to ALL
recipients that were remembered with MRCP, and a failure code
means that it should be considered to have failed for ALL of these
specified recipients. This applies regardless of the actual error
code; and whether the reply signifies success or failure, all
stored recipient names are flushed and forgotten - in other words,
things are reset to their initial state. This purging of the
recipient name list must also be done as the "reset" side effect
of any use of MRSQ.
A 452 reply to an MRCP can thus be handled by using a MAIL/MLFL to
specify the message for currently stored recipients, and then
sending more MRCP's and another MAIL/MLFL, as many times as
necessary; for example, if a server only had room for 10 names
this would result in a 50-recipient message being sent 5 times, to
10 different recipients each time.
If a user attempts to specify message text (MAIL/MLFL with no
argument) before any successful MRCP's have been given, this
should be treated exactly as a "normal" MAIL/MLFL with a null
recipient would be; some servers will return an error of some
type, such as "550 Null recipient".
See Example 1 for an example using MRSQ R.
Scheme mechanics: MRSQ T (Text first)
In the text-first scheme, MAIL/MLFL with no argument is used to
specify message text, which the server stores away. Succeeding
MRCP's are then treated as if they were MAIL/MLFL commands, except
that none of the text transfer manipulations are done; the stored
message text is sent to the specified recipient, and a reply code
is returned identical to that which an actual MAIL/MLFL would
invoke. (Note ANY 2xx code indicates success.)
The stored message text is not forgotten until the next MAIL/MLFL
or MRSQ, which will either replace it with new text or flush it
entirely. Any use of MRSQ will reset this scheme by flushing
stored text, as will any use of MAIL/MLFL with a non-null
argument.
If an MRCP is seen before any message text has been stored, the
user in effect is trying to send a null message; some servers
might allow this, others would return an error code.
See Example 2 for an example using MRSQ T.
62
IEN 149 June 1980
RFC 765 File Transfer Protocol
Why two schemes anyway?
Because neither by itself is optimal for all systems. MRSQ R
allows more of a "bulk" mailing, because everything is saved up
and then mailed simultaneously; this is very useful for systems
such as ITS where the FTP server does not itself write mail
directly, but hands it on to a central mailer demon of great
power; the more information (e.g. recipients) associated with a
single "hand-off", the more efficiently mail can be delivered.
By contrast, MRSQ T is geared to FTP servers which want to deliver
mail directly, in one-by-one incremental fashion. This way they
can return an individual success/failure reply code for each
recipient given which may depend on variable file system factors
such as exceeding disk allocation, mailbox access conflicts, and
so forth; if they tried to emulate MRSQ R's bulk mailing, they
would have to ensure that a success reply to the MAIL/MLFL indeed
meant that it had been delivered to ALL recipients specified - not
just some.
Notes:
* Because these commands are not required in the minimum
implementation of FTP, one must be prepared to deal with sites
which don't recognize either MRSQ or MRCP. "MRSQ" and "MRSQ ?"
are explicitly designed as tests to see whether either scheme is
implemented; MRCP is not, and a failure return of the
"unimplemented" variety could be confused with "No scheme
selected yet", or even with "Recipient unknown". Be safe, be
sure, use MRSQ!
* There is no way to indicate in a positive response to "MRSQ ?"
that the preferred "scheme" for a server is that of the default
state; i.e. none of the multi-recipient schemes. The rationale
is that in this case, it would be pointless to implement
MRSQ/MRCP at all, and the response would therefore be negative.
* One reason that the use of MAIL/MLFL is restricted to null
arguments with this multi-recipient extension is the ambiguity
that would result if a non-null argument were allowed; for
example, if MRSQ R was in effect and some MRCP's had been given,
and a MAIL FOO<CRLF> was done, there would be no way to
distinguish a failure reply for mailbox "FOO" from a global
failure for all recipients specified. A similar situation
exists for MRSQ T; it would not be clear whether the text was
stored and the mailbox failed, or vice versa, or both.
63
June 1980 IEN 149
File Transfer Protocol RFC 765
* "Resets" are done by all MRSQ's and "normal" MAIL/MLFL's to
avoid confusion and overly complicated implementation. The MRSQ
command implies a change or uncertainty of status, and the
latter commands would otherwise have to use some independent
mechanisms to avoid clobbering the data bases (e.g., message
text storage area) used by the T/R schemes. However, once a
scheme is selected, it remains "in effect" just as a "TYPE A"
remains selected. The recommended way for doing a reset,
without changing the current selection, is with "MRSQ ?".
Remember that "MRSQ" alone reverts to the no-scheme state.
* It is permissible to intersperse other FTP commands among the
MRSQ/MRCP/MAIL sequences.
64
IEN 149 June 1980
RFC 765 File Transfer Protocol
Example 1
Example of MRSQ R (Recipients first)
This is an example of how MRSQ R is used; first the user must
establish that the server in fact implements MRSQ:
U: MRSQ
S: 200 OK, no scheme selected.
An MRSQ with a null argument always returns a 200 if implemented,
selecting the "scheme" of null, i.e. none of them. If MRSQ were
not implemented, a code of 4xx or 5xx would be returned.
U: MRSQ R
S: 200 OK, using that scheme
All's well; now the recipients can be specified.
U: MRCP Foo
S: 200 OK
U: MRCP Raboof
S: 553 Who's that? No such user here.
U: MRCP bar
S: 200 OK
Well, two out of three ain't bad. Note that the demise of
"Raboof" has no effect on the storage of "Foo" or "bar". Now to
furnish the message text, by giving a MAIL or MLFL with no
argument:
U: MAIL
S: 354 Type mail, ended by <CRLF>.<CRLF>
U: Blah blah blah blah....etc etc etc
U: .
S: 250 Mail sent.
The text has now been sent to both "Foo" and "bar".
65
June 1980 IEN 149
File Transfer Protocol RFC 765
Example 2
Example of MRSQ T (Text first)
Using the same message as the previous example:
U: MRSQ ?
S: 215 T Text first, please.
MRSQ is indeed implemented, and the server says that it prefers
"T", but that needn't stop the user from trying something else:
U: MRSQ R
S: 501 Sorry, I really can't do that.
It's possible that it could have understood "R" also, but in
general it's best to use the "preferred" scheme, since the server
knows which is most efficient for its particular site. Anyway:
U: MRSQ T
S: 200 OK, using that scheme.
Scheme "T" is now selected, and the text must be sent:
U: MAIL
S: 354 Type mail, ended by <CRLF>.<CRLF>
U: Blah blah blah blah....etc etc etc
U: .
S: 250 Mail stored.
Now recipients can be specified:
U: MRCP Foo
S: 250 Stored mail sent.
U: MRCP Raboof
S: 553 Who's that? No such user here.
U: MRCP bar
S: 250 Stored mail sent.
66
IEN 149 June 1980
RFC 765 File Transfer Protocol
Again, the text has now been sent to both "Foo" and "bar", and
still remains stored. A new message can be sent with another
MAIL/MRCP... sequence, but the fastidious or paranoid could chose
to do:
U: MRSQ ?
S: 215 T Text first, please.
Which resets things without altering the scheme in effect.
67
June 1980 IEN 149
File Transfer Protocol RFC 765
APPENDIX ON PAGE STRUCTURE
The need for FTP to support page structure derives principally from
the need to support efficient transmission of files between TOPS20
systems, particularly the files used by NLS.
The file system of TOPS20 is based on the concept of pages. The
system level is most efficient at manipulating files as pages.
System level programs provide an interface to the file system so that
many applications view files as sequential streams of characters.
However, a few applications use the underlying page structures
directly, and some of these create holey files.
A TOPS20 file is just a bunch of words pointed to by a page table.
If those words contain CRLF's, fine -- but that doesn't mean "record"
to TOPS20.
A TOPS20 disk file consists of four things: a pathname, a page table,
a (possibly empty) set of pages, and a set of attributes.
The pathname is specified in the RETR or STOR command. It includes
the directory name, file name, file name extension, and version
number.
The page table contains up to 2**18 entries. Each entry may be
EMPTY, or may point to a page. If it is not empty, there are also
some page-specific access bits; not all pages of a file need have the
same access protection.
A page is a contiguous set of 512 words of 36 bits each.
The attributes of the file, in the File Descriptor Block (FDB),
contain such things as creation time, write time, read time, writer's
byte-size, end of file pointer, count of reads and writes, backup
system tape numbers, etc.
Note that there is NO requirement that pages in the page table be
contiguous. There may be empty page table slots between occupied
ones. Also, the end of file pointer is simply a number. There is no
requirement that it in fact point at the "last" datum in the file.
Ordinary sequential I/O calls in TOPS20 will cause the end of file
pointer to be left after the last datum written, but other operations
may cause it not to be so, if a particular programming system so
requires.
68
IEN 149 June 1980
RFC 765 File Transfer Protocol
In fact both of these special cases, "holey" files and
end-of-file pointers not at the end of the file, occur with NLS data
files.
The TOPS20 paged files can be sent with the FTP transfer parameters:
TYPE L 36, STRU P, and MODE S (in fact any mode could be used).
Each page of information has a header. Each header field, which is a
logical byte, is a TOPS20 word, since the TYPE is L 36.
The header fields are:
Word 0: Header Length.
The header length is 5.
Word 1: Page Index.
If the data is a disk file page, this is the number of that
page in the file's page map. Empty pages (holes) in the file
are simply not sent. Note that a hole is NOT the same as a
page of zeros.
Word 2: Data Length.
The number of data words in this page, following the header.
Thus the total length of the transmission unit is the Header
Length plus the Data Length.
Word 3: Page Type.
A code for what type of chunk this is. A data page is type 3,
the FDB page is type 2.
Word 4: Page Access Control.
The access bits associated with the page in the file's page
map. (This full word quantity is put into AC2 of an SPACS by
the program reading from net to disk.)
After the header are Data Length data words. Data Length is
currently either 512 for a data page or 21 for an FDB. Trailing
zeros in a disk file page may be discarded, making Data Length less
than 512 in that case.
69
June 1980 IEN 149
File Transfer Protocol RFC 765
Data transfers are implemented like the layers of an onion: some
characters are packaged into a line. Some lines are packaged into a
file. The file is broken into other manageable units for
transmission. Those units have compression applied to them. The
units may be flagged by restart markers. On the other end, the
process is reversed.
70
More information about the Comp.sources.unix
mailing list