Out-of-net host addresses for mail
RFC 754

Document Type RFC - Unknown (April 1979; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 754 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text