From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc915.txt | 627 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 627 insertions(+) create mode 100644 doc/rfc/rfc915.txt (limited to 'doc/rfc/rfc915.txt') diff --git a/doc/rfc/rfc915.txt b/doc/rfc/rfc915.txt new file mode 100644 index 0000000..2ea7102 --- /dev/null +++ b/doc/rfc/rfc915.txt @@ -0,0 +1,627 @@ + + +Network Working Group Marc A. Elvy +Request for Comments: 915 Harvard University + Rudy Nedved + Carnegie-Mellon University + December 1984 + + NETWORK MAIL PATH SERVICE + + +STATUS OF THIS MEMO + + This RFC proposes a new service for the ARPA-Internet community and + requests discussion and suggestions for improvements. Distribution + of this memo is unlimited. + +INTRODUCTION + + The network mail path service fills the current need of people to + determine mailbox addresses for hosts that are not part of the + ARPA-Internet but can be reached by one or more relay hosts that have + Unix To Unix Copy (UUCP) mail, CSNET mail, MAILNET mail, BITNET mail, + etc. + + Anyone can use the service if they have TCP/TELNET to one of the + hosts with a mail path server. + +DISCUSSION + + Currently many hosts that are not connected to the ARPA-Internet + network can send mail to and receive mail from the ARPA-Internet + community. The ARPA-Internet community sends mail using mailbox + addresses of the form "user@host" or "local-part@domain" [1, 5]. In + an effort to provide service to hosts not connected directly to the + ARPA-Internet, mail maintainers have used the feature that the + "local-part" of the mailbox address is locally interpreted to imbed + specially encoded mail routing or relaying information. These + encoded mailbox addresses have a variety of forms and have become + common practice. For example: + + demco%ucb-ean.cdn%ubc.csnet@CSNET-RELAY.ARPA + + "Rudy.Nedved%CMCCTE@CARNEGIE.MAILNET"@MIT-MULTICS.ARPA + + ihnp4!cmucsg!ern@UT-SALLY.ARPA + + mss.dartmouth@CSNET-RELAY.ARPA + + nedved%CMCCTF.BITNET@WISCVM.ARPA + + It is important that people be able to communicate, but it is clear + from the rampant confusion and frustration that something must be + + +Elvy & Nedved [Page 1] + + + +RFC 915 Month Year +Network Mail Path Service + + + provided to make it easier for people to address mail to + non-ARPA-Internet hosts. The result, for a variety of reasons, has + been the work and development of the Domain Name system and + facilities [2, 3, 7, 9], and it is expected to make mailbox addresses + be as simple as the current ARPA-Internet mailbox format (e.g., + "user@domain"). + + How do people discover the special encoded addresses for + non-ARPA-Internet host mailboxes until the domain name system is + working and covering the majority of hosts in the mail world? The + proposed solution to this problem is to provide a network service for + the ARPA-Internet and a mail service for the non-ARPA-Internet hosts + that, given a host and an optional addressing system or communication + protocol or some other piece of information, supplies the mailbox + address format for sending mail to that host. For example, + "nedved@Carnegie.MAILNET" would be translated by the server to + "nedved%Carnegie.MAILNET@MIT-MULTICS.ARPA". This memo covers the + proposed network service. + +DOCUMENT CONVENTIONS + + Unless otherwise noted, all numbers are in decimal. + + The term "host", as used in this document, describes one computer + system which may have more than one name associated with it. It may + have a name for each network or mail connection it supports and may + have several nicknames or aliases for the computer and/or for each + set of network names that the computer has acquired. + +OVERVIEW + + The network service is a connection based application on TCP [4]. A + server listens for TCP connections on the assigned port of 117 [8]. + It responds to the connection with a coded greeting message and waits + for a command line. For each command line sent to the server, the + server will respond with a coded message. The special command QUIT + causes the server to respond with a coded closing message and closes + the connection. + + + + + + + + + + + +Elvy & Nedved [Page 2] + + + +RFC 915 Month Year +Network Mail Path Service + + +DESIGN GOALS + + One of the goals is to provide the service to as many ARPA-Internet + hosts as possible. In the current ARPA-Internet, experience has shown + that software people first implement TELNET/TCP [6] before any other + network application or protocol. Therefore, it is a sub-goal that + people be able to access the service using available programs (with + minimal modifications) that implement TELNET/TCP. Therefore, + TELNET/TCP on port 117 will work correctly. The server understands + TELNET options but refuses all option negotiations that disagree with + the NVT characteristics defined by the TELNET protocol (see [6]), + does not echo, and expects command lines to end with (ASCII + code 13 (octal 15) followed by code 10 (octal 12)). Character + echoing and line editing is expected to be handled by the user host + for the benefit of the user. + + Mail systems and other programs are also expected to be able to + access and understand the service. Each command reply can have + multiple line responses with text understandable by the novice user. + Each command is encoded so as to make it easy for a program to parse + the lines and extract interesting information, such as whether the + operation was successful. + +THE PROTOCOL + + Given the developing nature of the protocol and its intent, the + command lines are composed of a command (case ignored) followed by + white space, the argument(s) and a . The white space is + required if any arguments are supplied but the arguments are + optional. White space following the command and any optional + arguments are ignored. + + := [ ] [] + + := [] | | + + Coded response lines have the rigid format of a 3-digit decimal code + followed by a space or a dash followed by text composed of characters + within the ASCII range 32 to 126 (octal 40 to 176) with at the + end of the line. The dash after the 3-digit code indicates at least + one more response line will be supplied while the space indicates the + current response line is the last one. + + := + + := | "-" + + + +Elvy & Nedved [Page 3] + + + +RFC 915 Month Year +Network Mail Path Service + + + := ASCII characters in the range 32 to 126. + + Some of the successful response text to certain commands have rigid + formats so programs can extract path information. The commands that + have format restrictions are clearly noted and the response format is + documented with the command. + + The response codes are in the range from 200 to 599 inclusively. The + following paragraphs provide the break down for each digit. + + The first, most significant, digit is the success indicator. It + breaks down into the simple success and total failure responses but + includes the ability to communicate a temporary failure condition and + the need for further information that has worked so well for SMTP [5] + and other similiar protocols. The codes are: + + 2xx Positive reply. + + 3xx Intermedate reply. Positive acknowlegement but more + information is neccessary. + + 4xx Temporary error. Try again later. + + 5xx Permanent error. Do not retry. + + The second digit is used to classify the response to provide a flavor + for certain types of success. The flavor is apparent in providing the + response on whether a host name is known by a domain name server or + not. The codes are: + + x0x Command related response. + + x1x Connection related response. + + x2x Database related response. + + x3x Domain transition related response. + + x4x Data added response. + + x5x Data deleted response. + + x6x Data modified response. + + + + + + +Elvy & Nedved [Page 4] + + + +RFC 915 Month Year +Network Mail Path Service + + +BASIC IMPLEMENTATION + + The minimum implementation is the support of three commands: HELP, + PATH and QUIT. The HELP command provides some level of documentation + and possibly lists the known addressing or communication protocols. + The PATH command takes as a required argument a user name or id + followed by a "@", followed by a domain style host name whose domain + components may be an addressing protocol, a communication + environment, or an unofficial or colloquial domain. + + S: (server listens on port 117) + U: (user connects to port 117) + S: 210-Welcome to the CMU network mail path service. + S: 210 Type 'HELP' for help. + U: help + S: 200-The server currently knows about the following mail worlds: + S: 200- BITNET,UUCP,CSNET,.AC.UK,EARNET,JANET,CDNNET + S: 200-Use the PATH command with "user@host.world" to get the + S: 200 ARPA-Internet mail address. + U: path root@inria.uucp + S: 220 philabs!mcvax!inria!root@SEISMO.ARPA + U: quit + S: 211 Bye bye. + S: (server closes connection) + +DETAILED PROTOCOL DESCRIPTION + + The protocol is designed to provide a flexible but conservative + mechanism for providing responses and adding experimental or extended + commands. + + + + The server responds with a message indicating the status of the + server and optional information. + + 210 Greeting message indicating the server is ready. + + 410 The server is down for some unknown reason for a short + time. + + 510 The server is unavailable. + + HELP [] + + The server can respond with general help information about the + server, about the specific topic described by "arg", or it can + + +Elvy & Nedved [Page 5] + + + +RFC 915 Month Year +Network Mail Path Service + + + indicate that something is temporarily wrong with the HELP + facility. It is strongly recomended that the general HELP + command documentation be implemented and expanded. + + 200 General or specific documentation given. + + 220 Documentation given from a database. + + 421 Service temporarily unavailable. + + 501 Command not implemented or topic not known. + + PATH @ + + The server normally responds with either the mail path that + will work for the given mailbox address or indicates the domain + style host name is unknown. If the database is in transition or + inconsistent, a temporary or permanent error can be supplied. + + 220 Rigid format route given. + + 230 Rigid format route given. Domain servers should be + used. + + 420 Database problems. Try again later. + + 501 Invalid argument form or null argument given. + + 520 No such host found in database. + + 521 Host name is ambiguous. + + When a route is supplied with the 2xx success responses. It has a + fixed format with a one-line response. The format is as follows: + + <3-digit-code>@ + + The "local-part" and "domain" components are defined under the + SMTP protocol [5] and are intended to be used over SMTP + connections. + + QUIT + + Respond and close the server down. + + 211 Close the connection down. + + + +Elvy & Nedved [Page 6] + + + +RFC 915 Month Year +Network Mail Path Service + + + One special code is reserved and is used for a special case. The code + is 412 and is sent when the server has been waiting for a response + for more then 2 minutes and has decided to timeout the connection. + After the "412 " is sent, the server may close or + possibly abort the connection. + + Because of the somewhat experimental nature of the server, additional + commands are expected to be added as they become needed. No + restrictions are placed on the names of these experimental commands + other then the must not conflict with the basic commands and are not + allowed to be abbreviated (i.e., "SEAR" can not be used for + "SEARCH"). + +PATH COMMAND ARGUMENTS + + It is important to understand that the server is an aid to users that + may have minimal amount of information about the host. Therefore the + PATH command takes domain style host names that may be complete or + incomplete specifications for the host and may be common or + colloquial domain names. The servers look through the entire database + for anything that matches and try to find the best answer + disregarding any local domain information. If several hosts have the + same nickname or alias and lack distinguishing domain components, the + server returns an error response containing all of the hosts found. + Some implementation may even break down the host name and indicate in + error messages that even though it did not find the host, it found + something else that might be what the user wanted. + +MAIL PATH SERVICE AND DOMAINS + + As mentioned previously, the mail path service is not intended to be + a replacement or a parallel service to the domain name system. It is + a stop gap measure and, when most of the domain name system is in + place, will probably be disabled on some or most of the hosts with + the service. + + Mail systems should check the domain name servers for the specified + host before trying a mail path server. The mail path servers should + be modified when one or more domain servers are in place to check if + a host is part of the domain system and to generate an error or an + indication (but still include the path information) if a host is + found to be a part of the domain system. + + The names used by the mail path servers have no official standing in + the ARPA-Internet community and have colloquial origins. The domain + name components are based on the adminstrative entities involved + whereas many of the current unofficial common domain style names for + + +Elvy & Nedved [Page 7] + + + +RFC 915 Month Year +Network Mail Path Service + + + non-ARPA-Internet hosts are based on the protocol used, the relay + host used, or some acronym that someone dreamed up. Only a few of + the current domain style names that are privately in use are expected + to be used by the ARPA-Internet community when the domain name + service is in use by the majority of the ARPA-Internet community. + +CAVEATS + + The greatest problem with the new service, as implemented, is that it + reports paths from the service host rather than from the user's host. + This is due to the nature of software. It would be more convenient + if it reported a correct path from the caller's host, but this would + require a different method of database management (a method which + could quickly compute the path from the caller's machine or a machine + which would be willing to keep updated databases for each host (which + is impractical)). + + Two minor problems exist with the database used by the software. Many + relay hosts exist in several different protocol or addressing name + spaces but under different names. The current software cross + referencing for the multiple protocol relay hosts is done by hand, + but, given the seeming reliability of these relay hosts, the problem + does not appear to be significant. The second problem is that the + data should be collected from the actual relay hosts to ensure + correctness, but in many cases this is impossible. + +EXAMPLES + + Find a route to CMU-CC-TE in the CARNEGIE part of MAILNET for user id + EN0C: + + S: (server listens on port 117) + U: (user connects to port 117) + S: 210-Welcome to the CMU network mail path service + S: 210 Type 'HELP' for help. + U: path EN0C@CMU-CC-TE.CARNEGIE.MAILNET + S: 220 EN0C%CMU-CC-TE%CARNEGIE.MAILNET@MIT-MULTICS.ARPA + U: quit + S: 211 Bye bye. + S: (server closes connection) + + + + + + + + + +Elvy & Nedved [Page 8] + + + +RFC 915 Month Year +Network Mail Path Service + + + Find a route to a host which has an unknown addressing system or + communication protocol and for which the name may be an alias: + + S: (server listens on port 117) + U: (user connects to port 117) + S: 210-Welcome to the CMU network mail path service + S: 210 Type 'HELP' for help. + U: path mss@dartvax + S: 220 mss%dartmouth@CSNET-RELAY.ARPA + U: quit + S: 211 Bye bye. + S: (server closes connection) + + Find a route to a host that is known by a very long domain style name + but is not in the current ARPA-Internet host tables: + + S: (server listens on port 117) + U: (user connects to port 117) + S: 210-Welcome to the CMU network mail path service + S: 210 Type 'HELP' for help. + U: path rob@vax1.cent.lanc.ac.uk + S: 220 rob%vax1.cent.lanc@UCL-CS.ARPA + U: quit + S: 211 Bye bye. + S: (server closes connection) + + Find a route to a host without any additional information and the + name is discovered to be ambiguous: + + S: (server listens on port 117) + U: (user connects to port 117) + S: 210-Welcome to the CMU network mail path service + S: 210 Type 'HELP' for help. + U: path brad@pitt + S: 521-Several hosts found under the name of 'pitt', try one of: + S: 521-brad@pitt.UUCP + S: 521-brad@pitt.CSNET + U: path brad@pitt.CSNET + S: 220 brad%pitt@CSNET-RELAY.ARPA + U: quit + S: 211 Bye bye. + S: (server closes connection) + + + + + + + +Elvy & Nedved [Page 9] + + + +RFC 915 Month Year +Network Mail Path Service + + +ACKNOWLEDGEMENTS + + The original protocol was documented by Marc Elvy for a server that + he and Alan Langerman built. The server used the pathalias software + created by Steve Bellovin, as modified by Peter Honeyman and Robert + T. Morris, to maintain the host to host connection database. The + software provided a way for people to make sense out of the jungle of + UUCP hosts. The Info-Nets@MIT-MC mailing list, created and maintained + by Robert Krawitz, made the CMU and Harvard mail path projects aware + of each other and the people on the list provided many of the mail + relay databases that are in use by the mail path servers. The + original server may be accessed through TCP port 117 on harvard.arpa + -- the "pathto" program that runs under 4.2BSD UNIX may be obtained + as a front end to the server from RFC915@HARVARD.ARPA. + + The current protocol scope was changed by Rudy Nedved to cover + BITNET, CSNET, MAILNET and other "mail networks" and further refined + by Marc Elvy, Alan Langerman and others. + + Comments should be sent to RFC-915@HARVARD.ARPA or mailed (via the + U.S. Postal Service) to: + + Marc A. Elvy + 108 Aiken Computation Laboratory + 33 Oxford Street + Harvard University + Cambridge, MA 02138 + + (617) 495-5849 + + Rudy Nedved + Department of Computer Science + Carnegie-Mellon University + Schenley Park + Pittsburgh, PA 15213 + + (412) 578-7685 + + + + + + + + + + + + +Elvy & Nedved [Page 10] + + + +RFC 915 Month Year +Network Mail Path Service + + +REFERENCES + + [1] Crocker, D. "Standard for the Format of ARPA Internet Text + Messages". RFC 822, Department of Electrical Engineering, + University of Delaware, August, 1982. + + [2] Mockapetris, P. "Domain Names - Concepts and Facilities". + RFC 882, USC/Information Sciences Institute, Novemeber, 1983. + + [3] Mockapetris, P. "Domain Names - Implementation Specification". + RFC 883, USC/Information Sciences Institute, Novemeber, 1983. + + [4] Postel, J. "Transmission Control Protocol- DARPA Internet + Program Protocol Specification". RFC 793, USC/Information + Sciences Institute, September, 1981. + + [5] Postel, J. "Simple Mail Transfer Prootcol". RFC 821, + USC/Information Sciences Institute, August, 1982. + + [6] Postel, J., and J. Reynolds. "Telnet Protocol Specification". + RFC 854, USC/Information Sciences Institute, May, 1983. + + [7] Postel, J. "Domain Name System Implementation Schedule". + RFC 897, USC/Information Sciences Institute, Feburary, 1984. + + [8] Reynolds, J., and J. Postel. "Assigned Numbers". RFC 923, + USC/Information Sciences Institute, October, 1984. + + [9] Su, Z., and Postel, J. "The Domain Naming Convention for + Internet User Applications". RFC 819, SRI International, + August, 1982. + + + + + + + + + + + + + + + + + + +Elvy & Nedved [Page 11] + -- cgit v1.2.3