As per Relevance of the word messages, we have this rfc below:
Network Working Group V. Cerf (ARPA
Request for Comments: 771 J. Postel (ISI
September 1980
MAIL TRANSITION
This is a draft memo and comments are requested
The principal aim of the mail service transition plan is to
orderly support for computer mail service during the period
transition from the old ARPANET protocols to the new
protocols
This plan covers only the transition from the current text
mail in the ARPANET environment to text computer mail in an
environment. This plan does not address a second transition
text only mail to multimedia mail [10,11].
The goal is to provide equivalent or better service in the
Internet environment as was available in the ARPANET environment
During the interim period, when both protocol environments are
use, the goal is to minimize the impact on users and
software, yet to permit the maximum mail exchange connectivity
It is assumed that the user is familiar with both the ARPANET
Internet protocol environments [1-8]. The Internet protocols
designed to be used in a diverse collection of networks including
ARPANET, Packet Radio nets, Satellite nets, and local nets (e.g.,
Ethernets, Ring nets); while the ARPANET protocol are, of course
limited to the ARPANET
The Internet protocol environment specifies TCP as the host-to-
transport protocol. The ARPANET protocol environment specifies
as the host-to-host transport protocol. Both TCP and NCP
connection type process-to-process communication. The problem in
transition is to bridge these two different
communication systems
The objective of this plan is to specify the means by which
ARPANET computer mail services may be extended into the
system without disruptive changes for the users during
transition
1
September 1980 RFC 771
Mail Transition Plan
MODEL OF MAIL
The model of the computer mail system taken here separates the
composition and reading functions from the mail transport functions
In the following, the discussion will be hoplessly TOPS20-oriented
We appologize to users of other systems, but we feel it is better
discuss examples we know than to attempt to be abstract
In the ARPANET mail service, composition and reading is done
user programs such as HERMES, MSG, MM, etc., while mail
is done by system programs such as MAILER (sending) and
(receiving).
One element of the ARPANET mail service is the assumption that
source of mail can have a direct interprocess
connection (via the NCPs) to every destination for mail. (There
some cases where special handling and forwarding of mail
this assumption.)
Mailbox names are of the form "MAILBOX@HOST", and it is assumed
MAILBOX is a destination mailbox on that host
The messages are actually transmitted according to the provisions
the File Transfer Protocol. Mail may be transimitted via either
control connection (MAIL command), or via a data connection (
command). In either case, the argument specifies only the
since the destination host is assumed to be the host receiving
transmission
For example: messages sent from Postel at USC-ISIF to Cerf
USC-ISIA would arrive at ISIA with the argument "Cerf" but
indication of the host
COMPOUND AND ALTERNATE
Mailboxes are of the form "mailbox@host" where mailbox is usually
name like "Postel" and host is a host identifier like "USC-ISIF".
some cases it will be useful to allow the host to be a compound
such as
USC-
ARPANET-
SATNET-
PPSN-
HOST1.
LSCNET/
2
RFC 771 September 1980
Mail Transition
or even the name of an organization
The only restriction is that "@" not appear in either the "mailbox
or the "host" strings in the destination address
To actually send the message the mailer program must convert the
string into the physical address to which to transmit the message
This name-to-address conversion is typically done by looking the
up in a table and finding the physical address in another field
that table entry. This means that all the compound and
names (and any other alternate names or synonyms) must also be in
host table
HIDDEN
Sometimes the mailbox part of the destination address is a
name and is used to mark a set of mailboxes which are not really
the host at all, but rather on another host which is connected
this host in a non-standard way
It is important to users of computer mail that replies to
may be easily composed with automatic assistance from the
processing programs. To preserve this capability it is
that a host understand the mailbox part of every address in
message it sends if the host part of the address is itself
That is, for every message, in every header field, in every
"m@h", host h must understand all values of m. Thus when a
prepares a message it should check all the addresses that appear
the header and for any address whose host part is this host
mailbox part should be verified
3
September 1980 RFC 771
Mail Transition Plan
THE TRANSITION
The basic ground rules for the transition are
1. ARPANET mailbox names must continue to work correctly
2. No changes should be required to mail editor software
parses message headers to compose replies and the like
Specifically, non-ARPANET mailbox designators must
accommodated without change to the parsing and checking
of mail processing programs
3. Automatic forwarding of messages between NCP and
environments without user (or operator) intervention
For the communication of messages between NCP and TCP hosts a
relay service will be provided on a few hosts that implement both
and NCP. These will be "well known" in the same sense that
or ports for contacting Telnet or FTP servers are well known
To make use of these relay servers changes will be made to the
programs. The mailer program will be responsible for determining
the destination address of the message is directly reachable via
interprocess communication system it has available (TCP or NCP
both), or if the mail must be relayed. If the mail must be relayed
the mailer must choose a relay server and transmit the message to it
The basis for the decision the mailer must make is an expanded
name table. There will be a table which translates host names
physical addresses. The physical addresses in this table will be
32-bit Internet addresses. (This makes sense for even NCP-only hosts
since after 1 January 1981 even they must use 96-bit leader
which requires 24-bit ARPANET physical addresses). Each entry
this table will also have some flag bits
The flag bits will include information to indicate if the host
this entry is (1) a NCP host with "old tables", (2) a NCP host
"new tables", (3) a TCP host, or (4) some other kind of host.
TCP hosts are assumed to have "new tables". "Old tables" are
without these flag bits, while "new tables" do have these flags
A separate table may be useful to list the addresses of the
with relay servers
4
RFC 771 September 1980
Mail Transition
When a message is sent to a relay server, the control information (
the argument of the mail transfer command) must be augmented
include the destination host identifier
The relay server may accept messages to be relayed without
that destination mailbox is actually reachable. This means that
may later discover that the destination mailbox does not exist (
some other condition prevents mail delivery). To be able to
the error to the originating user, the mailbox (mailbox@host) of
originating user must be included in the argument of the
transfer command. If the argument does not contain the address
the originating user no error response is attempted. The
report, which is itself a message, does not carry an
address in the command argument to avoid the possibility of a
chain of error reports (however, an originator address does
the header).
Since the originating host will act as if the mail was
delivered when it is accepted by the relay server, it deletes
back up copies of the message it was keeping in case of errors.
this reason, the relay server must include the complete message
any error report it sends to the originator. The relay server
parse the addresses in the argument before accepting a message.
it does not understand how deliver locally, or both relay and
(if the originating address is present) to the message, it should
accept it
There are enough differences in the transmission procedure that
relay server will use a distinct mail transfer protocol,
from the file transfer protocol
MAIL TRANSFER
The mail trasfer protocol to be used by the relay server and all
hosts is documented in reference [9].
There are nine cases of mail exchange, the three by three matrix
(1) old-table NCP hosts, (2) new-table NCP hosts, (3) TCP hosts
There are also two transfer mechanisms: file transfer and
transfer. The diagonal is easy, each type of host can exchange
with other hosts of its type. The other cases are more subtle
5
September 1980 RFC 771
Mail Transition Plan
An old-table NCP host is assumed to have a table with 32-bit
addresses, but no flag bits. It has NCP and file transfer. It
not have the separate mail transfer protocol
An new-table NCP host is assumed to have a table with 32-bit
addresses, and the flag bits. It has NCP and file transfer. It
has the new separate mail transfer
An TCP host is assumed to have a table with 32-bit
addresses, and the flag bits. It has the new separate mail transfer
It probably has a file transfer, but does not use it for mail
1. Old-table NCP to Old-table
This transfer is direct and uses the old mechanisms -- NCP
file transfer
2. New-table NCP to Old-table
This transfer is direct and uses the old mechanisms -- NCP
file transfer
3. TCP to Old-table
This transfer must use a relay server. The first transfer (
the TCP host to the relay server) is via TCP and the mail
protocol. The second transfer (from the relay server to
old-table NCP) is via NCP and file transfer protocol
4. Old-table NCP to New-table
This transfer is direct and uses the old mechanisms -- NCP
file transfer
5. New-table NCP to New-table
This transfer is done with the NCP and the mail transfer protocol
that is, using the old interprocess communication system and
new mail transmission scheme
6. TCP to New-table
This transfer must use a relay server. The first transfer (
the TCP host to the relay server) is via TCP and the mail
protocol. The second transfer (from the relay server to
new-table NCP) is via NCP and mail transfer protocol
6
RFC 771 September 1980
Mail Transition
7. Old-table NCP to
This transfer must use a special relay server. The first
(from the old-table NCP to the relay server) is via NCP and
file transfer protocol. The second transfer (from the
server to the TCP host) is via TCP and mail transfer protocol
This relay server must be special because the messages coming
the old-table NCP host will not have the destination
information in the command argument. This relay server must
a list of registered TCP user mailboxes and their associated
host identifiers. Since such a registry could be
large and frequently changing (and will grow as more TCP
come into existence) it will be necessary to limit the
on the registry
8. New-table NCP to
This transfer must use a relay server. The first transfer (
the new-table NCP to the relay server) is via NCP and the
transfer protocol. The second transfer (from the relay server
the TCP host) is via TCP and mail transfer protocol
9. TCP to
This transfer is direct and uses the new mechanisms -- TCP and
mail transfer protocol
In general, whenever possible the new procedures are to be used
MULTIPLE
A substantial portion of the mail sent is addressed to
recipients. It would substantially cut the transmission
processing costs if such multiple recipient mail were
using the multiple recipient technique available for use in both
old file transfer protocol [12] and new mail transfer protocol [9].
The relay servers will attempt to use a multiple recipient
whenever applicable on transmitting messages, and will accept
commands when revceiving messages
7
September 1980 RFC 771
Mail Transition Plan
COMPOSITION AND READING
The impact on the mail composition and reading programs is minimal
If these programs use a table to recognize, complete, or verify
identifiers, then they must be modified to use the new table
To assist the user in replying to messages it will be important
all addresses in the header fields (TO:, CC:, etc.) be complete
both the mailbox and host parts. In some cases this has
previously been necessary since the addresses without host
could be assumed to be local to the originating host, and the
host was recorded by the receiving host. When the messages were
directly the originating host was the sending host, but when
are relayed the originating host will not be the host sending
mail to the destination host
8
RFC 771 September 1980
Mail Transition
[1] Cerf, V., "The Catenet Model for Internetworking," IEN 48,
DARPA/IPTO, July 1978.
[2] Postel, J., "Internet Protocol," RFC 760, USC/
Sciences Institute, NTIS ADA079730, January 1980.
[3] Postel, J., "Transmission Control Protocol," RFC 761,
USC/Information Sciences Institute, NTIS ADA082609,
January 1980.
[4] Postel, J., "Telnet Protocol Specification," RFC 764,
USC/Information Sciences Institute, June 1980.
[4] Postel, J., "File Transfer Protocol," RFC 765,
USC/Information Sciences Institute, June 1980.
[5] Postel, J., "Assigned Numbers," USC/Information
Institute, RFC 762, January 1980.
[6] Postel, J., "Internet Protocol Handbook," USC/
Sciences Institute, RFC 766, July 1980.
[7] Feinler, E. and, J. Postel, "ARPANET Protocol Handbook,"
NIC 7104, Network Information Center, SRI International
January 1978.
[8] Crocker, D., J. Vittal, K. Pogran, and, D. Henderson
"Standards for the Format of ARPA Network Text Messages,"
RFC 733 7104, Network Information Center, SRI International
November 1977.
[9] Sluizer, S. and, J. Postel, "Mail Transfer Protocol,"
USC/Information Sciences Institute, RFC rrr, September 1980.
[10] Postel, J., "Internet Message Protocol," USC/
Sciences Institute, RFC 759, August 1980.
[11] Postel, J., "A Structured Format for Transmission
Multi-Media Documents," USC/Information Sciences Institute
RFC 767, August 1980.
[12] Harrenstien, K., "FTP Extension: XRSQ/XRCP,"
SRI International, RFC 743, December 1977.
9
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
