As per Relevance of the word response, we have this rfc below:
Network Working Group Marc A.
Request for Comments: 915 Harvard
Rudy
Carnegie-Mellon
December 1984
NETWORK MAIL PATH
STATUS OF THIS
This RFC proposes a new service for the ARPA-Internet community
requests discussion and suggestions for improvements.
of this memo is unlimited
The network mail path service fills the current need of people
determine mailbox addresses for hosts that are not part of
ARPA-Internet but can be reached by one or more relay hosts that
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
hosts with a mail path server
Currently many hosts that are not connected to the ARPA-
network can send mail to and receive mail from the ARPA-
community. The ARPA-Internet community sends mail using
addresses of the form "user@host" or "local-part@domain" [1, 5].
an effort to provide service to hosts not connected directly to
ARPA-Internet, mail maintainers have used the feature that
"local-part" of the mailbox address is locally interpreted to
specially encoded mail routing or relaying information.
encoded mailbox addresses have a variety of forms and have
common practice. For example
demco%ucb-ean.cdn%ubc.csnet@CSNET-RELAY.
"Rudy.Nedved%CMCCTE@CARNEGIE.MAILNET"@MIT-MULTICS.
ihnp4!cmucsg!ern@UT-SALLY.
mss.dartmouth@CSNET-RELAY.
nedved%CMCCTF.BITNET@WISCVM.
It is important that people be able to communicate, but it is
from the rampant confusion and frustration that something must
Elvy & Nedved [Page 1]
RFC 915 Month
Network Mail Path
provided to make it easier for people to address mail
non-ARPA-Internet hosts. The result, for a variety of reasons,
been the work and development of the Domain Name system
facilities [2, 3, 7, 9], and it is expected to make mailbox
be as simple as the current ARPA-Internet mailbox format (e.g.,
"user@domain").
How do people discover the special encoded addresses
non-ARPA-Internet host mailboxes until the domain name system
working and covering the majority of hosts in the mail world?
proposed solution to this problem is to provide a network service
the ARPA-Internet and a mail service for the non-ARPA-Internet
that, given a host and an optional addressing system or
protocol or some other piece of information, supplies the
address format for sending mail to that host. For example
"nedved@Carnegie.MAILNET" would be translated by the server
"nedved%Carnegie.MAILNET@MIT-MULTICS.ARPA". This memo covers
proposed network service
DOCUMENT
Unless otherwise noted, all numbers are in decimal
The term "host", as used in this document, describes one
system which may have more than one name associated with it. It
have a name for each network or mail connection it supports and
have several nicknames or aliases for the computer and/or for
set of network names that the computer has acquired
The network service is a connection based application on TCP [4].
server listens for TCP connections on the assigned port of 117 [8].
It responds to the connection with a coded greeting message and
for a command line. For each command line sent to the server,
server will respond with a coded message. The special command
causes the server to respond with a coded closing message and
the connection
Elvy & Nedved [Page 2]
RFC 915 Month
Network Mail Path
DESIGN
One of the goals is to provide the service to as many ARPA-
hosts as possible. In the current ARPA-Internet, experience has
that software people first implement TELNET/TCP [6] before any
network application or protocol. Therefore, it is a sub-goal
people be able to access the service using available programs (
minimal modifications) that implement TELNET/TCP. Therefore
TELNET/TCP on port 117 will work correctly. The server
TELNET options but refuses all option negotiations that disagree
the NVT characteristics defined by the TELNET protocol (see [6]),
does not echo, and expects command lines to end with (
code 13 (octal 15) followed by code 10 (octal 12)).
echoing and line editing is expected to be handled by the user
for the benefit of the user
Mail systems and other programs are also expected to be able
access and understand the service. Each command reply can
multiple line responses with text understandable by the novice user
Each command is encoded so as to make it easy for a program to
the lines and extract interesting information, such as whether
operation was successful
THE
Given the developing nature of the protocol and its intent,
command lines are composed of a command (case ignored) followed
white space, the argument(s) and a . The white space
required if any arguments are supplied but the arguments
optional. White space following the command and any
arguments are ignored
:= [ ] []
:= [] | |
Coded response lines have the rigid format of a 3-digit decimal
followed by a space or a dash followed by text composed of
within the ASCII range 32 to 126 (octal 40 to 176) with at
end of the line. The dash after the 3-digit code indicates at
one more response line will be supplied while the space indicates
current response line is the last one
:=
:= | "-"
Elvy & Nedved [Page 3]
RFC 915 Month
Network Mail Path
:= ASCII characters in the range 32 to 126.
Some of the successful response text to certain commands have
formats so programs can extract path information. The commands
have format restrictions are clearly noted and the response format
documented with the command
The response codes are in the range from 200 to 599 inclusively.
following paragraphs provide the break down for each digit
The first, most significant, digit is the success indicator.
breaks down into the simple success and total failure responses
includes the ability to communicate a temporary failure condition
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
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
for certain types of success. The flavor is apparent in providing
response on whether a host name is known by a domain name server
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
Network Mail Path
BASIC
The minimum implementation is the support of three commands: HELP
PATH and QUIT. The HELP command provides some level of
and possibly lists the known addressing or communication protocols
The PATH command takes as a required argument a user name or
followed by a "@", followed by a domain style host name whose
components may be an addressing protocol, a
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:
S: 200-The server currently knows about the following mail worlds
S: 200- BITNET,UUCP,CSNET,.AC.UK,EARNET,JANET,
S: 200-Use the PATH command with "user@host.world" to get
S: 200 ARPA-Internet mail address
U: path root@inria.
S: 220 philabs!mcvax!inria!root@SEISMO.
U:
S: 211 Bye bye
S: (server closes connection
DETAILED PROTOCOL
The protocol is designed to provide a flexible but
mechanism for providing responses and adding experimental or
commands
The server responds with a message indicating the status of
server and optional information
210 Greeting message indicating the server is ready
410 The server is down for some unknown reason for a
time
510 The server is unavailable
HELP []
The server can respond with general help information about
server, about the specific topic described by "arg", or it
Elvy & Nedved [Page 5]
RFC 915 Month
Network Mail Path
indicate that something is temporarily wrong with the
facility. It is strongly recomended that the general
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
will work for the given mailbox address or indicates the
style host name is unknown. If the database is in transition
inconsistent, a temporary or permanent error can be supplied
220 Rigid format route given
230 Rigid format route given. Domain servers should
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
fixed format with a one-line response. The format is as follows
<3-digit-code>@
The "local-part" and "domain" components are defined under
SMTP protocol [5] and are intended to be used over
connections
Respond and close the server down
211 Close the connection down
Elvy & Nedved [Page 6]
RFC 915 Month
Network Mail Path
One special code is reserved and is used for a special case. The
is 412 and is sent when the server has been waiting for a
for more then 2 minutes and has decided to timeout the connection
After the "412 " is sent, the server may close
possibly abort the connection
Because of the somewhat experimental nature of the server,
commands are expected to be added as they become needed.
restrictions are placed on the names of these experimental
other then the must not conflict with the basic commands and are
allowed to be abbreviated (i.e., "SEAR" can not be used
"SEARCH").
PATH COMMAND
It is important to understand that the server is an aid to users
may have minimal amount of information about the host. Therefore
PATH command takes domain style host names that may be complete
incomplete specifications for the host and may be common
colloquial domain names. The servers look through the entire
for anything that matches and try to find the best
disregarding any local domain information. If several hosts have
same nickname or alias and lack distinguishing domain components,
server returns an error response containing all of the hosts found
Some implementation may even break down the host name and indicate
error messages that even though it did not find the host, it
something else that might be what the user wanted
MAIL PATH SERVICE AND
As mentioned previously, the mail path service is not intended to
a replacement or a parallel service to the domain name system. It
a stop gap measure and, when most of the domain name system is
place, will probably be disabled on some or most of the hosts
the service
Mail systems should check the domain name servers for the
host before trying a mail path server. The mail path servers
be modified when one or more domain servers are in place to check
a host is part of the domain system and to generate an error or
indication (but still include the path information) if a host
found to be a part of the domain system
The names used by the mail path servers have no official standing
the ARPA-Internet community and have colloquial origins. The
name components are based on the adminstrative entities
whereas many of the current unofficial common domain style names
Elvy & Nedved [Page 7]
RFC 915 Month
Network Mail Path
non-ARPA-Internet hosts are based on the protocol used, the
host used, or some acronym that someone dreamed up. Only a few
the current domain style names that are privately in use are
to be used by the ARPA-Internet community when the domain
service is in use by the majority of the ARPA-Internet community
The greatest problem with the new service, as implemented, is that
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
if it reported a correct path from the caller's host, but this
require a different method of database management (a method
could quickly compute the path from the caller's machine or a
which would be willing to keep updated databases for each host (
is impractical)).
Two minor problems exist with the database used by the software.
relay hosts exist in several different protocol or addressing
spaces but under different names. The current software
referencing for the multiple protocol relay hosts is done by hand
but, given the seeming reliability of these relay hosts, the
does not appear to be significant. The second problem is that
data should be collected from the actual relay hosts to
correctness, but in many cases this is impossible
Find a route to CMU-CC-TE in the CARNEGIE part of MAILNET for user
EN0C
S: (server listens on port 117)
U: (user connects to port 117)
S: 210-Welcome to the CMU network mail path
S: 210 Type 'HELP' for help
U: path EN0C@CMU-CC-TE.CARNEGIE.
S: 220 EN0C%CMU-CC-TE%CARNEGIE.MAILNET@MIT-MULTICS.
U:
S: 211 Bye bye
S: (server closes connection
Elvy & Nedved [Page 8]
RFC 915 Month
Network Mail Path
Find a route to a host which has an unknown addressing system
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
S: 210 Type 'HELP' for help
U: path mss@
S: 220 mss%dartmouth@CSNET-RELAY.
U:
S: 211 Bye bye
S: (server closes connection
Find a route to a host that is known by a very long domain style
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
S: 210 Type 'HELP' for help
U: path rob@vax1.cent.lanc.ac.
S: 220 rob%vax1.cent.lanc@UCL-CS.
U:
S: 211 Bye bye
S: (server closes connection
Find a route to a host without any additional information and
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
S: 210 Type 'HELP' for help
U: path brad@
S: 521-Several hosts found under the name of 'pitt', try one of
S: 521-brad@pitt.
S: 521-brad@pitt.
U: path brad@pitt.
S: 220 brad%pitt@CSNET-RELAY.
U:
S: 211 Bye bye
S: (server closes connection
Elvy & Nedved [Page 9]
RFC 915 Month
Network Mail Path
The original protocol was documented by Marc Elvy for a server
he and Alan Langerman built. The server used the pathalias
created by Steve Bellovin, as modified by Peter Honeyman and
T. Morris, to maintain the host to host connection database.
software provided a way for people to make sense out of the jungle
UUCP hosts. The Info-Nets@MIT-MC mailing list, created and
by Robert Krawitz, made the CMU and Harvard mail path projects
of each other and the people on the list provided many of the
relay databases that are in use by the mail path servers.
original server may be accessed through TCP port 117 on harvard.
-- the "pathto" program that runs under 4.2BSD UNIX may be
as a front end to the server from RFC915@HARVARD.ARPA
The current protocol scope was changed by Rudy Nedved to
BITNET, CSNET, MAILNET and other "mail networks" and further
by Marc Elvy, Alan Langerman and others
Comments should be sent to RFC-915@HARVARD.ARPA or mailed (via
U.S. Postal Service) to
Marc A.
108 Aiken Computation
33 Oxford
Harvard
Cambridge, MA 02138
(617) 495-5849
Rudy
Department of Computer
Carnegie-Mellon
Schenley
Pittsburgh, PA 15213
(412) 578-7685
Elvy & Nedved [Page 10]
RFC 915 Month
Network Mail Path
[1] Crocker, D. "Standard for the Format of ARPA Internet
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
Program Protocol Specification". RFC 793, USC/
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
Internet User Applications". RFC 819, SRI International
August, 1982.
Elvy & Nedved [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
