diff options
Diffstat (limited to 'doc/rfc/rfc475.txt')
| -rw-r--r-- | doc/rfc/rfc475.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc475.txt b/doc/rfc/rfc475.txt new file mode 100644 index 0000000..06fc671 --- /dev/null +++ b/doc/rfc/rfc475.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group A. Bhushan +Request for Comments: 475 MIT-DMCG +NIC: 14919 March 6, 1973 + + + FTP AND NETWORK MAIL SYSTEM + + This paper describes my understanding of the results of the Network + Mail System meeting SRI-ARC on February 23, 1973, and the + implications for FTP (File Transfer Protocol). There was general + agreement at the meeting that network mail function should be within + FTP. + + FTP currently provides two commands for handling mail. The MAIL + command allows a user to send mail via the TELNET connection (the + server collects the mail and determines its end by searching for the + character sequence "CRLF.CRLF"). The MLFL (mail file) command allows + a user to send mail via the data connection (requires a user-FTP to + handle the command but transfer is more efficient as server need not + search for a special character sequence). These commands are being + used to provide network mailing facilities. Local mail and SNDMSG + programs have been modified at many sites to include network mailing + (e.g., USER@HOST at BBN_TENEX and MAIL host user at MIT-DMCG). + + The network mail system should provide a facility whereby users can + conveniently send messages to other network users who have + "mailboxes" at one or more hosts. It is not required that the + messages or mail be delivered in real-time. The network mail system + is not an interactive inter-console communication facility, but it + may be possible for some sites to deliver "urgent" mail to users in + real-time (e.g., print mail at user console if user is currently + logged-in). The mail system also does not provide a general inter- + process communication facility, though it may be possible to deliver + messages to programs which have mailbox addresses. Inter-process and + inter-entity communication facilities are very desirable but are + beyond the scope of the network mail system. + + The concepts of "mailbox" and "mailbox addresses" are central to this + discussion of network mail system. A mailbox is a place where the + mail is stored before a user picks it up. It may be a file in the + user's directory or it may be a bin for hard-copy. The mailbox + address is the address required by the sender in order to send the + mail to its destination mailbox. For users who have an "on-line" + network mailbox, the mailbox address contains the Host address and + the user's mailbox identification at that Host. The mailbox + identification is that which is required by an FTP-server in order + that it may put the mail in the desired mailbox. The terms mailbox + address will be used to refer to the on-line network mailbox address. + + + +Bhushan [Page 1] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + NETWORK MAIL SYSTEM FUNCTIONS + + The network mail system should provide the following six functions: + + 1. CREATING: This refers to the manner in which the user creates or + composes his message. The FTP servers do not explicitly provide + any message editing capability (server's editing conventions may + be applicable in the case of MAIL command). Editing conventions + such as those for character delete and line cancel vary widely + over the network. The user is most familiar with his local Host + conventions and these should be used for network mail editing. + The user also has access to local editing systems which can be + used for composing message files. The message file may then be + transmitted via the MAIL or MLFL commands (MLFL being preferable). + The present FTP approach of assuming the creation of messages to + be sender's responsibility seems adequate. TIP users if they + desire editing facilities should use intermediate Hosts for + creating and sending messages. + + 2. LOCATING: How sender determines receivers address. FTP assumes + that the sender knows the receivers correct address. There is no + published or "on-line" list of mailbox addresses. There is, + however, a list of network participants maintained (on-line) and + published by the Network Information Center (NIC) at SRI-ARC. The + network users have been assigned a unique "NIC Ident" and Host + site by the NIC. It was therefore specified in FTP that FTP- + servers maintain a table that maps NIC Idents to mail-box + identifications. The NIC will maintain on-line and publish the + local mailbox address information for network participants. It + would be possible for users to look up a published list, or querry + the NIC on-line to locate destination addresses. The NIC will + also provide an on-line facility (similar to FTP) that can be used + by programs for retrieving the address information. This latter + approach of the NIC's maintaining addresses has several + advantages. The user can obtain a number of addresses for a + group, and use these to transmit mail. The FTP servers need not + maintain NIC Ident Tables, and the NIC can provide a good facility + for locating addresses from last names, NIC Idents, or even + sketchy information. It may still be desirable that FTP servers + accept NIC idents, last names, and other standard forms as mailbox + identifiers. + + 3. SENDING: How message is sent to the destination mailbox. The + messages may be sent directly to the destination mailbox (via + TELNET or Data connections) or via an intermediate Host such as + the NIC. FTP does not explicitly provide for mail forwarding by + intermediate Hosts but FTP servers may be able to recognize + addresses as not being local, and forward mail. In the event mail + + + +Bhushan [Page 2] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + is to be forwarded, a desirable facility is to have the + intermediate site return an acknowledgement (by request) upon + delivery of mail or if delivery fails within a specified time. + The current FTP specifications recommend that FTP-servers accept + multiple addresses but do not require this. + + 4. STORING: Where mail is stored before reading and if information is + available for later reference or retrieval. The FTP does not + require that sender store mail or keep duplicate copies. It is + the receiver's responsibility to store the information for + reading, reference, or retrieval. The receiver need not store the + mail as a data file but can directly print it out on a user + console or line printer. FTP does not specify the procedures for + storage handling by intermediate sites. If intermediate site is + used for forwarding the mail until it is delivered to its final + destination. If the mail is undeliverable then the intermediate + site should return the undelivered information to the sender. A + similar situation arises when sending of mail is deferred by the + sending site (destination host may be down). The sending site + then acts as an intermediate forwarder insofar as the user is + concerned. + + 5. RECORDING: Should the mail be catalogued and recorded for later + reference and retrieval. FTP currently does not provide an + explicit mechanism for the receiver to record mail. If an + intermediate site (the NIC) is used for mail distribution then a + function of such a site could be to record mail, if so requested. + NIC is ideal for recording mail, but other sites may also wish to + record the mail. If the mail is recorded, then it is not + necessary to send the entire contents of the mail. Instead only a + citation for the document can be sent and the receiver can + retrieve the mail only if he wants to. This is particularly + useful for large documents such as NWG/RFC which are distributed + to a group. The citation may contain author, title, retrieval + pathname, and perhaps an abstract. + + 6. READING: How the mail is finally presented to and read by the + user. FTP currently assumes that mail reading is entirely the + receiving site's function. However, there are ways in which the + sender can aid the receiver in providing improved mail reading + facilities. For example, the receiving system, if it knows a + message to be urgent can deliver it immediately at a user console. + Long messages may be put in separate files with notification in + user's regular mail. Alternately, mail could be a citation that + the reading program can retrieve upon user request. Selective + handling of different classes of mail is important for an improved + network mail system. + + + + +Bhushan [Page 3] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + MODELS FOR MAIL SYSTEM USE + + The user of a mail system can use intermediate site for locating + addresses, recording and/or distributing mail, and for creating and + reading mail. We therefore have the following models for mail system + use: + + 1. The user connects directly to the destination FTP server and sends + mail using the MAIL command. Local editing functions are limited + to character delete and line cancel (assuming user is in line-at- + a-time mode) and server conventions may also apply. The user only + needs a user-TELNET program at his site but needs to know the + destination address. This model is specially applicable to TIP + and other mini-Host users who do not have a user-FTP or user-Mail + programs. + + 2. The user composes the mail using a local editor (or mail system) + and then requests his user-FTP or mail program to send the mail + directly to the destination via the FTP MAIL or MLFL commands. + The user needs to know the destination address. The mail can be + deferred by the sending program if the destination Host is down. + TIP users can use this model by using the facilities of a "home- + base" Host. + + 3. The user uses an intermediate site such as NIC (other sites may + provide forwarding services too) for mail distribution. The user + need not know the destination addresses but can use NIC idents for + individuals and groups of individuals. The mail can be recorded + on request and its sending can be deferred (the destination Host + may be down, or it may be more economical to defer mail). The + message to be mailed may be created at the local site using local + editing facilities, or it may be created directly at the + intermediate site. + + 4. The user may send a citation of the mail instead of the complete + mail item. The citation refers to an existing document which can + be retrieved on-line (such as the NIC number of a NIC journal + communication). + + MAILING TO TIP USERS + + The TIP does not currently provide an FTP server or mailbox + facilities. While it is possible to send mail to TIP terminals (such + as line printers) it seems undesirable to do so because of the + possibility of losing mail, the lack of privacy, and the fact that + user may be several (or several hundred) miles away from the location + of the TIP. The TIP users normally have a "home-base" computer where + they do their computing work most of the time. The TIP user problem + + + +Bhushan [Page 4] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + is best solved by requiring that TIP users rent mailboxes at their + "home-base" Host. Such a Host can provide good mail reading and + querry facilities. A TIP user can request his "home" Host to send + him notification of mail on a TIP terminal. If RDML command (NWG/RFC + 458) is accepted in FTP, TIP users could use such a command. More + important, if the user has a number of mailboxes on different Hosts, + the RDML (or RDMF) command can be used to read his mail at all the + sites where he has mailboxes. + + ACCESS CONTROL IN MAIL SYSTEM + + It has been suggested that FTP specification should require that mail + function (for receiving mail) should be "free", i.e., FTP servers + should not require the user to "login" (send the USER, PASS, and ACCT + commands). In the absence of the access control commands the FTP + server should charge the cost of receiving mail to an overhead or + browsing account. It should be noted that this "free" mail function + using default "USER" account may not allow non mail-related commands + without reinitializing. This requirement will improve communication + among the network users. + + Some systems, such as Multics, have mechanisms for access control in + the receipt of mail. That is a user can specify who is eligible to + send him mail (normally users give then access ".*.*.*.", i.e., any + one can send mail). The access control commands would be required to + gain privileged access. The USER command does not seem the best way + to identify the sender of mail. Consider users logged in as GUEST, + ICCC, NETWORK, MIT-DMCG, and NETWORK-USER. A separate FROM command + seems desirable. Such a command can be used to identify the sender + as well as to send acknowledgments and replies. The receiving site + can tag the mail as: FROM AKB at MIT-DMCG, logged in as GUEST. The + receiver can then send reply to the mailbox address AKB at Host 70 + (SNDMSG AKB@DMCG or MAIL DMCG AKB). + + NETWORK INFORMATION CENTER FUNCTIONS + + The NIC is a very special facility for handling mail. It provides + facilities for recording and distributing mail to individuals and + groups of individuals, and for locating users' addresses. The NIC + will also undertake to provide distribution of unrecorded mail. + Currently the NIC requires that users log into the NIC and use NLS to + create and distribute mail. Using NLS for creating mail has been a + frustrating experience for many who are used to different editing + systems. Recently there has been a problem that NIC is overloaded at + most times of the day and even if one can get a "network terminal" + and log in, the interaction is quite slow. As NIC (or NLS) is + designed for character-at-a-time interaction with remote echo, the + + + + +Bhushan [Page 5] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + use is inefficient. Using NIC is particularly unbearable when the + user falls behind in his echo by as much as an entire line. + + An alternative to direct use of NIC is to use the NIC via FTP and + programs at the user's site. The user can create journal documents + using his own local editing system and then transfer it to NIC via + FTP. The user may have to specify such information as author, title, + where the acknowledgment should be sent, and journal number if the + item is to be recorded. It should also be possible for users to send + sequential files to NIC and have them restructuredinto NLS form + without having to do an "input sequential" (a suggestion is to "NLS" + the file if its name is suffixed with a .NLS). Alternately it should + be possible for user's to retrieve journal documents and other + sequential files without having to do a previous "output sequential". + + The NIC currently delivers mail via hardcopy and/or on-line. On-line + currently means that user must log into NIC to see if he has a + message and read it by "print branch". The messages are not seen by + the destination users for several days and many users get their hard + copy before they have had a chance to examine their on-line NIC mail. + If the NIC were to deliver mail via FTP to network users, then the + mail turn-around time will be greatly speeded and the users will not + have to log into the NIC. Large documents need not be mailed to the + user in their entirety but only a citation need be sent. The NIC + willhave to collect the information on the mailbox addresses of + Network participants for delivering mail, especially since it appears + that many FTP servers are not "respecting" NIC idents. It is + recognized that a user may have only one (the most used) of these + addresses. + + The NIC identification subsystem (currently accessible via NLS only) + contains information on users (such as affiliation, US Mail address, + telephone numbers, etc.) and groups (members, etc.). The on-line + mailbox address information can be added here. The NIC will + undertake to provide a facility whereby the identification subsystem + can be querried by programs, allowing mailing programs to retrieve + the addresses automatically. This facility will be separate from + FTP. + + FTP MODIFICATIONS + + The FTP currently does not provide explicit facilities for recording + mail, communicating sender's address, sending program readable + citations, specifying author and title for documents, requesting + acknowledgments, and indicating message type (urgent, ordinary, and + long). To overcome these deficiencies, we can take any of the + following approaches: + + + + +Bhushan [Page 6] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + 1. Kludge the desired features in the pathname syntax of the MAIL and + MLFL commands, justifying the kludge on the grounds that most of + the functions are to be used only by the NIC. + + 2. Add new commands for the desired functions and alter the MAIL and + MLFL commands somewhat to recognize the existence of the new + commands. + + 3. Define a new mail command which incorporates the missing functions + (in the process defining new commands for the desired functions). + The MAIL and MLFL commands can be used in their present form but + may be gradually phased out. + + The first approach seems undesirable to me as many of the missing + functions can be used by other sites as well. In addition it will be + easier to write programs to deal with commands rather than a complex + syntax. The second and the third approaches are not very different + from each other. The third approach seems preferable as it will + allow existing mail programs to function in their present form. + Using the third approach consider the following new FTP commands: + + 1. MLTO (mail to): The argument is one or more mailbox identifiers + separated by "," (commas). It is suggested that if there is no + argument, the mail should be sent to some responsible user or + printed on a printer. This command starts the sequence of + optional FTP mail related commands described below. The sequence + ends with the TEXT, FILE, or CITA (citation) commands. + + 2. FROM: The argument is the address of the sender or senders. It is + in a standard form that can be interpreted by programs as well as + human users. The information is to be used for identifying the + sender(s), for sending replies, and for sending acknowledgments if + the receiver is an intermediate forwarding site. + + 3. MTYP (mail type): This identifies the type of mail as U (urgent), + O (ordinary), and L (long). The receiving system can take the + appropriate actions from this knowledge. The default assumption + is ordinary mail. + + 4. RECO (record the mail): The argument if present is the identifying + information for recording (such as NIC Journal number). If no + argument is present the server will assign the recording + information and send an appropriate reply (real-time or deferred). + + 5. AUTH (author): Identifies the author of the document in a form + acceptable to the server (NIC ident may be required by NIC). + + + + + +Bhushan [Page 7] + +RFC 475 FTP AND NETWORK MAIL SYSTEM March 1973 + + + 6. TITL (title): Identifies the title of the document. The argument + is an ASCII string ending with the sequence "CRLF.CRLF". + + 7. ACKN (acknowledge): Relevant for intermediate forwarding sites. + Asks the server to send acknowledgment on delivery or if delivery + fails within a specified time. + + 8. TEXT: No arguments. Starts the transfer of mail over TELNET + connection in an identical manner as MAIL. + + 9. FILE: No arguments. Starts transfer of mail over the data + connection in an identical manner as MLFL. + + 10. CITA (citation): Argument is the pathname of retrievable file. + + We also need to define new reply codes for handling mail. Some sites + have expressed the need for replies such as "send only X bytes of + mail". Other replies could specifically request additional commands + such as USER/PASS/ACCT for privileged mailing, FROM/ACKN for mail + forwarding, and AUTH/TITL for recorded mail. Another suggestion that + may be given consideration is allowing TYPE/BYTE other than A/8 for + FILE command. Mailing large files between like machines such as + PDP-10s is more efficient in I/36. The RDML and RDMF commands + proposed by Bressler and Thomas (NWG/RFC 458) also merit + consideration as they would aid the handling of mail for users who + have mailboxes at different Hosts. + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Kelly Tardif, Viagenie 10/99] + + + + + + + + + + + + + + + + + + + + + +Bhushan [Page 8] + |