rfc754.txt

RFC 相关的技术文档

RFC 754                                                        J. Postel
                                                                     ISI
                                                            6 April 1979



                   Out-of-Net Host Addresses for Mail

There is now interest in sustantially extending the scope of the
computer mail system used in the ARPANET to allow communication of
voice, fax, graphics, as well as text information between users in
different networks as wells as within the ARPANET.

The discussion of a transition from the current ARPANET sndmsg
environment and mechanisms to a more general internet environment and
richer mechanisms must consider techniques for continued activity during
the transition.  In addition, there is a current need for a mechanism to
support the interaction of the several already existing NSW-like message
environments with the ARPANET message environment.

This memo discusses some possible alternatives for computer mail
addressing for hosts outside the ARPANET in the short term.  This memo
is hopelessly Tenex oriented in its descriptions and examples.

It helps to keep a few goals in mind while considering the alternative
solutions:

Goals:

   1) Minimum Change to Existing Software.

   2) Maximum User Acceptance.

   3) Maximum Compatibility with the future Internet Message
   Environment.

   4) Minimum Special Transition Software.

These goals are to some degree incompatible, so the evaluation should be
expected to involve a trade off.

At this point, it would be good to have a model of the current situation
and mechanisms of the ARPANET message environment.  It is assumed the
reader understands it well enough to dispense with a long description of
how a message gets from A to B.  The important thing is to note the
types of players in the picture.  There are:

   message composition (or sending) programs (e.g., Hermes, SNDMSG), in
   general there are several message composition programs for each type
   of operating system or host in the network,




Postel                                                          [page 1]


RFC 754                                                     6 April 1979
Out-of-Net Host Addresses for Mail



   mailers,

   mail servers (i.e., FTP servers) that receive the mail coming into at
   host and deposit it in mailboxes,

   message processing (or reading) programs (e.g., Hermes, MSG, RD), in
   general there are several message processing programs for each type
   of operating system or host in the network,  and note that the more
   developed mail are both reading and sending programs.

Messages are transmitted as a character string to an address which is
specified "outside" the message.  The destination host ("YYY") is
specified to the sending (or user) FTP as the argument of the "open
connection" command, and the destination user ("XXX") is specified to
the receiving (or server) FTP as the argument of the "MAIL" (or "MLFL")
command.  In Tenex, when mail is queued this outside information is
saved in the file name ("[---].XXX@YYY").

The proposed solutions are briefly characterized.

Proposed Solutions:

   This first pass at describing the solutions is rather brief and
   intended to set the scene for a subsequent discussion based on
   examples.

   A) SINGLE MAILBOX

      This solution suggests that all mail for another network be routed
      to a single mailbox on a forwarding host on the ARPANET.  The FTP
      server would naturally put all the mail for this mailbox into a
      single file to be examined by a routing deamon process.  The
      routing deamon process would use information in new header lines
      to determine the actual destination.

      Format:

         Outside:  [---].NSW-MAIL@FWDR

         Inside:   To:       NSW-MAIL@FWDR
                   From:     Sam@ISIB
                   NSW-User: Joe








Postel                                                          [page 2]


RFC 754                                                     6 April 1979
Out-of-Net Host Addresses for Mail



   B) GLOBAL NAMES INSIDE

      This proposal suggests that all mail for users in another network
      be sent to a single mailbox on a forwarding host.  The FTP server
      would naturally put all the mail for this mailbox into a single
      file to be examined by a routing deamon process.  The routing
      deamon process would use information in existing header lines to
      determine the actual destination.

      Format:

         Outside: [---].NSW-MAIL@FWDR

         Inside:  To:   Joe@NSW
                  From: Sam@ISIB

   C) GLOBAL NAMES OUTSIDE

      This proposal suggests that mail for users in another network be
      sent to distinct per user mailbox names on a forwarding host.  The
      FTP server would somehow put all the mail for these mailboxes into
      a single file to be examined by a routing deamon process.  The
      routing deamon process would use information in existing header
      lines to determine the actual destination.

      Format:

         Outside: [---].Joe@FWDR or [---].Joe@NSW

         Inside:  To:   Joe@NSW
                  From: Sam@ISIB

   D) STRUCTURED NAMES

      This proposal suggests that mail for users in another network be
      sent to distinct per user mailbox names on a forwarding host,
      however, these mailbox names would have a common "network" part
      and a unique "user" part.  By recognizing the common part the FTP
      server would put the mail and the mailbox name into a single file
      to be examined by a routing deamon process.  The routing deamon
      process would use mailbox name information to determine the actual
      destination.








Postel                                                          [page 3]


RFC 754                                                     6 April 1979
Out-of-Net Host Addresses for Mail



      Format:

         Outside:  [---].NSW-Joe@FWDR

         Inside:  To:   NSW-Joe@FWDR
                  From: Sam@ISIB

Before further examination of the advantages and disadvantages of these
proposals, it would be well to have some more detailed criteria in mind
to help expose the degree to which the goals are met.

Criteria:

   1) What changes are needed?

   2) How many instances of the change need to be implemented?

   3) What information does the routing deamon use?

   4) How does the "answer" command work?

   5) How is the name space used?

   It is particularly instructive to work through examples with a
   mixture of mailbox destinations in the ARPANET and other networks in
   each of the "To:" and "CC:" fields and to see what happens when one
   wants to send an answer to all, just the "To:", or just the "CC:", or
   just the "From:" or "Sender:" mailboxes.

Solutions Reconsidered:

   It is easier to talk about these things in terms of examples.  In the
   following "NSW" is an example of a network name.  "FWDR" is a host
   name, or nickname for the forwarding host.  Also note that for all of
   these solutions it is assumed that host tables can have alternate or
   nicknames for hosts, e.g., FWDR could map to 86 while ISI also maps
   to 86, although this is not essential.

   In addition, all these solutions provide a single forwarding point
   from the ARPANET into the destination net.

   All forwarded messages are handled by a routing deamon which lives in
   the FWDR host.

   Also note that the information shown as the "outside" information is
   the Tenex representation.  The key thing is the mailbox argument
   value that is passed to the FTP server is the one in the string



Postel                                                          [page 4]


RFC 754                                                     6 April 1979
Out-of-Net Host Addresses for Mail



   "[---].XXX@YYY", not anything from the header.  Only the string "XXX"
   is passed to the FTP server.

   A) SINGLE MAILBOX

      Example:

         Outside:  [---].NSW-MAIL@FWDR

         Inside:   To:       NSW-MAIL@FWDR,Bill@ISIA
                   CC:       Jeff@ISIB
                   From:     Joe@ISIB
                   NSW-User-To: SAM,Fred
                   NSW-User-CC: Bob,Mike

         or

         Outside:  [---].NSW-MAIL@FWDR

         Inside:   To:       NSW-MAIL@FWDR,Bill@ISIA
                   CC:       Jeff@ISIB
                   From:     NSW-MAIL@FWDR
                   NSW-User-To: SAM,Fred
                   NSW-User-CC: Bob,Mike
                   NSW-User-From: Paul

      Every mail composition program has to change to make it easy for
      users to put the "NSW-User:" line in the header.  Every mail
      reading program has to change to notice and make use of this line.
      In an "answer" command the mail processing program has to know to
      copy this line into the answer message.  The deamon has to examine
      the inside message header to find the "NSW-User:" line and forward
      the message to the users listed there.  If there is a message that
      has both NSW and ARPANET mailboxes in both the "To:" and "CC:"
      lines, then it seems there must be both a "NSW-Users-To:" and a
      "NSW-Users-CC:" lines if it is to be possible to send an answer to
      just the users in the "To:" lines.  If there is another network,
      e.g. PRNET, then another set of header lines must be introduced,
      e.g. PRNET-USER-To: etc., that is up to four new lines per network
      (To, CC, From, Sender).

      This solution has the advantage of saving some transmissions:
      when several of the destination mailboxes are in NSW, the sending
      program sends just one copy to the FWDR and routing deamon, the
      routing deamon sends copies to all NSW users it finds.  If this is
      not done, the deamon would have difficulty avoiding sending
      multiple copies to each destination user.



Postel                                                          [page 5]