Out-of-net host addresses for mail
RFC 754
|
Document |
Type |
|
RFC - Unknown
(April 1979; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
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