As per Relevance of the word forwarding, we have this rfc below:
RFC 754 J.
6 April 1979
Out-of-Net Host Addresses for
There is now interest in sustantially extending the scope of
computer mail system used in the ARPANET to allow communication
voice, fax, graphics, as well as text information between users
different networks as wells as within the ARPANET
The discussion of a transition from the current ARPANET
environment and mechanisms to a more general internet environment
richer mechanisms must consider techniques for continued activity
the transition. In addition, there is a current need for a mechanism
support the interaction of the several already existing NSW-like
environments with the ARPANET message environment
This memo discusses some possible alternatives for computer
addressing for hosts outside the ARPANET in the short term. This
is hopelessly Tenex oriented in its descriptions and examples
It helps to keep a few goals in mind while considering the
solutions
Goals
1) Minimum Change to Existing Software
2) Maximum User Acceptance
3) Maximum Compatibility with the future Internet
Environment
4) Minimum Special Transition Software
These goals are to some degree incompatible, so the evaluation should
expected to involve a trade off
At this point, it would be good to have a model of the current
and mechanisms of the ARPANET message environment. It is assumed
reader understands it well enough to dispense with a long description
how a message gets from A to B. The important thing is to note
types of players in the picture. There are
message composition (or sending) programs (e.g., Hermes, SNDMSG),
general there are several message composition programs for each
of operating system or host in the network
Postel [page 1]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
mailers
mail servers (i.e., FTP servers) that receive the mail coming into
host and deposit it in mailboxes
message processing (or reading) programs (e.g., Hermes, MSG, RD),
general there are several message processing programs for each
of operating system or host in the network, and note that the
developed mail are both reading and sending programs
Messages are transmitted as a character string to an address which
specified "outside" the message. The destination host ("YYY")
specified to the sending (or user) FTP as the argument of the "
connection" command, and the destination user ("XXX") is specified
the receiving (or server) FTP as the argument of the "MAIL" (or "MLFL")
command. In Tenex, when mail is queued this outside information
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
intended to set the scene for a subsequent discussion based
examples
A) SINGLE
This solution suggests that all mail for another network be
to a single mailbox on a forwarding host on the ARPANET. The
server would naturally put all the mail for this mailbox into
single file to be examined by a routing deamon process.
routing deamon process would use information in new header
to determine the actual destination
Format
Outside: [---].NSW-MAIL@
Inside: To: NSW-MAIL@
From: Sam@
NSW-User:
Postel [page 2]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
B) GLOBAL NAMES
This proposal suggests that all mail for users in another
be sent to a single mailbox on a forwarding host. The FTP
would naturally put all the mail for this mailbox into a
file to be examined by a routing deamon process. The
deamon process would use information in existing header lines
determine the actual destination
Format
Outside: [---].NSW-MAIL@
Inside: To: Joe@
From: Sam@
C) GLOBAL NAMES
This proposal suggests that mail for users in another network
sent to distinct per user mailbox names on a forwarding host.
FTP server would somehow put all the mail for these mailboxes
a single file to be examined by a routing deamon process.
routing deamon process would use information in existing
lines to determine the actual destination
Format
Outside: [---].Joe@FWDR or [---].Joe@
Inside: To: Joe@
From: Sam@
D) STRUCTURED
This proposal suggests that mail for users in another network
sent to distinct per user mailbox names on a forwarding host
however, these mailbox names would have a common "network"
and a unique "user" part. By recognizing the common part the
server would put the mail and the mailbox name into a single
to be examined by a routing deamon process. The routing
process would use mailbox name information to determine the
destination
Postel [page 3]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
Format
Outside: [---].NSW-Joe@
Inside: To: NSW-Joe@
From: Sam@
Before further examination of the advantages and disadvantages of
proposals, it would be well to have some more detailed criteria in
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
mixture of mailbox destinations in the ARPANET and other networks
each of the "To:" and "CC:" fields and to see what happens when
wants to send an answer to all, just the "To:", or just the "CC:",
just the "From:" or "Sender:" mailboxes
Solutions Reconsidered
It is easier to talk about these things in terms of examples. In
following "NSW" is an example of a network name. "FWDR" is a
name, or nickname for the forwarding host. Also note that for all
these solutions it is assumed that host tables can have alternate
nicknames for hosts, e.g., FWDR could map to 86 while ISI also
to 86, although this is not essential
In addition, all these solutions provide a single forwarding
from the ARPANET into the destination net
All forwarded messages are handled by a routing deamon which lives
the FWDR host
Also note that the information shown as the "outside" information
the Tenex representation. The key thing is the mailbox
value that is passed to the FTP server is the one in the
Postel [page 4]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
"[---].XXX@YYY", not anything from the header. Only the string "XXX
is passed to the FTP server
A) SINGLE
Example
Outside: [---].NSW-MAIL@
Inside: To: NSW-MAIL@FWDR,Bill@
CC: Jeff@
From: Joe@
NSW-User-To: SAM,
NSW-User-CC: Bob,
Outside: [---].NSW-MAIL@
Inside: To: NSW-MAIL@FWDR,Bill@
CC: Jeff@
From: NSW-MAIL@
NSW-User-To: SAM,
NSW-User-CC: Bob,
NSW-User-From:
Every mail composition program has to change to make it easy
users to put the "NSW-User:" line in the header. Every
reading program has to change to notice and make use of this line
In an "answer" command the mail processing program has to know
copy this line into the answer message. The deamon has to
the inside message header to find the "NSW-User:" line and
the message to the users listed there. If there is a message
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
"NSW-Users-CC:" lines if it is to be possible to send an answer
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
(To, CC, From, Sender).
This solution has the advantage of saving some transmissions
when several of the destination mailboxes are in NSW, the
program sends just one copy to the FWDR and routing deamon,
routing deamon sends copies to all NSW users it finds. If this
not done, the deamon would have difficulty avoiding
multiple copies to each destination user
Postel [page 5]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
A problem arises about acknowledgements of mail receipt.
the normal ARPANET message delivery mechanisms will say the
is delivered when the FTP server puts the mail in the file for
routing deamon to examine. Second if the routing deamon
an message is to be forwarded to a nonexistent user, care must
used to notify the original sender unambiguously
Changes
all composition
B) GLOBAL NAMES
Example
Outside: [---].NSW-MAIL@
Inside: To: Joe@NSW, Bill@ISIA, Fred@
CC: Mike@NSW, Paul@NSW, John@
From: Sam@
Every mail composition program has to know that NSW is a
special host name, for which it uses a different mailbox
and sends to the FWDR host. The FTP server naturally puts all
NSW mail into a single mailbox file which the routing
examines. The "answer" command works fine. The routing
has to look at the inside header to determine where to forward
messages. It has to check the "To:" and "CC:" lines
The sending programs must also send just one copy to the FWDR
routing deamon, the routing deamon will send copies to all
users it finds. If this is not done, the deamon would
difficulty avoiding sending multiple copies to each
user. This is an advantage in terms of number of transmissions
A problem arises about acknowledgements of mail receipt.
the normal ARPANET message delivery mechanisms will say the
is delivered when the FTP server puts the mail in the file for
routing deamon to examine. Second if the routing deamon
an message is to be forwarded to a nonexistent user, care must
used to notify the original sender unambiguously
Changes
all sending
Postel [page 6]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
C) GLOBAL NAMES
Example
Outside: [---].Joe@
Inside: To: Joe@NSW, Bill@ISIA, Fred@
CC: Mike@NSW, Paul@NSW, John@
From: Sam@
No changes to mail composition or processing programs are needed
The FTP server has to put all the NSW users mail into a
mailbox file which the routing deamon examines. The cheapest
to do this is to put all the names of the NSW users in the
user forwarding file with the same destination ARPANET mailbox
This means the local users of the FWDR host and the users in
destination networks share the name space for user names.
routing deamon has to look at the inside header to determine
to forward the messages. It has to check the "To:" and "CC:"
lines
This appears to be the solution with the minimum change
existing software. The "answer" command works fine
There is a problem with the name space, for example, if
serves as FWDR host, then Fred@ISI and Fred@NSW cannot co-exist
Further, there is the database update problem. Every time a
user is added to NSW or any of the hosts in any of the nets
the FWDR host serves the forwarding file at the FWDR host has
be updated. The names added have to be unique so all user
assigned in NSW and all the hosts on all the networks served
the same FWDR host have to be oked by the "forwarding file
base administrator" before they can actually be used. Also
that Fred@NSW and Fred@PRNET cannot be routed through the
FWDR host
This doesn't work too well, if the sending programs are
changed they will send one copy of this message for each NSW
and all these copies will end up in the file to be examined by
routing deamon. If the FTP server code is not changed the
information will be lost and the routing deamon will have no
which NSW user this copy is for. To do the job right with
information available the routing deamon would have to keep
substantial record about each message it handled checking to
if it received for, and send a copy to, each intended
user
Postel [page 7]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
A problem arises about acknowledgements of mail receipt.
the normal ARPANET message delivery mechanisms will say the
is delivered when the FTP server puts the mail in the file for
routing deamon to examine. Second if the routing deamon
an message is to be forwarded to a nonexistent user, care must
used to notify the original sender unambiguously
Changes
ARPANET user forwarding file at FWDR
D) STRUCTURED
Example
Outside: [---].NSW-Joe@
Inside: To: NSW-Joe@NSW, Bill@ISIA, NSW-Fred@
CC: NSW-Mike@NSW, NSW-Paul@NSW, John@
From: Sam@
No changes to mail composition or processing programs are needed
The FTP server has to put all the NSW-x users mail into a
file which the routing deamon examines. The FTP server can
this on the recognition of the "NSW-" prefix without knowing
the legal individual users. In addition the FTP server puts
mailbox argument into the file with the message. This
necessary to avoid the loss of the "outside" information.
routing deamon can then look at the mailbox argument to
where to forward the messages. It need not look at the inside
the message at all. The "answer" command works fine
A problem arises about acknowledgements of mail receipt.
the normal ARPANET message delivery mechanisms will say the
is delivered when the FTP server puts the mail in the file for
routing deamon to examine. However, if the routing
discovers an message is to be forwarded to a nonexistent user,
deamon can easily tell the original sender the exact
user that is unreachable
Changes
FTP server at FWDR
Postel [page 8]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
Summary
A B C
Single Global Global
Mailbox Names Names
Inside
Criteria
1) What changes? Composer Composer None FTP
2) How many? 100 100 0 1
3) Routing information? New Old Old
Inside Inside Inside
4) "Answer" command? Changes Same Same
5) ARPANET name space 1 per 1 per 1 per 1
use? FWDR FWDR user
Goals
1) Software Change Bad Bad Good
2) User Acceptance Bad Good Good
3) Future Compatibility Bad Poor Poor
4) Transition Software Fair Good Bad
Conclusions
Solution D is recommended
Only solution D is based on the use of strictly "outside
information. Please note that the existing ARPANET
DELIVERY system is based strictly on the use of "outside
information only. Also note that the problems that keep coming
in ARPANET message processing & composition programs have to
with the different possibilities for syntax (and semanitcs) of
"inside" information. This is a major advantage of solution D
Postel [page 9]
RFC 754 6 April 1979
Out-of-Net Host Addresses for
Please note that the syntax NET-USER@FWDR in the examples is
the only form that could be used. Any of the following (or
others) would be fine
Net-User@FWDR User-Net@
Net/User@FWDR User/Net@
Net.User@FWDR User.Net@
Net.and.User@FWDR User.on.Net@
Postel [page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
