rfc915.txt

RFC 相关的技术文档

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:

      [e-mail]

      "[e-mail]"@MIT-MULTICS.ARPA

      ihnp4!cmucsg![e-mail]

      [e-mail]

      [e-mail]

   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,
   "[e-mail]" would be translated by the server to
   "[e-mail]". 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 <CRLF> (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 <CRLF>. 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.

      <cmdline> := <cmd> [<WS> <args>] [<WS>] <CRLF>

      <WS> := [<WS>] <WS> | <TAB> | <SPACE>

   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 <CRLF> 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.

      <rspline> := <digit><digit><digit><cont><rtext><CRLF>

      <cont> := <SPACE> | "-"



Elvy & Nedved                                                   [Page 3]



RFC 915                                                       Month Year
Network Mail Path Service


      <rtext> := 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 "[e-mail]" to get the
      S: 200 ARPA-Internet mail address.
      U: path [e-mail]
      S: 220 philabs!mcvax!inria![e-mail]
      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.

      <user connects to server>

         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 [<arg>]

         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 <user>@<host>

         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.