rfc915.txt

RFC 的详细文档！

            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><SP><local-part>@<domain><CRLF>

      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 <timeout msg>" 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 [e-mail]
      S: 220 [e-mail]
      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 [e-mail]
      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 [e-mail]
      S: 220 [e-mail]
      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: [e-mail]
      S: [e-mail]
      U: path [e-mail]
      S: 220 [e-mail]
      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 [e-mail].

   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 [e-mail] or mailed (via the
   U.S.  Postal Service) to:

      Marc A. Elvy
      108 Aiken Computation Laboratory
      33 Oxford Street
      Harvard University
      Cambridge, MA 02138

      [phone]

      Rudy Nedved
      Department of Computer Science
      Carnegie-Mellon University
      Schenley Park
      Pittsburgh, PA 15213

      [phone]












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]