From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 1-NOV-1989 12:34
To: MRGATE::"ARISIA::EVERHART"
Subj: Summary of network info.
Message-Id: <8911011558.AA13938@crdgw1.ge.com>
Received: From NUSC-NPT.NAVY.MIL by CRVAX.SRI.COM with TCP; Wed, 1 NOV 89 05:16:32 PDT
Date: 1 Nov 89 08:11:00 EST
From: "VAXA::LWS" <lws%vaxa.decnet@nusc-npt.navy.mil>
Subject: Summary of network info.
To: "info-vax!kl.sri.com" <info-vax!kl.sri.com@crvax.sri.com>
Date sent: 1-NOV-1989 07:44:21
There has been numerous requests for a summary of the info that I received
concerning networks. I tried to send it directly to some of you but it bounced
back. So Here are a few site mail manuals and a few refferences to books about
networking. This is veeeeerrrrrryyyyy llllooonnnnnggg so type N now if your not
interested. Also thanks for the Suzuki input--------\/ :-)
________________________________________________________________________________
|Louis W. Sefranek | INTERNET: LWS%VAXB.DECNET@NUSC-NPT.NAVY.MIL |
|Computer Services Division|----------------------------------------------------
|Aquidenck Data Corporation| definition of tension- |
|170 Enterprise Center | finding yourself behind a Ford Pinto, in front of |
|Middletown RI 02840 | an Audi 5000 and next to a Suzuki Samuri around a |
|(401)-847-7260 ext. 333 | curve. "????" |
--------------------------------------------------------------------------------
| Disclaimer: Daaa George? Daa what's that mean? You ignoramus, it's a |
| denial or a disavowal of legal claim. Daa well thanks George. |
________________________________________________________________________________
------------------------------------------------------------------------------
Please read "The Matrix" by John S. Quaterman
Digital Press 1989
Order # EY-C176E-DP
ISBN 1-55558-033-5
658 PAGES plus 60 pages of index
------------------------------------------------------------------------------
Hi Louis,
If you haven't already, send your request for information to
info-nets@think.com. Your question's a biggy. Indicate that you
are not a subscriber, or to subscribe:
send your request to: info-nets-request@think.com
Subject: <leave blank>
subscribe info-nets your_name
Good luck - ALB
Internet : alb%cod@aaaca1.sinet.slb.com (VMS)
: brushabe@aaaca2.sinet.slb.com (Unix)
Bitnet : brushaber%aaaca1.sinet.slb.com@slcs.slb.com
CompuServe: 71160.3505%compuserve.com@saqqara.cis.ohio-state.edu
M-Net : alb%m-net.ann-arbor.mi.us@cardiology.ummc.umich.edu
-----------------------------------------------------------------------------
Here are some references:
Quarterman, John S. The Matrix. Digital Press, 1990.
Quarterman, John S., and Josia C. Hoskins. "Notable Comput-
er Networks." In Communications of the ACM 29:932-971.
The first is a rather new book which you may not be able to find.
The second is a VERY good article which you should be able to find
in many libraries. I wrote some stuff for use around my own
university:
Wobus, John M. Electronic Mail Consultant's Guide. Comput-
ing & Network Services, Syracuse University, 1989.
This can be gotten by anonymous ftp from icarus.cns.syr.edu
in the file info/cgmail.txt. I appended more explicit instructions
for anonymous ftp below in case you haven't used it.
John Wobus
Syracuse University
P.S. The Internet address in your signature is not valid.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
To use ftp, you need to be on a host on the Internet.
(1)Type: ftp icarus.cns.syr.edu
(2)It prompts you
for username;
type: anonymous
(3)It prompts you
for password;
type: anonymous
(4)Type: get info/cgmail.txt cgmail.txt
(5)Type: quit
Now you have the file cgmail.txt.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Syracuse University Electronic-Mail Consultant's Guide
John M. Wobus
Communications & Development
Computing & Network Services
Syracuse University
June 29, 1989
Document Number: CGMAIL-1
(c) Syracuse University Computing & Network Services 1989.
Copying, in whole or in part, is permitted only for educational
purposes and copies must include this copyright notice. Copying
or republishing for commercial advantage is prohibited. For per-
mission to republish or distribute, write to: Director of Com-
puting & Network Services, Syracuse University, Skytop Office
Building, Syracuse NY 13244.
ABSTRACT
This guide provides a lot of background information for solv-
ing electronic-mail problems at Syracuse University. It includes
an overview of the world of electronic mail among colleges and
universities, describes idiosyncracies of networks and systems
available at Syracuse University and provides an extensive glos-
sary of terms peculiar to college and university electronic mail.
Abstract ii
PREFACE
Electronic mail among universities is a babel. There are many
different electronic-mail networks that serve universities, most
of which are interconnected forming an enormous "network of net-
works" which no one completely understands. If a user gives
another user his or her electronic-mail address, it may be obvi-
ous how to send a message, but it may not. Various computers
cannot reach other computers, but often they can in non-obvious
ways.
Most university people send electronic mail to few other
sites. If some of these sites are on networks requiring special
addresses, then the sender either must learn something about how
electronic mail is delivered or must seek the advice of someone
who does. The aim of this guide is to serve as an overview and
as a reference for people who are often faced with these prob-
lems. It gives a brief overview of electronic mail and offers
definitions of many terms one may come across. It serves as a
companion to [5], which is a "bag of tricks" for reaching various
mail networks.
Syracuse University Electronic-Mail Consultant's Guide iii
CONTENTS
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . ii
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 1
This document . . . . . . . . . . . . . . . . . . . . . . . 2
Overview of World-Wide Electronic Mail . . . . . . . . . . . . 3
Format of Messages . . . . . . . . . . . . . . . . . . . . . . 5
Address Formats . . . . . . . . . . . . . . . . . . . . . . 7
"Routing" or "Forwarding" Mail . . . . . . . . . . . . . 8
Qualifiers . . . . . . . . . . . . . . . . . . . . . . . 9
Mail Transfer Agents . . . . . . . . . . . . . . . . . . . . 11
Internet Mail . . . . . . . . . . . . . . . . . . . . . . . . 13
Qualifiers . . . . . . . . . . . . . . . . . . . . . . . . 14
Mail Exchangers . . . . . . . . . . . . . . . . . . . . . 15
Reaching Sites off the Internet . . . . . . . . . . . . . 16
What Can Your Computer Reach? . . . . . . . . . . . . . . 16
BITNET Mail . . . . . . . . . . . . . . . . . . . . . . . . . 18
The Columbia MAILER . . . . . . . . . . . . . . . . . . . 19
Qualifiers and Domains . . . . . . . . . . . . . . . . . . 20
Reaching Sites off BITNET . . . . . . . . . . . . . . . . 21
What Can Your Computer Reach? . . . . . . . . . . . . . . 21
Systems at Syracuse University . . . . . . . . . . . . . . . 22
IBM PCs, Compatibles, & Macintoshes . . . . . . . . . . . 22
ICARUS . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Public Workstation Cluster . . . . . . . . . . . . . . . . 23
RODAN . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SUAIS . . . . . . . . . . . . . . . . . . . . . . . . . . 23
SUMVS . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Sun Workstations . . . . . . . . . . . . . . . . . . . . . 24
SUNRISE . . . . . . . . . . . . . . . . . . . . . . . . . 24
SUVM . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Unix Systems . . . . . . . . . . . . . . . . . . . . . . . 25
VMS Systems . . . . . . . . . . . . . . . . . . . . . . . 25
The Easiest Way to Reach Nearly Anywhere . . . . . . . . . . 26
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 33
Contents iv
Appendix A: Electronic Mailing Lists . . . . . . . . . . . . 34
Subscribing and Cancelling Subscriptions . . . . . . . . . 34
Finding Out About Lists . . . . . . . . . . . . . . . . . 36
Syracuse University Electronic-Mail Consultant's Guide v
INTRODUCTION
Electronic mail is the exchange of messages between people
through a computer or computers joined by computer network. The
sender enters a message and an electronic-mail address. If the
recipient is on the same computer, then the mail software simply
stores the message where the recipient can read it.
If the sender and recipient are on different computers, then
the mail must be transferred through a data-communications net-
work from one computer to the other before it is stored for the
recipient. If the computers are not on the same network, then
the message must first be delivered to a computer which can move
it from one network to the other (an electronic-mail gateway).
If there is not a gateway joining the sender's and recipient's
networks, then the message might have to pass through intervening
networks using more gateways. And, of course, there are separate
groups of networks which share no gateways, so mail cannot be
delivered from one to the other. Among the world-community of
universities and colleges, there are a surprising number of net-
works which are interconnected allowing thousands of institutions
to exchange electronic mail.
PROBLEMS
There is no universal way of addressing an electronic message.
Different data-communications networks are incompatible, having
been developed by different groups of people, each using their
own hardware and software. Typically, each type of network has
its own way of addressing messages. If a colleague tells you his
or her electronic-mail address, it is likely to work if you are
both on the same network and the same type of computer. If not,
you might have to modify the address in order to make it work.
The rules for modifying addresses are as diverse as the different
networks and computers that make up our world-wide collection of
networks. If you are lucky, the electronic-mail software that
you are using to send the mail might do this address manipulation
for you (i.e., it might have some of these rules programmed in
it). This greatly simplifies sending some mail, but no program
incorporates all the rules (things change too quickly) and you
may even find that you need to compensate for your mail program's
manipulations as you try to figure out how to create a workable
address. The ability to build addresses thus requires some
knowledge of the software that handles electronic mail from your
computer to each of the networks you need to reach.
Syracuse University Electronic-Mail Consultant's Guide 1
THIS DOCUMENT
This document provides you with background information for
solving electronic-mail problems. Specific "tricks" are recorded
in another document, [5], which is separate so it can be kept
up-to-date. This document starts with an overview of the "world
of university electronic mail", describes the format used for
most electronic mail, describes the idiosyncracies of the systems
and the electronic-mail networks that serve Syracuse University,
lists a procedure for sending electronic mail nearly anywhere,
and finishes with an extensive glossary giving explanations of
specialized terms as well as various electronic-mail networks and
programs.
Introduction 2
OVERVIEW OF WORLD-WIDE ELECTRONIC MAIL
Colleges, universities, and other research institutions have
developed cooperative electronic-mail networks that span sites
throughout the United States and beyond. Large (multi-user) com-
puters, typically administered by the "computing services"
department or individual academic departments are tied together
by LANs, network gateways, and leased telephone lines. The com-
puters are assigned names and "electronic-mail addresses" of the
users are formed (according to explicit rules) out of the name of
the computer and the "username" or "sign-on name" of the individ-
ual user. The computers offer their users a program or programs
to enter and read the messages.
Furthermore, the major cooperative electronic-mail networks
have been interconnected by "electronic-mail gateways", computers
which are attached to more than one of these networks and trans-
fer electronic mail back and forth between them. The gateways
typically require extra information to be included in the message
to direct it first, to the gateway, and then tell the gateway
where to send it on. On many computers, software for entering
and sending electronic mail has been enhanced to direct mail
through the gateways. On some others, alternative programs have
been developed to do this.
The result of all this is a giant "network of networks" which
serves many thousands of computers at thousands of institutions,
serving at least a million people at these institutions. How-
ever, because any participating institution is free to add a
gateway to yet another network, no one really knows how to reach
all possible destinations or how large the network-of-networks
is. For example, many corporate networks are tied through gate-
ways, but very often, the gateway to a corporate network has
deliberate, software-implemented restrictions to help the corpo-
ration control such things as dissemination of trade secrets,
marketing strategy, or statements on the parts of individuals
that could be mistaken for corporate positions.
The main electronic-mail networks used to transfer electronic
mail among colleges, universities, and other research institu-
tions are BITNET (which includes "BITNET-proper" as well as
NETNORTH and EARN), the UUCP network, CSNET, and the Internet
(which includes ARPANET as well as NSFnet and all its regional
networks). All these and more are tied together with gateways.
Among the other networks tied together are similar, but smaller
or more specialized networks, corporate networks, commercial net-
works, and networks serving other countries or other regions of
the world. Networks that are deliberately kept separate include
commercial networks (who may be trying to avoid encouraging
"cooperative" electronic mail when they are trying to sell such a
service), corporate networks, and classified military networks.
Syracuse University Electronic-Mail Consultant's Guide 3
Syracuse University is a member of BITNET and NYSERNet (a part
of the Internet), and has software to facilitate the delivery of
mail to all the networks named above as well as others. Thus we
will discuss BITNET and the Internet at length. Numerous other
networks are briefly described in the glossary.
Overview of World-Wide Electronic Mail 4
FORMAT OF MESSAGES
The most common message format is commonly known as RFC822 and
is defined in [2]. It is the official format for the Internet
and a variant of it is the most common format for messages on
BITNET. It makes an electronic message look something like a
memo (with lines at the top labeled "To:", "Date:", etc.) but
has an exact definition so that software can be written to help
manipulate such messages. In this section, we will give an over-
view of RFC822 format. For a complete explanation, consult [2].
RFC822 format divides messages into two overall sections:
"message header" and the "message body". They are separated by
the first "empty" line in the message. The message body (after
this empty line) can contain anything. The message header is
strictly defined. Each line in the header either starts with a
label (a word followed by a colon, such as "Date:") or is a con-
tinuation of a line that does, in which case it starts with one
or more "blank" characters. We will ignore continuation lines in
the rest of our explanation of the header--just remember that any
line in the header may be continued.
A legal RFC822 header must have at least three lines: a
"Date" line, a "From" line, and a destination line marked by
"To", "cc", or "bcc". They may be in any order as may all the
lines of the header. The date is nearly exactly specified, but
you will often see mail with illegal date formats. RFC822's
exacting specification of the date format is helpful: it lets
programs sort messages according to the date, for example. The
"From" and destination lines hold electronic-mail addresses of
the sender and recipient of the message. We will discuss the
format of such addresses in more detail below.
+---------------------------------------------------------------+
| Date: 21 Jun 89 13:18:04 DST |
| From: mmroe@suvm |
| To: jjdoe@suvm |
| |
| Hi. |
| |
| Figure 1: Example RFC822 message: at its simplest. |
+---------------------------------------------------------------+
The destination line may hold a list of addresses, separated
by commas.
There are numerous additional "optional" lines which may be in
the header. Some of these are:
Syracuse University Electronic-Mail Consultant's Guide 5
Sender Holds the address of a person (or program) who sent
this message on behalf of the person whose address is
listed in the "From" line.
Reply-to Holds the address which should receive the reply. It
is unnecessary if replies should be sent to the address
listed in the "From" line.
Subject Holds a word, phrase, or sentence for the convenience
of the sender and recipient. It is intended to hold a
summary or describe the nature of the message.
Resent-? When you send a message that you receive on to another
person, this may be marked in the header by simply add-
ing three lines: "Resent-to:", "Resent-from:", and
"Resent-date:". Unfortunately, they are not well
defined; for example, there is not complete agreement
about what to do when the message is re-sent yet
another time.
In-Reply-To:
Holds something to identify the message you are reply-
ing to. It may be, but is not necessarily a Message-
ID.
The following lines are usually added to the header as it is
transferred through intervening computers and finally delivered:
Return-path
Holds an address which will reach the sender, as deter-
mined by the intervening computers that delivered the
mail.
Received Holds information about a mail system (mail transfer
agents) that relayed the message.
Message-ID
Holds an identification string assigned to the message
by the sending computer.
Comments Holds text (like the subject). It is intended to allow
the addition of a small amount of additional text to
the message without disturbing the message body.
There are some other lines used less often. If you want to
invent your own, lines beginning with an "X-" are set aside for
that purpose. Here is an example message-header with lots of
lines:
Format of Messages 6
+---------------------------------------------------------------+
| Return-Path: <smith@DG-RTP.DG.COM> |
| Received: from ucbarpa.Berkeley.EDU |
| by jade.berkeley.edu (5.61.1/1.16.22) |
| id AA24755; Wed, 21 Jun 89 20:31:44 PDT |
| Received: from RELAY.CS.NET by ucbarpa.Berkeley.EDU |
| id AA01355; Wed, 21 Jun 89 19:58:14 -0700 |
| Received: from dg-rtp.dg.com by RELAY.CS.NET |
| id aa10152; 21 Jun 89 17:36 EDT |
| Received: from rtp46.rtp.dg.com (rtp46) by dg-rtp.dg.com |
| id AA03542; Wed, 21 Jun 89 17:16:43 edt via SMTP |
| Received: by rtp46.rtp.dg.com (1.00/4.7) |
| id AA13489; Wed, 21 Jun 89 17:17:32 edt |
| From: Lynn Smith <smith@DG-RTP.DG.COM> |
| Message-Id: <8906212117.AA13489@rtp46.rtp.dg.com> |
| Subject: Billings and the rest of the world |
| To: info-billings@ucbarpa.Berkeley.EDU |
| Date: Wed, 21 Jun 89 17:17:28 EDT |
| Cc: Mark Ditroff <ditroff@DG-RTP.DG.COM> |
| X-Mailer: ELM [version 2.2 PL0] |
| |
| Figure 2: Example of a long message header. |
+---------------------------------------------------------------+
ADDRESS FORMATS
A "From:", "Sender:", "Reply-to:", or "Return-path:" field has
an electronic-mail address in a style defined by RFC822. A
"To:", "cc:", or "bcc:" field holds one such address or a list of
such addresses, separated by commas. In this section, we will
describe this format. Given a computer with the name "SUVM" and
a username of "MMROE", here are some examples of the address that
demonstrate the legal formats:
+---------------------------------------------------------------+
| MMROE@SUVM |
| MMROE@suvm |
| Mary Roe <MMROE@SUVM> |
| Mary M Roe <MMROE@SUVM> |
| "Mary M. Roe" <MMROE@SUVM> |
| MMROE@SUVM (Mary M. Roe) |
| |
| Figure 3: Example RFC822 addresses. |
+---------------------------------------------------------------+
The basis of all the formats is the username and the computer's
name joined with an "at" sign (@) between. Some other relevant
points:
Syracuse University Electronic-Mail Consultant's Guide 7
* The receiving computer is allowed to distinguish usernames by
case so the case of its letters must be preserved. Many
types of computers ignore the case, so mail-sending programs
that ignore this stricture work a large percentage of the
time.
* Angle brackets (<>) may be placed around the address. Any
words placed before the angle brackets are ignored by the
software but mail software should keep them intact and they
may be inserted for the benefit of the recipient.
* Quoted strings using double quotes (") may also be placed
before the angle brackets.
* Pairs of parenthesis () mark the beginning and end of "com-
ments" within the header line. They may be used within
addresses.
Following are some addresses with problems:
+---------------------------------------------------------------+
| Mary M. Roe <MMROE@SUVM> |
| Mary Roe, 443-9999 <MMROE@SUVM> |
| |
| Figure 4: Example bad RFC822 addresses. |
+---------------------------------------------------------------+
* Words, numbers, and quoted strings may be placed before the
angle-bracketed address. Other, "special" characters may
not. Much software will ignore a period, but commas are used
to separate addresses in address lists, and any mail software
will fail trying to interpret whatever comes before the comma
as a separate address.
Ideally, the software used to compose and send the message would
take care of making sure the addresses are correct, but this is
not always the case.
"Routing" or "Forwarding" Mail
It is often necessary for the sender to "route" mail: if the
computer that you are sending from cannot send directly to the
recipient's computer, perhaps there is a third computer which can
receive from yours, can send to your recipients, and will inter-
pret certain address forms as instructions to forward the mes-
sage. These are also referred to as "in-care-of" addresses: you
are sending the mail to an address "in care of" another computer.
Here are some example forms:
Format of Messages 8
+---------------------------------------------------------------+
| jjdoe%farnode@icarus |
| farnode!jjdoe@icarus |
| @icarus:jjdoe@farnode |
| |
| Figure 5: Example addresses that forward mail. |
+---------------------------------------------------------------+
These each direct mail first to ICARUS, asking ICARUS to forward
the mail to jjdoe@FARNODE. Some points:
* Though RFC822 allows the use of percent (%) or exclamation
point (!) in usernames, any special interpretation (i.e.,
forwarding) is left up to the receiving system. In other
words, this is not an RFC822 rule; it is a convention which
RFC822 allows. Many systems, particularly Unix systems,
interpret the percent sign this way, but this is no RFC822
requirement. The use of the exclamation point is less uni-
versal, and is used mainly to forward to certain types of
networks (UUCP networks).
* The use of the additional at-sign (@) and colon (:) is the
method for forwarding mail specified by RFC822, but it is not
universally implemented.
An example of an illegal way to specify forwarding is:
+---------------------------------------------------------------+
| jjdoe@farnode@icarus |
| |
| Figure 6: Example of illegal address. |
+---------------------------------------------------------------+
In fact, the predecessor to RFC822 allowed this and much software
still interprets it as you might expect.
Qualifiers
Our discussion has ignored qualifiers, which are extra words
appended to the end of the name of the computer, joined to it
with an intervening period (.).
Syracuse University Electronic-Mail Consultant's Guide 9
+---------------------------------------------------------------+
| icarus.cns.syr.edu |
| |
| Figure 7: The name of a computer with qualifiers. |
+---------------------------------------------------------------+
RFC822 defines them, but says nothing about how they are used.
They are simply part of the name of the computer as far as RFC822
is concerned. Networks that utilize RFC822 for the transmission
of mail have their own definitions of what the qualifiers mean.
We will discuss qualifiers in the discussion of Internet and
BITNET mail.
Format of Messages 10
MAIL TRANSFER AGENTS
In our discussion of RFC822 format, we brought up the term
mail transfer agent with no explanation. The function of compos-
ing and sending a message is often divided into composing the
message (entering and editing it), and the actual sending. A
program which does the latter is called a mail transfer agent.
This division of function is motivated by the fact that a sepa-
rate mail transfer agent is often designed to do more than simply
send outgoing messages. Other typical capabilities include:
* Inspecting incoming mail, interpreting in-care-of addresses
and resending the mail on accordingly.
* Inspecting the destination addresses of outgoing mail and
using special procedures to route it if necessary.
For example, the mail transfer agent might be programmed to rec-
ognize addresses on some other electronic-mail network and route
the message through a gateway to that network. This might
require rewriting the destination address as an in-care-of
address or it might require further manipulation of the mes-
sage.(1)
* Acting as gateways between different electronic-mail net-
works. A single mail transfer agent can do the same task for
two different electronic-mail networks. This puts it in the
position to move mail from one network to the other.
A related task is that the mail transfer agent may be programmed
to rewrite all the addresses in each copy of the message sent so
that the recipient can use any of the addresses. Following is an
example demonstrating this process:
+---------------------------------------------------------------+
| To: mmroe%finalc@ournode |
| From: jjdoe@firstc |
| |
| Figure 8: Example To: and From: fields. |
+---------------------------------------------------------------+
---------------------
(1) Such rewriting of addresses in the header by the mail trans-
fer agent is sometimes called "munging" them.
Syracuse University Electronic-Mail Consultant's Guide 11
+---------------------------------------------------------------+
| To: mmroe@finalc |
| From: jjdoe%firstc@ournode |
| |
| Figure 9: Example of To: and From: fields after rewriting. |
+---------------------------------------------------------------+
This example shows how the computer OURNODE's mail transfer agent
rewrites the header fields as it forwards the message. By
rewriting the "From:" field as an in-care-of address, it gives
the recipient an address which will route MMROE's answer back
through OURNODE. This is very helpful if the computers FIRSTC
and FINALC cannot exchange mail directly which is presumably the
reason why the original message was routed through OURNODE. An
example of this is the case where the two computers are on dif-
ferent networks.
Some examples of mail transfer agents are Sendmail on Unix,
PMDF on VAX/VMS, and IBM's SMTP program on VM/CMS.
Mail Transfer Agents 12
INTERNET MAIL
The Internet is a world-wide network made up of hundreds of
interconnected smaller networks acting cooperatively. It
includes university campus networks, nation-wide networks,
regional networks, corporate networks, and government networks,
all operating at different speeds. They all use a common proto-
col (TCP/IP) which is designed to make connected networks act as
one large network. For example, to sign on to a computer at
another university that's on that university's network, one needs
only that computer's official "Internet" name. Routing the data
to and from that computer through any number of intervening net-
works is handled automatically.
The Internet started with ARPANET, but has since grown to
where ARPANET is only a small part of it.(2) The Internet now
includes MILNET, Wideband, ESNet, DRI, NSFnet, various campus
networks of universities and other research institutions, various
corporate networks, and various networks serving other countries.
NSFnet includes the NSFnet "backbone" (a network linking about 13
sites across the continental United States) as well as several
networks serving regions of the country or certain important
sites. These include BARRNet, CICnet, JVNCNET, Merit, MIDNET,
MRNET, NCSANET, NorthwestNet, NYSERNet, PSCNET, SDSCNET,
SESQUINET, SURANET, USAN, and WESTNET.
Electronic mail from one computer on the Internet to another
is generally transmitted directly from the sender's computer to
the recipient's computer. More specifically, the sending comput-
er sends a query to the receiving computer to see if it is ready
to receive a message. If so, it sends the beginning of the mes-
sage, waiting for the receiving computer to request more. The
two computers continue to send the message, piece by piece until
the receiving computer sends an "acknowledgement" that it has
received the entire message. If the sending computer does not
receive this acknowledgement, it waits a while and tries again.
Here are some consequences of this method:
* The message is only transmitted if both the sending and
receiving computers as well as the entire intervening network
are working for a sufficiently long time to transfer the mes-
sage.
* The length of time necessary to transfer a message depends
upon the speed at which the network transmits data as well as
the speed at which the computers carry out their sending and
requesting operations. These, in turn, depend upon network
and computer load. A message may end up waiting until night
time to be delivered simply because that is when the loads go
down to the point where it can get through.
---------------------
(2) ARPANET is currently in the process of being disassembled.
Syracuse University Electronic-Mail Consultant's Guide 13
* The message takes up space on the sending computer until it
is delivered.
* Should the network or receiving computer lose the final
acknowledgement, then the message will be duplicated: the
receiving computer does not later realize that the next try
is really the message that it has already received. This
should be rare, but does happen and some circumstances exa-
cerbate the problem.
* As long as the message is waiting, the sending computer uses
up a bit of computer time and network capacity trying to send
it. Thus a computer that normally receives mail but is
turned off is wasting computer and network resources.
If a message is directed to a list of recipients including two or
more recipients on the same receiving computer, then only one
copy of the message needs to be transmitted to the receiving com-
puter.
QUALIFIERS
Qualifiers (as described in the section on the format of
electronic-mail addresses) are used on the Internet to designate
a heirarchical organization of all the computer names. The final
two qualifiers of the official Internet name of a computer desig-
nate the institution which owns it. For example, names ending
with ".syr.edu" belong to Syracuse University whereas those end-
ing with ".hp.com" belong to the Hewlett-Packard corporation.
These pairs are assigned to the institution by a central adminis-
tration for the Internet. Of these two, the very last qualifier
designates the type of institution or the location by country.(3)
Following are some of the final qualifiers used on the Internet:
edu designates an educational institution.
com designates a commercial institution.
mil designates a military institution.
gov designates a non-military government institution.
net designates an institution which provides networking
services.
org designates other institutions such as non-profit insti-
tutions.
---------------------
(3) Originally, all final qualifiers designated the type of
institution, but as networks in other countries were added to
the Internet, some countries wanted a set of names of their
own to administer.
Internet Mail 14
us designates an institution in the United States. Cur-
rent practice is to use this for certain small institu-
tions.
ca designates an institution in Canada.
Use of qualifiers before these last two are left to the insti-
tution. They may be used by the institution to divide the names
between departments as Syracuse University does (for example,
".cis.syr.edu" designates a name belonging to the School of Com-
puting and Information Science).
Thus qualifiers define "sets" of names whose administration
may be delegated heirarchically. These sets are called "domains"
and such a set is usually designated by its string of qualifiers,
so, for example, we may speak of the "syr.edu domain", which is
the set of all names that end with ".syr.edu".
It is important to note that as far as the Internet is con-
cerned, the qualifiers are part of its name for the computer.
The responsibility for supplying any qualifiers to make the
user's task easier belongs to the software on the sending comput-
er.
MAIL EXCHANGERS
The Internet supports the idea of "mail exchangers", computers
which receive mail for other computers. Essentially, this is an
automated method by which mail for one computer is sent in care
of another: if "computer A" is the designated mail exchanger for
"computer B", then any computer sending mail addressed to "com-
puter B" should send the mail to "computer A" instead, which
should be set up to deliver the mail properly. This facility is
useful for various purposes:
* If a computer is down a lot of the time, another computer,
which is up more often, can be its designated mail exchanger,
thereby collecting mail for it from throughout the world.
The mail exchanger would be set up to deliver the mail to the
receiving computer when it is up again. This is a courtesy
to the sending computer which does not have to waste so much
time trying to deliver the message and to the users of the
Internet since it reduces network load for the failed
attempts.
* A computer which is not on the Internet at all can be given
an Internet name. The mail can be delivered by giving it a
mail exchanger: a computer which does reside on the Internet
and which can deliver the mail, presumably through an entire-
ly different network.
There are a couple of other useful features of mail exchangers:
Syracuse University Electronic-Mail Consultant's Guide 15
* A computer may have several designated mail exchangers which
are prioritized. A sending computer can then try the mail
exchanger with the highest priority first, then try another
if that computer is down. This allows one to give mail a
chance to make its first step across the Internet if any of
several computers are running.
* A mail exchanger can be designated for an entire domain of
names. This can direct all mail addressed to an entire
institution to a single mail exchanger (or prioritized list
of mail exchangers), or can be used to make an entire network
which is not part of the Internet appear to be part of it,
for the purposes addressing electronic mail.
REACHING SITES OFF THE INTERNET
Computers on the Internet may send to numerous sites off the
Internet through three mechanisms:
* Mail exchangers.
* Special interpretation of addresses by the mail transfer
agent.
* Explicit in-care-of addressing.
Numerous domains have been established (using single mail exchan-
gers for entire domains) to handle networks associated with vari-
ous countries of the world, to make them appear to be part of the
Internet as far as electronic mail is concerned. See [5] for
some examples.
BITNET is an example of a network which is not handled by mail
exchanger. Many computers on the Internet support the qualifier
".bitnet", sending the mail to an appropriate gateway through
configuration of the mail transfer agent.
WHAT CAN YOUR COMPUTER REACH?
Unfortunately, not all software on the Internet is capable of
delivering electronic mail to all Internet computers. The gener-
al reason for this is that the rules for deciding where to send
electronic mail have been enhanced since the beginnings of the
Internet and not all software is up-to-date. Following are some
of the problems plaguing some Internet computers:
* Many Internet computers still use an old system of looking up
the name of a computer and deciding how to route data to it.
The old method was to look in a table (called the "host
table"), usually stored on a disk of the sending computer.
The newer method (called the "Domain Name System") uses the
Internet Mail 16
network itself to ask about the names. The Domain Name Sys-
tem allows individual institutions to maintain lists of their
own names, making them available to all, through the network.
The Internet now has so many names that host tables include
only a small fraction of them and would be impractically
large if they included all.
* An Internet computer may have more than one attachment to the
Internet. Internet software should try routing mail through
one attachment, and if it is not working, should try another
if there is one. Some computers on the Internet run software
which will give up after trying one.
* Many computers on the Internet do not look for designated
mail exchangers when they send a message.
Another source of differences in the capabilities of computers
on the Internet is that the mail transfer agents may be pro-
grammed differently. For example: many computers on the Internet
support the ".bitnet" qualifier, but not all.
Note that if you are sending mail from a computer which suf-
fers from one of these restrictions, you can often get the mail
delivered by sending it through another computer on the Internet
which does not suffer from the same restrictions, using in-care-
of addressing.
Syracuse University Electronic-Mail Consultant's Guide 17
BITNET MAIL
BITNET is a cooperative network of academic institutions.
BITNET, NETNORTH, and EARN actually form a single network serving
a large part of the world, but some of the administrative tasks
are divided three ways. NETNORTH is all the sites in Canada,
EARN is all the sites in Europe and the middle east, and BITNET
is all the rest though the vast majority are in the United
States. The rest of this discussion will refer only to BITNET
but applies to all three.
BITNET's basic function is to transport files. BITNET also
supports "interactive messages" which amount to single lines of
text sent from one user to another. The word "message" as used
with respect to BITNET often refers to these interactive messag-
es, thus you hear BITNET users say the redundant phrase
"electronic-mail message" to avoid confusion.
The files BITNET transports are in the format of IBM-card
input or IBM-lineprinter output. BITNET is actually built out of
networking software provided with the VM/CMS operating system
which was originally intended to tie together the I/O spooling
systems of two or more systems running VM/CMS. BITNET now sup-
ports systems other than VM/CMS systems, in particular, VAX/VMS
systems (which require the JNET networking software to join
BITNET) which now outnumber VM/CMS systems on BITNET.
Any BITNET user may send a file to any other BITNET user using
a BITNET address. BITNET addresses consist of a username and the
name of a computer, but are written in different forms:
+---------------------------------------------------------------+
| MMROE AT SUVM |
| MMROE@SUVM |
| MMROE@SUVM.BITNET |
| |
| Figure 10: Different forms of a single BITNET address. |
+---------------------------------------------------------------+
Different programs require different forms of the address. Each
BITNET computer has a BITNET name no longer than 8 characters can
do something useful with usernames of no more than 8 characters
as that is all BITNET supports.
BITNET itself consists of numerous computers tied together
with communications links to form a big "tree" shaped network.
When you send a file to someone on a computer not directly con-
nected to your computer, BITNET first copies the entire file to
the first computer on the route from your computer to the desti-
BITNET Mail 18
nation. When the file is again intact, it is copied again to the
next computer on the route until it reaches the computer used by
the recipient. Networks of this sort are known as "store-and-
forward" networks. Unlike the Internet, if part of BITNET is
down between you and the recipient, the file will go as far along
the route as it can, then wait for the next "link" to start func-
tioning again, then proceed.
An electronic-mail message on BITNET is simply a file sent
like any other file. Special commands have been devised to help
users compose, send, read, and store files used for mail. Con-
ventions have been established to aid in the management of
electronic-mail files: they normally have a fileclass of M and a
filetype of MAIL and are normally card-image files rather than
lineprinter files (BITNET carries along with the file some extra
information including a "class" as well as a filename and file-
type).
By convention, BITNET mail files use the RFC822 format.
Unfortunately, the standard VM/CMS command for composing
electronic-mail messages, NOTE, does not. BITNET does not
enforce the convention so sites are free to make up their own
electronic-mail file formats, and some do. This wreaks havoc on
the recipients of such messages who may be trying to use
electronic-mail programs that can usefully manipulate messages in
RFC822 format (e.g. reply to a message, sort it by date or by
sender, etc).
This ability to exchange files is shared by the large majority
of computers on BITNET, but not all. Some implement just enough
of this capability to exchange electronic mail, recognizing cer-
tain file characteristics (filetype and/or class) to identify the
file as mail and ignoring other files. Some may even demand a
certain format for the file such as RFC822. Other computers are
attached to BITNET through entirely non-standard means and
require the services of a mail transfer agent to receive mail.
THE COLUMBIA MAILER
The Columbia MAILER is one of several mail transfer agents
that are in wide use throughout BITNET. Others include PMDF
(which may be run on VAX/VMS machines) and IBM's SMTP program.
These latter two act as electronic-mail gateways between BITNET
and an internet, a function we will discuss later. The Columbia
MAILER runs under VM/CMS as a "virtual machine". At Syracuse
University, SUVM runs a Columbia MAILER under the name "BITMAIL".
To use the Columbia MAILER, programs for composing and sending
mail format it in RFC822 format and send it to the nearest Colum-
bia MAILER instead of directly to the recipient (on SUVM, EMAIL
does this). The Columbia MAILER, in turn, sends it to a mail
transfer agent on the same computer as the recipient which deliv-
ers it to the recipient. If there is no mail transfer agent on
Syracuse University Electronic-Mail Consultant's Guide 19
the receiving computer, then the Columbia MAILER sends the file
directly to the recipient. This method has several advantages
over the more direct method of sending mail on BITNET:
* It sends only a single copy of a message to a computer with
two or more recipients if there is a mail transfer agent on
the receiving computer to do the final delivery. This saves
BITNET network capacity.
* It can deliver mail to some BITNET computers which can only
receive mail through the services of a mail transfer agent.
* It can deliver mail to computers on other electronic-mail
networks.
* It can handle longer usernames and computer names than BITNET
can otherwise handle.
* It can use qualifiers to route mail.
Sites without Columbia MAILERs can get some or all of these
benefits by running a different mail transfer agent (e.g. PMDF)
or by offering the user special software to compose messages in
the formats required by gateways to transfer mail to other net-
works. Examples of the latter are the GMAIL program for VAX/VMS
systems and the SENDGATE program for VM/CMS systems. These must
be configured in a manner similar to the Columbia MAILER to take
the destination address and figure out what gateway should
receive the message and what format the gateway expects. SUNRISE
offers the GMAIL program with an unusual configuration: it sim-
ply sends all mail to BITMAIL, SUVM's Columbia MAILER. This
reduces maintenance and assures SUNRISE's users the same reach as
SUVM's.
QUALIFIERS AND DOMAINS
With mail transfer agents that can handle qualifiers, BITNET
has a domain scheme similar (on the surface) to Internet domains.
We will refer to this as the "BITNET domain scheme". Mail trans-
fer agents are configured to check destination addresses with a
table of domains, and send all mail destined for certain domains
to certain designated mail transfer agents. For example, all
BITNET mail directed to computers whose names end with ".SYR.EDU"
are directed by other Columbia MAILERs to BITMAIL, SUVM's Colum-
bia MAILER. Sites may use this mechanism to make the same set of
computer names available to both BITNET and Internet users, but
there is the danger that a site could do this inconsistently,
e.g. invent some BITNET names that look exactly like Internet
names but cannot be reached from the Internet.
BITNET Mail 20
REACHING SITES OFF BITNET
As was discussed above, mail transfer agents make the sending
of mail to non-BITNET sites straightforward. The mail transfer
agent identifies Internet addresses and sends such mail to a
BITNET/Internet gateway. There are many such gateways: SUVM has
one. There are three sites which have volunteered to allow other
BITNET sites to use their BITNET/Internet gateways (since not
every site has one of their own). These three are the City Uni-
versity of New York, Cornell, and Princeton. BITNET sites with-
out their own gateways generally configure their mail transfer
agents to send all Internet mail to the site closest to them-
selves. The BITNET computer-name INTERBIT refers to the computer
among these three which is nearest to your own.
Mail transfer agents also route through other gateways, reach-
ing numerous other electronic-mail networks. Generally, a BITNET
domain is defined (i.e., a qualifier is selected) to designate
the network and the mail transfer agent is configured to identify
such addresses and send the mail to the proper gateway with what-
ever additional manipulation is required.
WHAT CAN YOUR COMPUTER REACH?
Every month, a central BITNET administration redistributes the
latest list of names of BITNET computers as well as configuration
tables for the Columbia MAILER. Your computer's capabilities
depend upon how recently its tables have been updated.
Another source of differences is the fact that any BITNET site
may connect their computer to non-BITNET computers as if it were
on BITNET (i.e., using the same software) if they simply refrain
from registering it as a BITNET node. They can send mail to this
computer and to their computer it appears to be on BITNET, but
other BITNET sites cannot send to it.
The biggest factor determining what your computer can reach is
whether it runs a Columbia MAILER or one of the alternatives.
Computers that do can reach all of BITNET (including computers
requiring the services of a mail transfer agent to receive mail)
as well as computers on the Internet and numerous other
electronic-mail networks. Computers that do not can reach most
BITNET computers, but nothing else.
Syracuse University Electronic-Mail Consultant's Guide 21
SYSTEMS AT SYRACUSE UNIVERSITY
Here are various different kinds of computers found at Syra-
cuse University along with descriptions of how you use electronic
mail with them.
IBM PCS, COMPATIBLES, & MACINTOSHES
There is no specific program to use electronic mail from PC's
or Macintoshes since they are single user-systems. Only multi-
user systems should store received electronic mail because:
1. Mail addressed to computers that are turned off causes
problems. The mail waits, using computer storage in the
"sending computer" as well as computer and network time to
constantly check to see if the receiving computer is up
again. Many single-user computers are turned off part of
the time.
2. Single-user computers are generally not as secure as multi-
user computers.
3. Multi-user computers often have a professional administra-
tor who can handle mail-delivery problems.
4. Many users can otherwise use a number of different single-
user systems interchangeably. If someone were to send them
mail on such a system, they would either be forced to
return to it to check their mail.
Since people often reply to messages using "return addresses" or
"from addresses", sending mail from single-user systems can cause
problems.
You can use Kermit, Telnet, or TN3270 to reach a multi-user
system to which you are allowed access, then use its mail system.
There is a program (called POP) which allows you to use internet
mail on a multi-user system without using terminal emulation. We
have tried it, but do not yet support it.
ICARUS
Icarus is a "departmental" Unix system owned by CNS which pro-
vides no direct services to users, but may be used indirectly.
It is on the Internet and is one of the few computers on campus
which implement all the features necessary to deliver mail
throughout the Internet. This makes it a valuable first target
for in-care-of addressing.
Systems at Syracuse University 22
PUBLIC WORKSTATION CLUSTER
The Public Workstation Cluster is a set of Sun Workstations
for general academic use. They are on the Internet and all use
the Internet computer name ZOOKEEPER.CNS.SYR.EDU in their
electronic-mail addresses. They offer the user the RandMH pack-
age of mail commands, using Sendmail to transfer the mail.
The cluster's Sendmail recognizes the ".BITNET" qualifier and
routes such mail appropriately. It does not use the Internet
Domain Name System nor does it look for mail exchangers or alter-
nate Internet attachments.
RODAN
RODAN is a Gould Unix system for general academic use. It is
on the Internet and offers the user the RandMH package of mail
commands, using the Sendmail program to transfer the mail.
RODAN's Sendmail recognizes the ".BITNET" qualifier and routes
such mail appropriately. It uses the Internet Domain Name System
and looks for alternate Internet connections, but does not look
for mail exchangers.
SUAIS
SUAIS is an IBM MVS system for administrative use. It is on
BITNET and offers the user the EMC2 electronic-mail system.
SUAIS delivers incoming mail only if the file adheres to
EMC2's concept of a mail file, but does not require the use of a
mail transfer agent. It can deliver mail only to BITNET comput-
ers not requiring the help of a mail transfer agent for delivery.
SUMVS
SUMVS is an IBM MVS system for general academic use. It is on
BITNET and offers (through its APL subsystem) users the MAILMAN
electronic-mail system.
SUMVS can send electronic mail to all BITNET computers, but
requires the use of a mail transfer agent to receive incoming
mail. It can exchange mail with other electronic-mail networks.
SUMVS is not recommended for use with electronic mail since plans
are to discontinue its electronic-mail service.
Syracuse University Electronic-Mail Consultant's Guide 23
SUN WORKSTATIONS
Many departments have Sun Workstations for their own use.
Most of them are on the Internet. Different Sun Workstations on
campus are set up to use mail differently. Any can use Telnet
(or TN3270 if installed) to reach a multi-user system to handle
electronic mail. Some departments have set up mail programs that
use storage and return-addresses of multi-user systems to ease
the reception of mail.
The restrictions upon mail sent from such Sun Workstations
varies with the department.
SUNRISE
SUNRISE is a DEC VAX/VMS system for general academic use. It
is on BITNET and the Internet. It offers the standard VAX/VMS
command, MAIL, which invokes a program also known as VMSMAIL.
VMSMAIL is designed to send mail through a DECnet, but through
special addressing, can send mail via the JNET software to BITNET
and via the WIN/TCP software to the Internet. A separate user
mail program, GMAIL, composes and sends mail to mail-only BITNET
nodes and to other networks.
A problem associated with systems running JNET is that
VMSMAIL's reply command cannot reply to computers off of BITNET.
SUNRISE implements a partial solution which solves the problem
for replies to Internet computers: VMSMAIL's reply command
directs the return message directly through the Internet even if
it was received through BITNET.
SUNRISE's internet software does not use the Domain Name Sys-
tem, look for multiple addresses of Internet sites, or look for
mail exchangers. SUNRISE's MAIL command can send to all BITNET
computers that do not require the use of a mail transfer agent as
well as to the Internet. SUNRISE's GMAIL command can also send
mail to the rest of BITNET as well as to other electronic-mail
networks.
SUVM
SUVM is an IBM VM/CMS system for general academic use. It is
on BITNET and the Internet. Its command for composing electronic
mail, EMAIL, directs mail through SUVM's Columbia MAILER
(BITMAIL) and for Internet computers, through SMTP (part of the
VM TCP/IP software package). SUVM also has the standard, but
limited VM/CMS command to compose mail, NOTE. Reception of mail
is handled by the programs RDRLIST and PEEK.
SUVM's EMAIL can send to all BITNET computers, and to other
electronic-mail networks. It also sends mail to the Internet,
Systems at Syracuse University 24
using the Domain Name System, but does not look for mail exchan-
gers or alternate Internet attachments of receiving computers.
UNIX SYSTEMS
Some departments have Unix systems for their own use. Most of
these are on the Internet. There are a variety of different sets
of mail programs for sending and receiving mail on Unix systems,
so the capabilities of the systems vary.
VMS SYSTEMS
Some departments have DEC VAX/VMS systems for their own use.
Most are on a DECnet which interconnects the VMS systems on cam-
pus while others run either JNET or WIN/TCP. The capabilities of
the systems vary.
Syracuse University Electronic-Mail Consultant's Guide 25
THE EASIEST WAY TO REACH NEARLY ANYWHERE
Following is a simple procedure which will deliver a message
to any of a very large number of computers including virtually
all computers on BITNET and the Internet as well as those on many
other electronic-mail networks. It is a simpler alternative to
the procedure outlined in [5].
1. Try sending the message in care of SUVM.
2. If this fails, try sending the message from a computer on
the Internet in care of ICARUS.
This procedure is effective because SUVM has the best BITNET
software available for delivering mail can route mail through
numerous gateways to numerous other networks. ICARUS has the
best Internet software available.
The disadvantage is that the mail route is not necessarily the
most efficient: the message will be transferred to ICARUS or SUVM
before it leaves the campus. The procedure outlined in [5] pro-
duces a more straight-forward route.
The Easiest Way to Reach Nearly Anywhere 26
GLOSSARY
This glossary covers electronic-mail-related networks, pro-
grams, and other terms.
ACSNET This term has two unrelated meanings. At Syracuse Uni-
versity, this term refers to Academic Computing Servi-
ces Network, which attaches Academic Computing Servi-
ces' computers to many terminals and personal computers
throughout the campus as well as connections to the
telephone system for use by modems. ACSNET is also the
name of the Australian Computer Sciences Network which
is the primary network joining educational and research
institutions in Australia.
ARPANET One of the original national networks that supported
electronic mail. It was designed by the Department of
Defense to join sites which performed non-classified
research for the military.
BITMAIL The name of SUVM's "virtual machine" that runs the
Columbia MAILER.
BITNET A network of over 1000 computers throughout United
States and a few other countries. In a technical
sense, BITNET, NETNORTH and EARN make up a single net-
work so a computer on one can reach computers on any of
the three with equal ease. However, they are adminis-
tered separately.
BITNODE A command on SUVM which, given the BITNET name of a
computer, yields a little information about it.
BSMTP A modified form of SMPT used on BITNET between mail
transfer agents and with gateways.
Columbia MAILER
A mail transfer agent used by some BITNET computers
running the VM operating system (on IBM mainframes).
It supports the BITNET domain-name scheme and helps
send mail through gateways. SUVM runs the Columbia
MAILER under the name BITMAIL. Most other sites use
the name MAILER.
Crosswell MAILER
Another name for the Columbia MAILER.
CSNET A network serving computer-science research institu-
tions. It actually runs three different types of net-
works, an internet (part of the Internet), and X.25
network, and a protocol specifically developed for
CSnet that uses dialup connections. The three are con-
nected by a central gateway.
Syracuse University Electronic-Mail Consultant's Guide 27
DECnet A type of network developed by DEC. Various computers
running DEC software at Syracuse University form a DEC-
net capable of exchanging electronic mail. The Univer-
sity DECnet is shared with NMR Incorporated. DECnet
mail is of limited utility because of the small number
of machines that use it and there is no general gate-
waying capability to exchange mail between a DECnet-
only computer and a computer not on DECnet.
DNS Abbreviation for Domain Name System.
domain An Internet term for the set of Internet names of com-
puters that end with a specific set of qualifiers.
Domain Name System
A distributed database of names of computers maintained
by and for the Internet. Each institution enters and
maintains the names of their own computers and any com-
puter which needs a name uses the Internet to find it.
EARN The European Academic Research Network. See BITNET.
EMAIL The supported command on SUVM for sending mail. It
uses BITMAIL to route mail.
EMC2 A mail system which Syracuse University runs as an
application on SUAIS. It can send mail to normal
BITNET sites, but nowhere else.
ESNET A national network which is a component network of the
Internet.
EZMAIL An experimental mail command on SUVM. Not generally
available nor supported.
GMAIL A program that runs under the VMS operating system
which helps a user send mail through gateways to other
networks. It can only send mail, not receive mail. It
gives a VMS computer on BITNET approximately the same
"reach" as a VM computer that runs the Columbia MAILER.
GMAIL on SUNRISE has been configured to send all its
mail through BITMAIL on SUVM, giving it exactly BIT-
MAIL's reach.
HEPNET A national network for computers that do research on
high energy physics. It uses DECnet.
in-care-of addressing
An electronic-mail term for using an address that
routes a message first to one computer, then on to
another. The most usual way to do this is using a per-
cent sign (%). See the section on Internet Mail for
more details.
Glossary 28
Internet A large internet that serves more than 30,000 computers
and includes numerous international, national, region-
al, and campus networks.
internet A data-communications network built around the TCP/IP
family of protocols (as opposed to SNA or Appletalk,
etc).
JNET A software package which may be installed on a system
running the VMS operating system. It gives its system
the capability to join BITNET. It is essentially a
reimplementation of the function of RSCS.
Kermit A file transfer protocol which transfers files between
computers through asynchronous communications lines.
It is also the name for many programs including PC
terminal-emulation programs that implement the Kermit
protocol.
LISTSERV A program that runs on VM systems, managing mailing
lists. SUVM runs it under the name LISTSERV.
MAIL Surely a commonly used name for mail commands. VMS's
standard mail command is called "MAIL". RiceMAIL's
command to send mail is called "MAIL".
Mail Exchanger
An Internet term for a computer which has been desig-
nated to receive mail addressed to another computer.
The Internet Domain Name System manages a list of mail
exchangers for computers on the Internet. This term is
often abbreviated "MX".
Mail Transfer Agent
A generic name for software that takes a message from
the Mail User Agent, figure out where to send it first,
store it until it can be sent, send it, and possibly
retry if the first time fails.
Mail User Agent
A generic name for software to help the user read, com-
pose, and address messages.
MAILBOOK A command which is part of the RiceMAIL package and
which allows one to manipulate "NOTEBOOKS", files con-
taining copies of messages sent and received.
MAILER See Columbia MAILER.
Mailman A mail system written in APL used on Syracuse Universi-
ty's Sharp APL timesharing system. It can send and
receive mail through SUVM's BITMAIL. It is not recom-
mended as it will be phased out soon.
Syracuse University Electronic-Mail Consultant's Guide 29
MFENET A network which attaches physics departments of various
universities that are doing magnetic fusion research to
a supercomputer at Lawrence Livermore National Labora-
tories. It uses DECnet.
MMDF A mail transfer agent used by many Unix systems. It
was originally designed for use on CSNET, but is also
otherwise used on the Internet. It has roughly the
same function as Sendmail.
MX Abbreviation for Mail Exchanger.
NETNORTH A Canadian network of academic institutions. See
BITNET.
NOTE The standard VM/CMS command for sending electronic
mail. On BITNET, it has been largely replaced by com-
mands capable of sending mail off BITNET and to BIT-
NET's mail-only computers. See RiceMAIL and EMAIL.
NSFnet A collection of internets funded by the NSF to facili-
tate research funded by the NSF. All its component
networks are part of the Internet. They include BARRN-
et, CICnet, JVNCNET, Merit, MIDNET, MRNET, NCSANET,
NorthwestNet, NYSERNet, PSCNET, SDSCNET, SESQUINET,
SURANET, USAN, and WESTNET.
NYSERNet The New York Education and Research Network. A compo-
nent network of NSFnet and the Internet. Syracuse Uni-
versity's attachment to the rest of the Internet is
through NYSERNet.
PEEK The VM/CMS command to read incoming electronic-mail.
PMDF A mail transfer agent which can be run on VAX/VMS sys-
tems. It has roughly the same capabilities as MMDF and
Sendmail, but also allows VAX/VMS systems to act as
gateways between BITNET or similar networks, internets
and DECnets.
POP Post Office Protocol. A protocol designed to allow
single-user computers to access mail stored on another
computer (presumably a multi-user computer) without a
"terminal session". The aim is to let the user of the
small computer exchange electronic mail without having
to learn to use the computer that actually stores the
mail. Syracuse University has experimented with POP,
but does not provide it as a "supported" service.
PROFS An automated office system marketed by IBM which has
its own peculiar type of electronic mail. PROFS users
of computers on BITNET can exchange electronic mail
with other PROFS users of computers on BITNET. PROFS
also has some limited capabilities for sending to other
sites and importing mail from other sites.
Glossary 30
qualifier A part of a name of a computer following a period (.)
in the name. For example, the name
"ICARUS.CNS.SYR.EDU" has three qualifiers. Qualifiers
are used to designate domains of names.
RandMH A set of mail commands for Unix systems.
RDRLIST A VM/CMS command to aid in the reading of mail. It
displays one line about each message waiting to be
read.
RFC822 A mail protocol that defines the "headers" of mail sent
on the Internet. It is also used for many other
electronic-mail networks.
RiceMAIL A set of mail commands for VM/CMS systems including
MAIL and MAILBOOK.
RSCS A VM/CMS program which, with the use of synchronous
communications hardware and lines, can tie together
VM/CMS systems, giving them the ability to transfer
files from one to the other. It is the basis for
BITNET.
Sendmail The standard mail transfer agent provided with Berke-
ley's version of Unix.
SMTP A mail protocol that defines the "envelope" of mail
sent on the Internet. This is usually completely hid-
den from the users. SMTP is also the name of a mail
transfer agent provided with the IBM's VM TCP/IP soft-
ware, which can be used as an electronic-mail gateway
between a BITNET-style network and an internet.
SPAN The Space Physics Analysis Network. A national network
which connects NASA to many research institutions which
aid NASA in the analysis of data from space probes. It
is built around DECnet.
Telnet The internet protocol for managing a users interactive
session with a computer on an internet. Also, the usu-
al name of the command that provides this service. So
to the user, using the "telnet" command on a computer
on an internet is much like a terminal emulator and
modem on a personal computer.
THEnet The Texas Higher Education Network. It uses DECnet.
TN3270 A command which uses a variant of the TELNET protocol
that, gives the user the full-screen capabilities of an
IBM mainframe.
USENET A distributed electronic bulletin board offering many
of the advantages of electronic mailing lists.
Syracuse University Electronic-Mail Consultant's Guide 31
UUCP A Unix program which allows the creation of networks of
computers that transfer mail to each other through
dial-up modems. A cooperative network of Unix systems
has grown through the use of UUCP to tie Unix systems
to others.
VM Spooling System
The mechanism by which files (including electronic-mail
messages) are send from one user to another on a com-
puter running VM/CMS. Electronic mail to, from, or
routed through a VM/CMS system are typically stored in
its spooling system.
VM TCP/IP A software package which allows a VM/CMS system to be
placed on an internet. See also SMTP.
VMSMAIL The standard VAX/VMS program for sending and receiving
mail. Also known as "MAIL" which is the name of the
command that invokes it.
WIN/TCP for VMS
A software package which allows a VAX/VMS system to be
placed on an internet.
X.400 The International Standards Organization's official
standard protocol for the exchange of electronic mail.
It is new and not used much yet, but is expected to
replace RFC822 and SMPT eventually.
YAMP An experimental mail command on SUVM. Not generally
available or supported.
Glossary 32
BIBLIOGRAPHY
1. User's Directory of Computer Networks. Austin: University
of Texas System, 1988.
2. Crocker, David H. Standard for the Format of ARPA Internet
Text Messages. Internet RFC822.
3. Quarterman, John S., and Josia C. Hoskins. "Notable Comput-
er Networks." In Communications of the ACM 29:932-971.
4. Webster, Sally. Using Electronic Mail and BITNET Through
Academic Computing Services' VM/CMS System. Academic Com-
puting Services, Syracuse University, 1988.
5. Wobus, John M. Electronic Mail Network Help Sheet. Comput-
ing & Network Services, Syracuse University, 1989.
[1] is compiled from data provided by several world-wide net-
works about the computers they serve. It includes a "site
index", listing the names of the computers by site (i.e., insti-
tution). Unfortunately, its data on computers on the Internet is
not extensive enough to be very useful. It is supposed to be
updated periodically. [3] is an excellent, though slightly dated
reference on various electronic-mail networks around the world.
[5] is a short companion to this guide, which includes specific
methods for sending information from various computers at Syra-
cuse University to computers on various national and internation-
al networks.
Syracuse University Electronic-Mail Consultant's Guide 33
Appendix A
ELECTRONIC MAILING LISTS
One interesting service provided through electronic mail is
electronic mailing lists. Such mailing lists are useful for
announcements, and are also useful for maintaining "discussions"
through the mail between more than two people, and for allowing a
group of people to cooperatively answer questions.
A mailing list consists of a list of electronic-mail address-
es. Associated with it is an electronic-mail address for the
list itself. When you send a message to the list's address, the
message is re-sent to all the addresses in the list (This is
sometimes known as "exploding" the message and mailing lists have
been known as "mail exploders"). This can be done by a person,
but it is often done automatically with special software for the
purpose.
Mailing lists are generally formed to facilitate communica-
tions between a particular group of people. Often it is a group
of people simply interested in a particular topic. Sites often
maintain their own mailing lists for their own purposes, includ-
ing only their own people on the list. "National" (or interna-
tional) lists may be open to subscription to anyone or may be
"private".
SUBSCRIBING AND CANCELLING SUBSCRIPTIONS
There is no universal way to subscribe to an "open" mailing
list. The wrong way is to send a message to the list's address.
This results in the message being sent to all members of the
list: if it is a large list, then this practice forces lots of
people to weed out many such subscription-requests from their
incoming mail. The ideal solution is that whoever tells you
about the list should also tell you how to subscribe to it. Usu-
ally, all you need to know is a second electronic-mail address to
which you direct requests to subscribe to the list in question.
To cancel your subscription, you send the cancel-request to the
same address.
On the Internet, there is a convention which allows you to
derive the "subscription" address from the "list" address: the
computer-name is the same, and the username for subscriptions is
the same as the username for the list except that it has the
string "-request" appended to the end. For example:
Electronic Mailing Lists 34
+---------------------------------------------------------------+
| big-lan@suvm.acs.syr.edu -address of a mailing list. |
| big-lan-request@suvm.acs.syr.edu -address to receive requests|
| to subscribe to the |
| "big-lan" list. |
| |
| Figure 11: Example of addresses associated with a mailing |
| list. |
+---------------------------------------------------------------+
A list maintained on BITNET may support the same convention,
but it will only be useful for BITNET computers using Columbia
MAILERs or the like because of the 8-character limit on normal
BITNET usernames. Many BITNET lists are supported by a program
called LISTSERV which manages subscriptions for mailing lists
automatically. The LISTSERV program itself has a BITNET
(electronic-mail) address to which you send requests to subscribe
in a very strict format. LISTSERV will take such requests either
in an electronic-mail message or as a BITNET "interactive mes-
sage". You direct the request to the LISTSERV program on the
computer on which the mailing list in question resides. Follow-
ing are the commands to subscribe to a list maintained by a
LISTSERV and to cancel such a subscription.
+---------------------------------------------------------------+
| SUBSCRIBE BIG-LAN Mary Roe |
| SIGNOFF BIG-LAN |
| |
| Figure 12: LISTSERV commands to get on/off a mailing list. |
+---------------------------------------------------------------+
To do this through electronic mail, direct the message to the
name LISTSERV on the same computer as the mailing list. Follow-
ing is the LISTSERV address used to subscribe to BIG-LAN@SUVM:
+---------------------------------------------------------------+
| LISTSERV@SUVM |
| |
| Figure 13: Address of the LISTSERV on SUVM. |
+---------------------------------------------------------------+
To do this through "interactive" BITNET commands, use the VM/CMS
command "TELL" or the VAX/VMS JNET command "SEND" to send the
command. Examples:
Syracuse University Electronic-Mail Consultant's Guide 35
+---------------------------------------------------------------+
| CMS: TELL LISTSERV AT SUVM SUBSCRIBE BIG-LAN Mary Roe |
| VMS: send listserv@suvm subscribe big-lan Mary Roe |
| |
| Figure 14: Interactive commands to subscribe to the |
| BIG-LAN list. |
+---------------------------------------------------------------+
Note that LISTSERV requires that you give it your name.
FINDING OUT ABOUT LISTS
There is no universal way to find out about lists. Anyone on
any electronic-mail network can start one. SRI, the institution
which administers the Internet maintains a list of mailing lists
along with a brief description of each one and instructions for
subscribing. It is available via anonymous FTP from SRI-NIC.ARPA
as well as from various BITNET fileservers such as NETSERV. The
LISTSERV on BITNIC keeps several mailing lists of broad interest.
Also many lists of broad interest are available on numerous LIST-
SERVs. To tell what lists a LISTSERV supports send it the com-
mand "LIST" (in the same manner as the "SUBSCRIBE" or "SIGNOFF"
command except that "LIST" takes no argument).
Electronic Mailing Lists 36
___________________________________________________________________________
Communications of the ACM had an article on this subject in the
October 1986 issue, "Notable Computer Networks", pp 932-972. I'm sure it's
somewhat out of date, but maybe a good start.
*******************************************************************************
* IIIII RRR IIIII EEEEE Mike Pawka *
* I R R I E Systems Programmer Inna Babylon *
* I R R I EEE Naval Ocean Systems Center *
* I RRR I E San Diego, CA 92152 *
* I R R I E Internet: mike@cisco.nosc.mil *
* IIIII R R IIIII EEEEE Alternate: pawka@nosc-tecr.arpa *
*******************************************************************************
_______________________________________________________________________________
I'm afraid this is a rather large request. I have a very thick book detailing
just what you're looking for. It's about 400 pages and is a year old. It's
hopelessly outdated! I suspect that it would help, though.
It's the "Users' Directory of Computer Networks" published by the University of
Texas. The last I heard was that it is available for $17 from:
UT System OTS
Balcones Research Center
10100 Burnet Rd.
Austin, TX 78758-4497
Attn: Sandra Johnson
Both price and availability may have chenged in the past year.
You've bitten off a large task. I don't think I want to type in all of the
potentially useful information. My fingers get tired!
But, if you can catch me in my office (8:00 to 4:00 Pacific), I would be
willing to spend a few minutes explaining some of what I know. I imagine the
postmater of most any larger site could be of assistance, as well.
R. Kevin Oberman
Lawrence Livermore National Laboratory
Internet: oberman@icdc.llnl.gov
(415) 422-6955
Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
_____________________________________________________________________________
I N T E R O F F I C E M E M O R A N D U M
Date: 27-Oct-1989 11:37am EST
From: Bill Sherman
SHERMAN
Dept: A&T - 301
Tel No: (203) 440-6210
TO: Remote Addressee ( _VAXB::LWS )
Subject: Simple E-mail instructions - VMSmail Version
A Document is attached to this message
Simple E-mail rules to get to real-world networks
VMSmail Version
Are you confused about all these different E-mail networks? Having
trouble finding out how to send to somebody when they say that they're
on network X, and gives you their E-mail address on that network?
If you answered yes, then this may be what you've been looking for!
Simply scan this list of some of the most-used networks for the
desired network, and use the address provided in order to send mail to
that person via VMSmail from any NUSC VAX (not just V703!).
If you have any further questions, please feel free to contact the
Code 30 Information Technology Group (ITG) at x4654, or send VMSmail
to VSDEC::FRONT_DESK.
Bill Sherman
A&T Technical Services
July 20, 1989
Please find the network you wish to send to in the left column, and
substitute the address you were given for the underscored portion in
the sample address.
Note: The quotation marks provided ARE a required syntax!
Internet
ARPANET
MILNET
V70NL::WINS%"address"
UUCP
V70NL::WINS%"@uunet.uu.net:address"
OMNET
V70NL::WINS%"[mailbox/omnet]mail/usa%telemail@intermail.isi.edu"
BITNET
V70NL::WINS%"@mitvma.mit.edu:address"
Note: If what follows the @ in the address you have been given is
a single word with no periods in it, then you should append
.BITNET to the address before placing it in the address
template above.
For example, if you were given DJF101@URIACC as the
address, you should instead use DJF101@URIACC.BITNET.
SPAN
V70NL::WINS%"address@star.stanford.edu"
Note: If address is in the form name::username, then the address
should be changed to the form username%name.SPAN before
placing it in the address template above.
If address is in the form number::username, then the
address should be rewritten username%[number.SPAN].
For example, if you were given ECL1::SHERMAN as the
address, you should use SHERMAN%ECL1.SPAN in the address
template above, and if you were given 6114::SHERMAN you
should use SHERMAN%[6114.SPAN] in the template above.
Using Logical Names
To simplify the sending of mail to such complex addresses as listed
above, you may choose to use a logical name. Adding a line such as
$ define/nolog bill "v70nl::wins%""sherman@nusc.arpa"""
in your login.com will allow you to specify "bill" at the "To:"
prompt, which VMSmail will expand for you.
From: 6225::SHERMAN "Bill Sherman" 27-OCT-1989 11:43
To: VAXB::LWS
Subj: Internet E-mail Addresses
I N T E R O F F I C E M E M O R A N D U M
Date: 27-Oct-1989 11:39am EST
From: Bill Sherman
SHERMAN
Dept: A&T - 301
Tel No: (203) 440-6210
TO: Remote Addressee ( _VAXB::LWS )
Subject: Internet E-mail Addresses
A Document is attached to this message
Electronic Mail Address Determination on the Internet
The intent of this document is to give a working understanding of
the determination of addresses required to exchange electronic
mail between nodes which are members of an Internet subnet, and
between those Internet nodes and nodes which are on non-Internet
networks such as BITNET, UUCP, and SPAN.
It is assumed that you are already familiar with using your own
system's mail mechanisms, and know how to address mail so that it
will be sent out on to the Internet. If you do not know how to
do this, you should check with your local system's user support
group.
By Bill Sherman
A&T Technical Services
December 5, 1988
What is the Internet?
The Internet is a large collection of physically connected net-
works. Currently, it contains over 1000 networks ranging in size
from the ARPANET and MILNET, through large corporations such as
General Electric, Digital Equipment Corporation, to local college
networks such as those at Berkeley and MIT.
Diagrammatically, we have Internet as a large backbone,
connecting all of its tributaries
+--- ARPANET -- MILNET
I |
n +--- GE
t |
e +--- DEC
r |
n +--- Berkeley
e |
t +--- MIT
| .
| .
| .
Each of these tributary networks has one node assigned as an
Internet gateway. It is through this gateway that all mail
coming from or going to other networks must travel.
Exchanging mail between MILNET and ARPANET users
Because MILNET and ARPANET are nominally the same network, you
may send mail between two nodes on either of these networks by
using the address
user@node
where "user" is that person's username and "node" is the DDN
hostname of the computer where that username resides. For
example, mail may be sent to user SHERMAN at the node named
NUSC.ARPA (which is on MILNET) by using the address
SHERMAN@NUSC.ARPA
from any host on MILNET or ARPANET.
Routing mail via an intermediary host
There are many cases in which mail must be routed via an
intermediate host. In general, the format of an address which
uses routing is
user%host@gateway
where "gateway" is the name of a host which knows how to send
mail to the address "user%host". An alternate form of
@gateway1,@gateway2,...@gatewayn:user@host
can be used on many systems if it is necessary to route through
several hosts.
As an example of a use of routing, suppose that a fictitious
company ABC had a network which consists of computers called
ADAM.ABC, EVE.ABC, and APPLE.ABC, and you are unable to send mail
directly to APPLE. You would most likely be able to send mail to
a user at APPLE by using the address
user%APPLE@EVE.ABC
This would send your mail first to EVE.ABC, which would then
forward your mail to the address user%APPLE on EVE's sister
machine APPLE. This works because most mail systems recognize a
percent-sign as an alternate form of an at-sign in the absense of
an at-sign.
Exchanging mail between Internet networks in general
As an example of exchanging mail between two networks which are
members of the Internet, let's take ARPANET and DEC-WRL-NET.
First, you cannot send directly to most of the hosts on
DEC-WRL-NET, as they are not directly connected to the Internet.
In general you will have to route all mail through one of that
network's machines which is connected to the Internet. Such a
machine is DECWRL.DEC.COM. So following the model above for
routing, to send to user WHITE on host MOUSE.DEC, you would use
the address
WHITE%MOUSE.DEC@DECWRL.DEC.COM
Getting mail from Internet to other networks
In order to send mail to networks which are not members of the
Internet, you must route mail through a node which has access to
both Internet and the network you wish to reach. The best
current routers for some popular networks are listed below.
BITNET
To reach BITNET, several gateways have been set up and officially
registered for this use. Two which cover the eastern part of the
U.S. are
CUNYVM.CUNY.EDU (at the City University of New York)
MITVMA.MIT.EDU (at MIT)
Others are located at Cornell University and Princeton
University.
The group of hosts which serve as official Internet-BITNET
gateways are collectively known as INTERBIT. (Formerly, the node
WISCVM.WISC.EDU was the Internet-BITNET gateway. This node no
longer serves this function, and should not be used.)
As an example of sending mail to a user on BITNET, let's compose
the address required to send mail to user PHR113 on the BITNET
node URIMVS. The addresses on BITNET follow the same user@node
format that Internet addresses do, and so the address on BITNET
would be PHR113@URIMVS. To get a message from Internet to
BITNET, we will route through MITVMA. One additional piece of
information is that INTERBIT requires a suffix of .BITNET on
addresses, indicating that a given message is to be transferred
to the BITNET network. Putting all this information together
gives the complete address of
PHR113%URIMVS.BITNET@MITVMA.MIT.EDU
SPAN
Following the procedure similar to that listed above or BITNET,
if you want to send mail to user SHERMAN on node ECL1 which is on
the SPAN network, you would use the router STAR.STANFORD.EDU.
In this case, a suffix of .SPAN is required, giving a full
address of
SHERMAN%ECL1.SPAN@STAR.STANFORD.EDU
UUCP
The router for UUCP is a node named UUNET.UU.NET. But for UUCP
there is an additional complication. Addresses on UUCP follow
the UNIX standards for network addresses. These are of the form
node1!node2!...noden!user
and so to send to user MOH at node MOUTON you would use the
address
mouton!moh@uunet.uu.net
Interest groups
In order to help with the exchange of information, many interest
groups have been formed. INFO-VAX is one of the most popular
interest groups. The complete list of registered interest groups
is available from DDN Network Information Center.
In case of problems
For a number of years, electronic communication between users on
MILNET and ARPANET has relied upon the contents of what is called
the Host Table. This table gives the name and network address of
all officially-registered hosts along with other important pieces
of data about the network structure. A master copy of this table
is kept at the DDN Network Information Center.
Unfortunately, some sites may not maintain an up-to-date version
of Host Table, while other sites may add nodes without
registering them, and so these unofficial nodes may not be
reachable from all other sites, while some sites do not use
domain routing features available to them. In these cases there
is usually a host owned by the same research group or company
which can be used as a gateway to the unregistered host. See the
section which describes the address format for routing via
gateways for information on how to do this.
site-specific appendix
ecl1: VMSmail, STAR::"internet-address"
nusc: VMSmail, V70NL::MAILER!internet-address
vsdec: A1-Mail, _V70NL::MAILER!internet-address
Glossary
ARPANET The unclassified DoD experimental research and
development network (funded by the DARPA project).
This network was formed in 1969. See also MILNET.
BITNET Because It's Time NETWORK.
DARPA Defense Advanced Research Project Agency.
DDN Defense Department Network. The two unclassified
portions of this network are ARPANET and MILNET.
INTERNET Also called the ARPA Internet. A backbone of computer
networks which communicate via a set of standard
internet protocols developed by the Internet Working
Group (IWG) under the sponsorship of the DARPA
Information Processing Techniques Office (IPTO).
Formed in 1979.
MILNET The DARPA military operational communications network.
This network was split off from ARPANET in 1984.
SPAN Space ... Network.
SRI-NIC The Network Information Center for the DDN.
_______________________________________________________________________________
This is a very ambitious project! I'm including in this letter some
bibliographic information of books and guides that can get you started.
There is a lot of online material, too. Have you heard of Charles Hedrick's
"Intro to TCP/IP" or Ed Krol's "Hitchhiker's Guide to the Internet?" If not,
let me know and I will send them to you. (I will be leaving to go on a trip
for a week, so if you don't get something back right away you'll know why!)
Also, contact the NSFNET Network Service Center (617) 873-3400 for information
about how to receive their "Internet Resource Guide."
Hope this helps!
Tracy LaQuey
The University of Texas at Austin Computation Center
Co-chair, Internet Engineering Task Force USER-DOC Working Group
(USER-DOC stands for User Documentation)
------------------------------------------------------------
%A John S. Quarterman
%T The Matrix: Computer Networks and Conferencing Systems Worldwide
%I Digital Press
%C Bedford, MA
%D 1989
%X This book is a successor the article "Notable Computer Networks" published
by the CACM, October 1986. The first eight chapters contain
background materials that introduce important topics for readers who are not
familiar with networks and conferencing systems. References are provided for
those who want more complete treatments. The second half of the book contains
descriptions of specific systems, organized geographically, in order to
facilitate discussion of regional history. Maps are included. Syntaxes and
gateways are provided for sending mail from one system to another. Access
information is given for those wishing to join or research a system. There is
extensive reference sections found at the end of each chapter. For more
information, write matrix@longway.tic.com.
%A Tracy Lynn LaQuey
%T Users' Directory of Computer Networks
%P 653
%I Office of Telecommunication Services, University of Texas System
%C Balcones Research Center, 10100 Burnet Road, Austin, Texas 78758-4497
%D July 1989
%X This directory contains host indexes, contact information, network site
lists, general information on over 40 major networks, network maps, a domain
index, an Internet IP network number index, tutorials on the Domain Name SystemX
.500, Electronic Mail, and an Organization Index which lists the
domain, host and network index information by organizations. Much of the
information was written or provided by contacts at networks or Network
Information Centers, so it is accurate and timely. For more information,
write netbook@nic.the.net. Ordering information can be retrieved via
anonymous ftp to host emx.utexas.edu, directory net.directory, file
1989.ordering
%A Donnalyn Frey
%A Rick Adams
%T !%@:: A Directory of Electronic Mail Addressing and Networks
%P 284
%I O'Reilly and Associates
%C Newton, MA
%D August 1989
%X This is a handbook of electronic mail addressing and networks. It contains
and electronic mail tutorial, short descriptions of networks, and helpful
indexes of domain names and ISO codes.
______________________________________________________________________________
28-OCT-1989 14:18:39
Hello:
This is a HELP from somewere in the NET. Don't ask, I really don't
know were it came from. I only remember that it is from a HELP. I hope
this can help you in some way because it's the only piece of INFO in
hard hand that I have.
Cordially;
Rafael Muller
>
> Computer networks now span the world, and the gateways between them
> allow millions of users to send electronic mail messages to one
> another, permitting easy collaboration between researchers in
> different countries. However, the syntax required to send a message
> from one machine to another is often complicated, and there is no
> central register of electronic addresses for users.
>
> In order to send electronic mail it is typically necessary to know
> the user name of the addressee, the name of the machine on which he
> or she is working (the host), and the name of the network to which
> the machine is connected (the domain). This information may be
> obtained from the sender (see hints on deciphering electronic mail
> addresses). Because there are several different networks in wide
> use, a lot of electronic mail has to cross from one network to
> another via GATEWAY machines or RELAYS. These are computers that
> are connected to two or more different networks and which accept
> mail from one network and forward it onto another network. Many of
> the mysteries of electronic mail have to do with determining the
> syntax needed to send mail through such relays.
>
> NetworkDescriptions
>
> The computer networks in most common use by astronomers in North
> America are the ARPA Internet, Span (NASA's Space Physics Analysis
> Network), BITNET, UUCP, and TELENET (a commercial network managed by
> GTE). In addition, astronomers world-wide have access to a number
> of networks, such as JANET and Starlink in Britain, EARN in Europe,
> INFNET/ASTRONET in Italy, ACSNET in Australia, and the international
> packet-switched networks based on the X.25 protocol.
>
> Mail delivery times will vary from network to network; on SPAN mail
> delivery is essentially instantaneous (indeed, if the mail cannot be
> sent the user is informed of this immediately, and queuing of
> messages is no supported). On UUCP it may take several days for a
> message to reach its destination. Most networks provide mail
> delivery in times between a few minutes and a few hours, and if the
> mail does not go through immediately they will try again several
> times before returning the mail to the sender. Some networks only
> provide electronic mail services (such as BITNET and Telenet), while
> others allow users to log in on other computers and copy files (such
> as SPAN and the Internet).
>
> The current state of the computer networks is somewhat akin to
> telephone systems around the turn of the century - there are
> numerous systems, some mutually incompatible, and some
> interconnected through gateways that provide mail forwarding
> services. Moreover, different networks use different PROTOCOLS, or
> data encoding schemes, for the transmission of information. Some of
> these protocols are open standards, such as TCP/IP, and some are
> proprietary to certain manufacturers (such as DEC's DECnet). As a
> result, there is often no one simple way to specify a mail address.
> There is no equivalent to the standard telephone number, although
> there are 'standard' ways of specifying electronic mail addresses.
>
> As far as the user is concerned, electronic mail/data communications
> lines are essentially error free; complex error checking and error
> correcting procedures are defined in the standards, and are carried
> out by a combination of hardware and software. As an alternative to
> data communications lines, one may use direct dial-up with normal
> telephone lines and error correcting modems. However, the costs
> compared with the data communications networks are high over long
> distances, and the passband and signalling standards used on audio
> networks can vary from country to country, which may result in
> incompatibility between modems (e.g., between the USA and the UK).
> Generally, the costs of commercial data communications lines are
> related to the quantity of data transmitted, while direct dial-up
> costs are related to the length of time that a call takes.
> Different methods are used to encode the data on data communications
> lines and telephone lines. On telephone lines between modems, the
> data are encoded as a frequency modulated audio tone, and the
> transmission rate is limited by the bandwidth of the line, usually
> to 2400 baud (although baud rates up to 9600 can be obtained by
> using special modems). On data communications links, although the
> physical media may be similar, phase encoding is used which allows a
> much higher transmission rate, typically 9600 baud.
>
> Standards for data communications links are defined by the
> International Standards Organization (ISO). ISO has attempted to
> identify a seven layer model describing the interconnection of
> computers of different types via any kind of network. The lower
> levels are concerned with hardware matters, such as defining the pin
> for the 'transmit' line, while the upper layers are concerned with
> more esoteric problems, such as the means by which one might
> transmit an encrypted picture to a telex machine. However, there is
> still much confusion, because there exist competing standards from
> different organizations, such as TCP/IP from ARPA, DECnet from DEC,
> SNA from IBM and the "Coloured Book" protocols in the UK; some of
> which incorporate a mixture of ISO and proprietary protocols. The
> ISO standard protocols are still being developed, but when they are
> available many of these problems will diminish.
>
> NOTE ON CaSe SENSITIVITY: Most electronic mail addresses are not
> sensitive. As a matter of convention, electronic mail addresses on
> computers running the UNIX operating system tend to be given in
> lower case (e.g., on the UUCP and Internet networks), and addresses
> on VMS machines tend to be given in upper case (e.g., on the SPAN
> network). This is a tendency, however, not a strict rule. One
> should be careful with UUCP addresses in particular; users are
> advised to follow the case specifications carefully, since the
> address host1!host2!user is NOT the same as host1!host2!User.
>
> NetworkDescriptions
>
> ARPAInternet
>
> The Defense Advanced Research Project Agency (D)ARPA network was
> initially set p by the U.S. Department of Defense in 1969. It is
> now a part of the ARPA Internet, which uses TCP/IP (Transmission
> Control Protocol/Internet Protocol) communications and includes over
> 30,000 hosts (1987) and more than 570 networks in several domains:
>
> COM - commercial organizations
>
> EDU - educational/research organizations
>
> GOV - civilian government organizations
>
> MIL - Department of Defense
>
> ORG - other organizations
>
>
> Most Internet network sites that astronomers communicate with will
> be in the EDU domain (universities, national observatories). The
> old ARPA domain is being phased out, and addresses ending in .ARPA
> will no be valid after December 1988. For example, after this date
> mail to STScI will have to be addressed as user@stsci.edu rather
> than as user@stsci.arpa. Most sites have already converted to the
> new domain names and the associated utility functions that support
> the distributed name/domain directory system.
>
> There are additional domains for countries outside the USA, e.g., UK
> (United Kingdom) and AU (Australia). The Internet includes some
> transcontinental and transatlantic satellite links (SATNET).
> Typical delivery times on the Internet are of order of a few
> minutes.
>
> In the Internet individual computers are assigned numerical
> addresses within a hierarchical system, with the first number in the
> address being the number of the individual network on the Internet.
> For example, [4.0.0.0] is SATNET, [10.0.0.0] is the ARPA network,
> [128.112.0.0] is the Princeton network, and [128.112.24.2] is an
> individual machine at Princeton. These addresses are mapped against
> alphanumeric addresses via host tables. Thus, the machine
> [128.112.24.2] corresponds to PUPGG.PRINCETON.EDU. In fact, users
> will generally need to specify the alphanumeric name of the host,
> rather than its numerical address, when sending mail or doing a
> remote login. Other examples of Internet host names are STSCI.EDU,
> SCIVAX.STSCI.EDU, NOAO.ARIZONA.EDU, NAIC.EDU, ASTRO.UMD.EDU. These
> names all have at least two components (site.domain), and may have
> several fields separated by periods preceding the domain, e.g.,
> ASTRO.AS.UTEXAS.EDU. These fields can generally be interpreted as a
> hierarchy - machine, (subnet), campus, domain. The Network
> Information Center (NIC) coordinates site and host numbers for all
> of the systems connected to the Internet.
>
> The Internet is the fastest growing of the United States networks
> and presently is supported by DARPA, the National Science
> Foundation, NASA, the Department of Energy, and the United States
> Geological Service. NSF has the mandate to support national
> networking for the scientific research community. The NSF
> communications backbone was upgraded in July 1988 with new gateways
> and high-speed T1 lines (1.544 Mbits/sec). This backbone connects
> supercomputer sites in Princeton, Ithaca, Pittsburgh, Urbana,
> Boulder, and San Diego. In addition there are backbone nodes in Ann
> Arbor, College Park, Houston, Lincoln, Palo Alto, Salt Lake City,
> and Seattle. s. 1 The NSF backbone services the main node sites
> and a hierarchically structured set of midlevel networks: regional
> networks such as NYSERNET and NorthWestNet, consortia such as SDSC
> agencies (DARPA, NASA, DOE) further facilitate communications. all
> of the mid-level networks support communications with at least 56
> kbit/sec links.
>
> The NSF supports network connections and the regional and consortia
> networks connect university campuses. Each campus is expected to
> provide local network connections and assistance to any campus
> department that needs network access. This policy provides a level
> of local control yet supports connections at high speed. All of the
> campus links have 56 kbits/sec lines at minimum, and most campuses
> have one or more 10 Mbits/sec Ethernet Local Area Networks (LANs) on
> campus, making access quite simple.
>
> NetworkDescriptions
>
> Bitnet/Earn
>
> BITNET (the name derived from the phrase "Because It's Time") is a
> worldwide network connecting over 1000 hosts by means of leased 9600
> baud telephone lines. Funding used to be provided by IBM
> Corporation, but user sites must now foot the bill for their BITNET
> network traffic. IBM's RSCS (Remote Spooling and Connecting
> Subsystem) protocols are used. The network has different names in
> different countries: BITNET in the USA (more than 1000 hosts in
> 1988), NETNORTH in Canada (91 hosts), EARN (European Research
> Network) in Europe (363 hosts), and ASIANET in Japan (7 hosts), but
> these distinctions are invisible to the user. The network has a
> tree-like structure with the trunk at host CUNYVM in New York, and
> there is just one route between any two hosts.
>
> Host names are non-hierarchical and are limited to 8 characters.
> Within EARN there are some conventions about how these names are
> constructed. For Austria, Germany, Sweden and Switzerland, the
> first character of the host name is the international country
> abbreviation (i.e. 'D' for Germany) the second and third letters
> are an abbreviation for the location, the fourth to sixth letters
> are the initials of the organization, the seventh letter is the
> number of the software version, and the eighth letter is a system
> number (1-9, A-Z). Other European countries follow related
> conventions.
>
> Consequently, most EARN names are unpronounceable and unmemorable,
> and there is often confusion between the letter 'O' and the digit
> '0'.
>
> The single EARN host in the United Kingdom, UKACRL, serves as a
> gateway to the JANET network. It relays mail only between JANET and
> proper BITNET hosts; it will not forward mail sent through another
> relay to BITNET.
>
> On BITNET in the United States the names tend to have more obvious
> meanings. For example, ALASKA is the University of Alaska, NRAO is
> the National Radio Astronomy Observatory, and UWAPHAST is the
> University of Washington Physics Department.
>
> Sometimes BITNET hosts are referred to as hosts.BITNET. The .BITNET
> may usually be omitted in electronic mail addresses totally within
> the BITNET network.
>
> Because BITNET/EARN is IBM-based, characters sent from other types
> of machines may be translated from ASCII to EBCDIC, and "exotic"
> characters such as { may be corrupted.
>
> NetworkDescriptions
>
> Span
>
> The NASA-supported Space Physics Analysis Network began operating in
> 1981. There are now more than 1000 hosts on the network, including
> 130 on the European SPAN segment. SPAN uses the DECnet protocols,
> and almost all of the machines in SPAN are DEC VAXes.
>
> The backbone of the network is provided by 4 routing centers
> connected by 56 kbits/sec links: NSSDCA at Goddard Space Flight
> Center in Greenbelt, Maryland, SSL at Marshall Space Flight Center
> in Huntsville, Alabama, JPLLSI at Jet Propulsion Laboratory in
> Pasadena, California, and JSC at Johnson Space Center in Houston,
> Texas. Most SPAN sites are connected with 9.6 kbits/sec lines.
>
> The network is managed by the National Space Data Center (NSSDC) at
> GSFC. There is a transatlantic X.25 link between GSFC and the main
> host in Europe, ESOC (the European Space Operations Centre at
> Darmstadt). The Rutherford Appleton Laboratory recently became a
> SPAN host (RLVAD).
>
> The names of host on SPAN may have up to 6 alphanumeric characters.
> For example, BKYAST is the Astronomy Department at UC-Berkeley,
> CFAPS1 is Planetary Science Division at the Center for Astrophysics
> in Cambridge, EXOSAT is the EXOSAT project at ESTEC, The
> Netherlands, and GAL is at the NASA Ames Research Center.
>
> Hosts also have numbers of the form area.machine, where area is a
> 6-bit area code. You may need to specify the SPAN address in its
> numeric form if your site does not have a current SPAN site table.
> One can determine the numeric form of a SPAN address from the
> formula 1024 X area + machine. For example, CFAPS1 is SPAN host
> number 17.32, corresponding to address 17440 in decimal. JANET
> users should note that the number may no be used as a substitute for
> the name when sending messages through the gateway at
> STAR.STANFORD.EDU, although most other gateways accept them.
>
> Addresses on SPAN (and other DECnet based networks) are given in the
> form HOST::USER or, if routing through machine HOST1 is to be
> specified, as HOST1::HOST::USER. Using the routing may be handy if
> your computer doesn't have the host name in its site table and you
> don't know the number or if you know a certain routing is better or
> if one of the normal links is down. Remember that mail cannot be
> delivered over SPAN unless the full link between the you and the
> distant user is up and working.
>
> Note that SPAN is integrated with HEPNET, the High Energy Physics
> Network. HEPNET addresses have the same form as SPAN addresses,
> i.e., HOST::SITE.
>
> NetworkDescriptions
>
> UUCP/USENET
>
> The Unix to Unix CoPy network (UUCP) includes of order 7000 hosts,
> most running the Unix operating system. The network mostly uses
> simple dial-up modem connections, with TCP/IP network connections
> where possible. The first links were made in 1978 at Bell
> Laboratories. Each host pays for its own links, which are generally
> low-speed (1200 and 2400 baud) and low-cost. Administration is
> minimal. Typical delivery times are of order days.
>
> UUCP host-names are non-hierarchical. Some examples are aardvark,
> edison, groucho, kludge, tukey, yoyo, and zyx.
>
> The UUCP network is unusual in using explicit source-routing, in
> which addresses of the form hosta! hostb!host!user are interpreted
> as a route along which the message must be sent in order to reach
> user at host. A few central hosts are known, reasonably reliable
> forwarding machines; use of these hosts in UUCP addresses makes the
> routing information shorter. Some example addresses are ...
> MCVAX!ENEA!ASTOL!user (Lund Observatory,
> Sweden),...MCVAX!UKC!QMC-MS!user (Queen Mary Collage, London), and,
> {CFA, IHNP4, SEISMO}!NOAO!SUNSPOT!user (National Solar Observatory,
> New Mexico). The curly brackets indicate that any of the specified
> backbone sites may precede !NOAO!SUNSPOT. The ellipses should be
> replaced by whatever routing information is needed (if any) to get
> the message as far as the host name which follows them. The trick
> in making successful use of UUCP is to be able to determine a
> routing path from your machine to another machine (as if you had to
> tell Ma Bell or MCI how to route your phone calls!). Some sites
> have software that can provide routing information; if you cannot
> provide the full route, the program will try to determine a route
> for you automatically.
>
> There are a number of UUCP-related networks: EUNET in Europe (900
> hosts), JUNET in Japan (160 hosts) and ACSNET in Australia. In
> Europe, there is one backbone site in each country, e.g., TUT in
> Finland, INRIA in France, ARIADME in Greece, MCVAX in the
> Netherlands, ENEA in Sweden, and UKC in the United Kingdom. All the
> European backbone sites are connected to MCVAX in Amsterdam, which
> also connects to SEISMO, the main routing node in the USA. Examples
> of other backbone sites are MUNNARI in Australia (Melbourne) and
> UUNET in the United States. From the Internet mail can be relayed
> through UUNET.UU.NET.
>
> NetworkDescriptions
>
> GTETelenet
>
> Telenet is a commercial network with a mail service run by GTE. A
> number of scientists are on this network, particularly the
> oceanographers and the VLBI crustal dynamics community. NASA uses
> Telenet systems to provide services for their NASA mail and GSFCmail
> networks. Telenet has a large number of local telephone numbers and
> with a modem and a PC a user can connect to the network from nearly
> anywhere in the United States. Users are not dependent upon their
> institutions being wired up to one of the major networks. Telenet
> charges a fee based on the connect hours used.
>
> Telenet addresses are of the form [username/site]network/country.
> The four most active Telenet networks for astronomers are TELEMAIL
> (physicist), MAIL (some specific institutional networks), NASAMAIL
> (NASA headquarters and most NASA centers, and GSFCMAIL (Goddard
> Space Flight Center).
>
> Most users communicate within their own network and do not use the
> brackets and network/country designations. Within one Telemail
> network, the username is sufficient if the name is unique. For
> example, if you are on TELEMAIL and want to send mail to Peter
> Boyce, then PBOYCE is an adequate address. If you are on NASAMAIL
> you would have to use the address [PBOYCE/AMERPHYS]TELEMAIL.
> Conversely, to get to a NASAMAIL user the address would be of the
> form [username/NASA]NASAMAIL. If you stay within the United States,
> the country designation is not needed. If you have trouble
> contacting someone who says they are on TELEMAIL, try adding the
> network designation.
>
> The American Institute of Physics is upgrading an electronic network
> service they have established called PINET. In additions to
> listings of jobs, abstracts in advance of publication, meeting
> notices and other data, they are establishing an electronic mail
> service, called PIMAIL, with direct connections to BITNET and the
> INTERNET. PIMAIL subscribers will be able to mail to these networks
> without having to use gateways. The expanded service is expected to
> start by March 1989. AIP will charge only for the communications
> costs. Note that AIP will not server as a gateway between networks,
> but will allow their subscribers who come on Telenet to communicate
> directly and easily with the other two networks.
>
> To get more information on PINET contact the PINET Administrator,
> American Institute of Physics, 335 East 45th Street, New York, NY
> 10017 (tel 212-661-9404).
>
> NetworkDescriptions
>
> PSI/DTE
>
> Most countries have public data communications networks that allow
> national and international calls to be made in support of electronic
> mail, file transfers, and remote logins. To make a call to a remote
> computer, it is necessary only to know the machine's DTE (Date
> Terminal Equipment) number, often quoted as a PSI (Packetnet System
> Interface) number, DNIC number, or X.25 number.
>
> The X.25 protocols (X.3, X.25, X.28,...,sometimes known as
> "Triple-X") may be used directly to establish connections with
> remote host computers. International gateways (using the X.75
> protocol) ensure that links can be made between countries. The
> Triple-X protocols are used by a number of other networks to provide
> connections between sites. Most of these X.25 links are not visible
> to network users, but they do provide many gateway-gateway links in
> the Internet, CSNET, and UUNET. Also, these protocols are the
> underpinnings for the Telenet networks, the new international mail
> standard X.400, and for DEC's PSI. PSI supports mail, remote
> logins, and remote file transfers, and there are several relays
> between PSI mail and other networks.
>
> Each DTE number is unique to a given machine and is internationally
> recognized. The first 3 digits are a country code, the 4th digit
> distinguishes individual networks within the country, and the next 8
> (or so) digits are used to distinguish physical lines on the
> network. As well as this total of approximately 12 digits, 3 more
> digits may be added to specify local sub-addresses (individual
> computers) sharing the given line. Some countries allow only one
> digit for the subaddress, others allow two, and a few allow three.
> DTE numbers are often quoted with a zero preceding the country code.
> The DTE number functions much more like the standard telephone
> numbers we are accustomed to; the DTE address is the same regardless
> of your particular host.
>
> Since DTE numbers are generally long, difficult to remember, and
> easy to mistype, some sites will set up alias tables for commonly
> addressed sites. These allow users to refer to the site by a simple
> name rather than by the DTE number.
>
> On DEC systems you may see addresses of the form PSI%HOST or
> PSI%31103010014012, the latter being the DTE number.
>
> NetworkDescriptions
>
> OtherNetworks
>
> ASCNET
>
> The Australian Computer Science Network includes over 300 hosts
> (1986) and caters to a mix of academic and commercial clients. The
> network is UNIX-based and began operating in 1979. Each host pay
> for its own links. The naming syntax, like that of the internet, is
> hierarchical. An example of a host-name on ACSNET is
> SUPHYS.SU.OZ.AU (Physics Department, Sydney).
>
> For information contact POSTMASTER@MUNNARI.OZ.AU, or ACSNET
> Coordinator, Department of Computer Science, University of Sydney,
> New South Wales 2006, Australia.
>
> NetworkDescriptions
>
> OtherNetworks
>
> CDNNET
>
> CDNNET. The Canadian Universities' X.400 network includes
> approximately 65 hosts. An example of a host-name on CDNNET is
> DRAO.NRC.CDN (Dominion Radio Astrophysical Observatory).
>
> For information about CDNNET contact CDNNET HQ, Computer Centre,
> University of British Columbia, Vancouver, British Columbia V6T RWS,
> Canada.
>
> Canada is now involved with a major network project called NRCNET
> which is to provide high speed, full function network links across
> Canada. For information contact WOODSWORTH@NRCDAO.BITNET.
>
> NetworkDescriptions
>
> OtherNetworks
>
> CSNET
>
> CSNET. The Computer Science Network includes many hosts in the USA
> and at international sites. Host names are hierarchical. An
> example of a host-name on CSNET is ANDY.BGSU.CSNET, a machine at
> Bowling Green State University. CSNET only offers mail services but
> uses a number of different network links. CSNET also runs an
> information server and a relay system that can be reached from the
> Internet RELAY.CS.NET.
>
> NetworkDescriptions
>
> OtherNetworks
>
> HEPNET
>
> HEPNET. The High Energy Physics network includes over 600 hosts,
> 150 of them in Europe. An example of a host-name on HEPNET is MINN
> (node 43077), at the University of Minnesota. HEPNET uses both
> DECnet and Coloured Book protocols. The DECnet addresses are
> coordinated with SPAN.
>
> NetworkDescriptions
>
> OtherNetworks
>
> INFNET/ASTRONET
>
> INFNET/ASTRONET. The Italian research network uses the DECnet
> protocols and includes approximately 100 hosts. ASTRONET is a
> subset of INFNET consisting of nodes at major Italian astronomy
> research centers.
>
> INFNET hosts can be reached via the BITNET/EARN gateway CERNVAX at
> CERN, Switzerland, and are also accessible on the SPAN network. For
> example, the INFNET host ASTBO1, serving the Radio Astronomy group
> in Bologna, is also SPAN host ASTBO1, node number 39.126 (40062).
> EARN addresses for INFNET users are sometimes quoted as
> user@host.BITNET.
>
> NetworkDescriptions
>
> OtherNetworks
>
> JANET
>
> JANET. The UK Joint Academic (X.25) Network includes approximately
> 1000 hosts. All UK universities and most polytechnics are
> connected. The network originated with SERCNET (the Science and
> Engineering Council Network) in 1977, and was renamed JANET in 1984.
> The cost of leasing lines from British Telecom is met through grants
> from the SERC. Electronic mail and other services are implemented
> using the UK Coloured Book protocols. Each Coloured Book defines a
> different standard. For example, the Grey Book defines a temporary
> network mail protocol based on the RFC733 header standard (following
> an ARPA Internet convention).
>
> Host names conform to a National Registration Scheme (NRS), managed
> by Sanford University, and are hierarchical like those of hosts on
> the Internet, but with the most significant element first. For
> example, UK.AC.CAM.PHY-RAVX is the Radio Astronomy Vax in Cambridge,
> UK.AC.MANCHESTER.JODRELL-BANK. STARLINK is Jodrell Bank,
> UK.AC.UCL.CS.NSS is the Internet gateway at University College,
> London, and UK.UMRCC is the Manchester Computer Centre.
>
> AC stands for Academic Community, i.e., it corresponds to the EDU
> part of the Internet. There is also a CO domain catering to
> commercial clients.
>
> Within JANET the UK.AC may be omitted. There are also standard
> abbreviations for some names, e.g., RGO.STAR for
> RO-GREENWICH.STARLINK.
>
> NetworkDescriptions
>
> OtherNetworks
>
> SOLARMAIL
>
> SOLAR MAIL. Solar Mail is an electronic mail distribution system
> run by Rick Bogart of Stanford University for solar astronomers.
> With mailboxes on SPAN, Internet, and Bitnet, this can be a
> convenient way to contact solar astronomers or receive notices of
> interest to the solar community. For further information contact
> SOLARMAIL@SOLAR.STANDFORD.EDU
>
> NetworkDescriptions
>
> OtherNetworks
>
> STARLINK
>
> STARLINK. The UK astronomers' DECnet-based Starlink network
> (9600/19200 baud lines) is funded by the Science and Engineering
> Research Council and includes 10 Vax host. There are associated
> Microvaxes at several other British universities.
>
>
> HINTS
>
> To the novice, many electronic mail addresses appear to be
> incomprehensible jungles of acronyms and punctuation marks. Below
> are a few hints on deciphering them, followed by some real-life
> examples.
>
> * All the alphabetic and numeric characters, including @ % ! " :
> . , may appear in electronic mail addresses. % signs(! signs
> for UUCP) usually separate the names of hosts through which the
> message is to be routed. For example, a message to
> user%host%host1%host2@host3 will be sent to host3, which will in
> turn forward the message to user%host%host1 at host2, and so on.
> Exclamation marks, curly brackets, and ellipses are used in
> specifying UUCP addresses. Colons are used in DECnet addresses
> to separate the host name from the user name and in some
> Internet addresses.
>
> * To determine the network of origin, look at the form of the
> sender's address in the 'from' field in the header. An address
> of the form user@host or user@host.domain has probably
> originated on the Internet or BITNET/EARN. UUCP addresses will
> be punctuated by exclamation marks (host!host2!host3!user).
> Addresses on SPAN (and other DECnet based networks, such as
> INFNET and Starlink) have a host name and user name separated by
> two colons (HOST::USER).
>
> * Host names on the Internet, CSNET, and JANET are hierarchical,
> of the form domain1.domain2.domain3. Most networks with
> hierarchical naming place the least significant domain (i.e.,
> the final destination machine) first (host.site.domain). In
> JANET addresses the most significant domain comes first, e.g.,
> UK.AC.RO-GREENWICH.STARLINK, and JANET names must often be
> reversed when communicating with networks outside the UK.
> Hence, for example, STARLINK.RO-GREENWICH.AC.UK is the address
> quoted by RGO to BITNET users. Note that the elements
> neighboring the hyphen retain their original order - i.e., the
> hyphen is treated like an alphabetic character that is part of
> the domain name.
>
> * Internet names often end in .EDU, e.g., NOAO.ARIZONA.EDU. Less
> common (to astronomers) will be addresses from the domain .COM,
> .GOV, .MIL, and, .ORG.
>
> * SPAN and other DECnet (INFNET/ASTRONET, HEPNET, Starlink) hosts
> are sometimes referred to by area and number or by number alone.
> You may have to use the numerical address if the node names are
> not present in your local site table. The most general form of
> an address where the message must pass from one network to
> another, or through some intermediate host, has the form
>
> user%host.domain@relay.mydomain
>
> The message is sent to the computer called relay which is in a
> network mydomain that your local system can reach. The computer
> relay then passes the message on to the remote machine called
> host in the network domain. The computer relay may actually
> modify the address you specify in order to perform the message
> forwarding. In cases where the remote address is of some
> peculiar form, or where the relay host does not know how to
> modify it, the remote part of the address will generally get
> written inside quotation marks. For example,
>
> "ASTRTS::ADOC"@IO.ARC.NASA.GOV
>
> will relay a message from the Internet (note the .GOV domain) to
> the user ADOC at the ASTRONET site ASTRTS.
>
> AcrossNetworks
>
> Mail crosses network boundaries through forwarding systems known as
> gateways or relays. It is often necessary to find a route to a user
> that utilizes one of these gateways. For example, a user on BITNET
> could send mail to a user on SPAN by making use of the gateway at
> SDSC:
>
> user%host.SPAN@SDSC.BITNET
>
> or a user on the Internet could send mail to a BITNET user using the
> gateway at CUNYVM:
>
> user%host.BITNET@CUNYVM.CUNY.EDU
>
> See 'Gateways table' for more information. This table can also be
> used to work out the return addresses. As shown in the table, many
> combinations are possible and there may be one or more relay systems
> that serve the same networks. The table list possibly redundant
> relays because individual relays may be down at times and because
> relays may cease service.
>
> Much of the information in the table is taken from Quaterman and
> Hoskins (1986). The syntax for messages traveling to and from SPAN
> were provided by the SPAN Network Information Centre at NSSDCA
> (dated September 1987). Dates indicate the last time a particular
> syntax was tried and found to work. Confirmation of others would be
> appreciated.
>
> In the UK hierarchical host-names must be entered in reverse order.
> In the table the context makes clear the order required. For
> example, JANET names may need to be specified as UK.host or as
> host.UK.
>
> Note that while most gateways support open access, authorization may
> be required in order to use some gateways. For example, UK users
> must register in order to use the gateways at UK.AC.UCL.CS.NSS
> (Internet), UK.AC.RL.EARN (BITNET/EARN) and UK.AC.UKC (UUCP).
> Limits are also imposed on the lengths or records and sizes of files
> (typically a few tens of kbytes) that may be mailed through
> gateways. Binary files will not usually transmit in the form of
> mail over networks, although programs are available for converting
> some kinds of binary data to ASCII data.
>
> Relays through which a message passes have mailers for forwarding
> the message according to the address it bears. In one of the hosts
> is down the message may be sent via another route, returned to the
> sender, delayed, or lost. The reply, if it comes at all, may do so
> by a quite different route. For example, replies to JANET addresses
> sometimes attempt to enter the United Kingdom by the Internet
> gateway at UK.AC.UCL.CS.NSS, rather than the EARN gateway at
> UK.AC.RL.EARN. Few UK users are registered for use of the Internet
> gateway, and messages directed at it are frequently bounced. Most
> UK users are authorized to use the EARN gateway.
>
> If you know a host address but not individual users's address, try
> using the surname, first initial plus surname, or the user's
> initials. Some sites have alias tables set up for their staff so
> that mail arriving at any of a number of names will be forwarded to
> (hopefully) the right person. You can also try sending mail to
> POSTMASTER (recommended), ROOT (for UUCP), SYSTEM (will probably
> work), or OPER (last resort), and specify the name of the recipient
> in the first line of text. Since systems managers and computer
> operators will generally not care to continue handling your
> misguided mail, they may well provide you will a proper address for
> the intended recipient. POSTMASTERs tend to be user friendly sorts
> who are willing to help the mail get to its final destination.
>
> Because of the possibility that an outgoing message may disappear
> down a black hole, it is recommended that users append to each
> message (a) a request for confirmation, and (b) their network and
> postal addresses and their telephone and telex numbers. All of this
> is not necessary once you have exercised a particular e-mail routing
> a few times and have some confidence that the mail will get through.
> Hopefully, in time, the current complexities of electronic mail will
> disappear and something like the relative simplicity of the national
> and international telephone systems will replace it. In the
> meantime, patience, this guide, and the help of a local e-mail
> 'guru' will help a lot.
>
>
> GatewaysTable
>
> ACSNET
>
> From To Syntax
> ACSNET ACSNET user@host.OZ.AU
> ARPA user%host.domain.@MUNNARI.OZ
> BITNET user%host.BITNET@MUNNARI.OZ
> JANET user%host.UK@MUNNARI.OZ
> JUNET user%host.JUNET@MUNNARI.OZ
> SPAN user%host.SPAN@VLSI.JPL.NASA.GOV
> UUCP user%host.UUCP@MUNNARI.OZ
>
>
> GatewaysTable
>
> ARPA
>
> From To Syntax
> Arpa ACSNET user@host.OZ.AU
> ACSNET user%host.OZ@UUNET.UU.NET
> ARPA user@host.domain
> BITNET user%host.BITNET@CUNYVM.CUNY.EDU
> CSNET user%host.CSNET@RELAY.CS.NET
> JANET user%host.UK@NSS.CS.UCL.AC.UK
> JANET user%host.UK@IO.ARC.NASA.GOV
> JUNET user%host.JUNET%UTOKYO-RELAY@RELAY.CS.NET
> SPAN user%host.SPAN@NSSDCA.GSFC.NASA.EDU
> SPAN user%host.SPAN@STAR.STANFORD.EDU
> SPAN user%host.SPAN@VLSI.JPL.NASA.GOV
> SPAN user%host.SPAN@IO.ARC.NASA.GOV
> UUCP user%host.UUCP@UUNET.UU.NET
>
>
> GatewaysTable
>
> BITNET
>
> From To Syntax
> BITNET ACSNET user%host.OZ.AU@relay
> ARPA user@host.domain
> ARPA user%host.domain@relay
> BITNET user@host
> JANET user%host.UK
> JANET user%UK.host@AC.UK
> JANET user%uk.host@UKACRL
> JUNET user%host.JUNET@RELAY.CS.NET
> SPAN user%host.SPAN@SDSC.BITNET
> UUCP host1!host2!host!user@PSUVAX1
>
>
> GatewaysTable
>
> JANET
>
> From To Syntax
> JANET ACSNET back-bone-site!host.OZ!user@UK.AC.UKC
> ARPA user%domain.host@UK.AC.RL.EARN
> ARPA user%host.domain@UK.AC.UCL.CS.NSS
> BITNET user%host@UK.AC.RL.EARN
> CDNNET user%CDN.host@UK.AC.RL.EARN
> CSNET user%CSNET.host@RL.EARN
> HEPNET user%CERN.DECNET.host@UK.AC.EAN-RELAY
> HEPNET user%host.HEPNET%LBL@UK.AC.RL.EARN ?
> INFNET user%host.INFNET%BITNET.CERNVAX
> INFNET user%INFNET.host@UK.AC.RL.EARN
> JANET user@UK.host
> JUNET user%host.JUNET@UK.AC.UKC
>
>
> GatewaysTable
>
> SPAN
>
> From To Syntax
> SPAN ACSNET NSSDCA::EXOS%"user@domain.OZ.AU"
> ACSNET JPLLSI::"user@domain.OZ.AU"
> ARPA NSSDCA::EXOS%"user@host.domain"
> ARPA STAR::"user@host.domain"
> ARPA JPLLSI::"user@host.domain"
> ARPA SDSC::"user@host.domain"
> BITNET NSSDCA::EXOS%"user@host.BITNET"
> BITNET HAMLET::"user@host.BITNET"
> BITNET STAR::"user@host.BITNET"
> BITNET JPLLSI::"user@host.BITNET"
> BITNET SDSC::"user@host.BITNET"
> JANET JPLLSI::"user%host.domain@NSS.CS.UCL.AC.UK"
> JANET NSSDCA::EXOS%"user%host@NSS.CS.UCL.AC.UK"
> JANET STAR::"user%host@NSS.CS.UCL.AC.UK"
> JUNET JPLLSI::"user%host.JUNET@RELAY.CS.NET"
> JUNET IO::...!KDDLAB!host!user@RELAY.CS.NET
> UUCP IO::"host2!host1!host!user@UUNET.UU.NET"
> UUCP NSSDCA::EXOS%"host2!host1!host!user@UUNET.UU.NE
T"
>
>
> GatewaysTable
>
> UUCP
>
> From To Syntax
> UUCP ACSNET UUNET!MUNNARI!host.OZ.AU!user
> ARPA UUNET!host.domain!user
> BITNET PSUVAX1!host.BITNET!user
> JANET relay!NSS.CS.UCL.AC.UK!host.UK!user
> JUNET relay!host.JUNET!user
> SPAN user%host.SPAN@VLSI.JPL.NASA.GOV
> SPAN user%host@IO.ARC.NASA.GOV
> UUCP host1!host2!host!user
>
-=(~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~)=-
-=( Rafael Muller Sierra |INTERNET: 802376335@rumac.upr.cun.edu )=-
-=( University of Puerto Rico | R_MULLER@cuhac.upr.cun.edu )=-
-=( Mayaguez Campus | UPRENET: RUMAC::802376335 )=-
-=( College of Agriculture | CUHAC::R_MULLER )=-
-=( and Mechanical Arts. C.A.A.M. | )=-
-=( Disclaimer: )=-
-=( "Where computer knowledge is integrated... I get desintegrated" )=-
-=(_______________________________________________________________________)=-
________________________________________________________________________________
You might want to check out the book THE MATRIX: A WORLD-WIDE
CONFERENCING SYSTEM by John Quarterman and available from
Digital Press. It covers all of the nets.
Dave Harbula Edinboro University of PA
Internet: harbula@edinboro.edu Edinboro, PA 16444
Uucp: ...pitt!cuphub!edinboro!harbula (814) 732-2931
______________________________________________________________________________
Howdy,
You will want to pick up the nutshell handbook "!%@:: Addressing &
Networks" from O'Reilly and Associates, Inc. Their phone number is :
1-800-338-NUTS.
TTFN,
Ray
>________________________________________________________________________________
>|Louis W. Sefranek | INTERNET: LWS%VAXB.DECNET.NUSC-NPT.NAVY.MIL |
>|Computer Services Division|----------------------------------------------------
>|Aquidenck Data Corporation| definition of tension- |
>|170 Enterprise Center | finding yourself behind a Ford pinto and in front |
>|Middletown RI 02840 | of an Audi 5000. |
>|(401)-847-7260 ext. 333 | "????" |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And next to a Suzuki Samurai on a curve.
---
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ray Smith | UUCP: {uunet,aplcen,sundc}!anagld!rcsmith
Analytics, Inc. | ARPA: rcsmith@analytics.com or
Suite 200 | anagld!rcsmith@uunet.uu.net or
9891 Broken Land Parkway | RCSmith@DOCKMASTER.NCSC.MIL
Columbia, MD 21046 | Voice: (301) 381-4300 Fax: (301) 381-5173
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
_______________________________________________________________________________
Network Working Group E. Krol
Request for Comments: 1118 University of Illinois Urbana
September 1989
The Hitchhikers Guide to the Internet
Status of this Memo
This RFC is being distributed to members of the Internet community in
order to make available some "hints" which will allow new network
participants to understand how the direction of the Internet is set,
how to acquire online information and how to be a good Internet
neighbor. While the information discussed may not be relevant to the
research problems of the Internet, it may be interesting to a number
of researchers and implementors. No standards are defined or
specified in this memo. Distribution of this memo is unlimited.
NOTICE:
The hitchhikers guide to the Internet is a very unevenly edited memo
and contains many passages which simply seemed to its editors like a
good idea at the time. It is an indispensable companion to all those
who are keen to make sense of life in an infinitely complex and
confusing Internet, for although it cannot hope to be useful or
informative on all matters, it does make the reassuring claim that
where it is inaccurate, it is at least definitively inaccurate. In
cases of major discrepancy it is always reality that's got it wrong.
And remember, DON'T PANIC. (Apologies to Douglas Adams.)
Purpose and Audience
This document assumes that one is familiar with the workings of a
non-connected simple IP network (e.g., a few 4.3 BSD systems on an
Ethernet not connected to anywhere else). Appendix A contains
remedial information to get one to this point. Its purpose is to get
that person, familiar with a simple net, versed in the "oral
tradition" of the Internet to the point that that net can be
connected to the Internet with little danger to either. It is not a
tutorial, it consists of pointers to other places, literature, and
hints which are not normally documented. Since the Internet is a
dynamic environment, changes to this document will be made regularly.
The author welcomes comments and suggestions. This is especially
true of terms for the glossary (definitions are not necessary).
Krol [Page 1]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
What is the Internet?
In the beginning there was the ARPANET, a wide area experimental
network connecting hosts and terminal servers together. Procedures
were set up to regulate the allocation of addresses and to create
voluntary standards for the network. As local area networks became
more pervasive, many hosts became gateways to local networks. A
network layer to allow the interoperation of these networks was
developed and called Internet Protocol (IP). Over time other groups
created long haul IP based networks (NASA, NSF, states...). These
nets, too, interoperate because of IP. The collection of all of
these interoperating networks is the Internet.
A few groups provide much of the information services on the
Internet. Information Sciences Institute (ISI) does much of the
standardization and allocation work of the Internet acting as the
Internet Assigned Numbers Authority (IANA). SRI International
provides the principal information services for the Internet by
operating the Network Information Center (NIC). In fact, after you
are connected to the Internet most of the information in this
document can be retrieved from the SRI-NIC. Bolt Beranek and Newman
(BBN) provides information services for CSNET (the CIC) and NSFNET
(the NNSC), and Merit provides information services for NSFNET (the
NIS).
Operating the Internet
Each network, be it the ARPANET, NSFNET or a regional network, has
its own operations center. The ARPANET is run by BBN, Inc. under
contract from DCA (on behalf of DARPA). Their facility is called the
Network Operations Center or NOC. Merit, Inc. operates NSFNET from
yet another and completely seperate NOC. It goes on to the regionals
having similar facilities to monitor and keep watch over the goings
on of their portion of the Internet. In addition, they all should
have some knowledge of what is happening to the Internet in total.
If a problem comes up, it is suggested that a campus network liaison
should contact the network operator to which he is directly
connected. That is, if you are connected to a regional network
(which is gatewayed to the NSFNET, which is connected to the
ARPANET...) and have a problem, you should contact your regional
network operations center.
RFCs
The internal workings of the Internet are defined by a set of
documents called RFCs (Request for Comments). The general process
for creating an RFC is for someone wanting something formalized to
write a document describing the issue and mailing it to Jon Postel
Krol [Page 2]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
(Postel@ISI.EDU). He acts as a referee for the proposal. It is then
commented upon by all those wishing to take part in the discussion
(electronically of course). It may go through multiple revisions.
Should it be generally accepted as a good idea, it will be assigned a
number and filed with the RFCs.
There are two independent categorizations of protocols. The first is
the state of standardization which is one of "standard", "draft
standard", "proposed", "experimental", or "historic". The second is
the status of this protocol which is one of "required",
"recommended", "elective", or "not recommended". One could expect a
particular protocol to move along the scale of status from elective
to required at the same time as it moves along the scale of
standardization from proposed to standard.
A Required Standard protocol (e.g., RFC-791, The Internet Protocol)
must be implemented on any host connected to the Internet.
Recommended Standard protocols are generally implemented by network
hosts. Lack of them does not preclude access to the Internet, but
may impact its usability. RFC-793 (Transmission Control Protocol) is
a Recommended Standard protocol. Elective Proposed protocols were
discussed and agreed to, but their application has never come into
wide use. This may be due to the lack of wide need for the specific
application (RFC-937, The Post Office Protocol) or that, although
technically superior, ran against other pervasive approaches. It is
suggested that should the facility be required by a particular site,
an implementation be done in accordance with the RFC. This insures
that, should the idea be one whose time has come, the implementation
will be in accordance with some standard and will be generally
usable.
Informational RFCs contain factual information about the Internet and
its operation (RFC-1010, Assigned Numbers). Finally, as the Internet
and technology have grown, some RFCs have become unnecessary. These
obsolete RFCs cannot be ignored, however. Frequently when a change
is made to some RFC that causes a new one to be issued obsoleting
others, the new RFC may only contains explanations and motivations
for the change. Understanding the model on which the whole facility
is based may involve reading the original and subsequent RFCs on the
topic. (Appendix B contains a list of what are considered to be the
major RFCs necessary for understanding the Internet).
Only a few RFCs actually specify standards, most RFCs are for
information or discussion purposes. To find out what the current
standards are see the RFC titled "IAB Official Protocol Standards"
(most recently published as RFC-1100).
Krol [Page 3]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
The Network Information Center (NIC)
The NIC is a facility available to all Internet users which provides
information to the community. There are three means of NIC contact:
network, telephone, and mail. The network accesses are the most
prevalent. Interactive access is frequently used to do queries of
NIC service overviews, look up user and host names, and scan lists of
NIC documents. It is available by using
%telnet nic.ddn.mil
on a BSD system, and following the directions provided by a user
friendly prompter. From poking around in the databases provided, one
might decide that a document named NETINFO:NUG.DOC (The Users Guide
to the ARPANET) would be worth having. It could be retrieved via an
anonymous FTP. An anonymous FTP would proceed something like the
following. (The dialogue may vary slightly depending on the
implementation of FTP you are using).
%ftp nic.ddn.mil
Connected to nic.ddn.mil
220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT
Name (nic.ddn.mil:myname): anonymous
331 ANONYMOUS user ok, send real ident as password.
Password: myname
230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.
ftp> get netinfo:nug.doc
200 Port 18.144 at host 128.174.5.50 accepted.
150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
226 Transfer Completed 157675 (8) bytes transferred
local: netinfo:nug.doc remote:netinfo:nug.doc
157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
ftp> quit
221 QUIT command received. Goodbye.
(Another good initial document to fetch is NETINFO:WHAT-THE-NIC-
DOES.TXT).
Questions of the NIC or problems with services can be asked of or
reported to using electronic mail. The following addresses can be
used:
NIC@NIC.DDN.MIL General user assistance, document requests
REGISTRAR@NIC.DDN.MIL User registration and WHOIS updates
HOSTMASTER@NIC.DDN.MIL Hostname and domain changes and updates
ACTION@NIC.DDN.MIL SRI-NIC computer operations
SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and services
Krol [Page 4]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
For people without network access, or if the number of documents is
large, many of the NIC documents are available in printed form for a
small charge. One frequently ordered document for starting sites is
a compendium of major RFCs. Telephone access is used primarily for
questions or problems with network access. (See appendix B for
mail/telephone contact numbers).
The NSFNET Network Service Center
The NSFNET Network Service Center (NNSC), located at BBN Systems and
Technologies Corp., is a project of the University Corporation for
Atmospheric Research under agreement with the National Science
Foundation. The NNSC provides support to end-users of NSFNET should
they have questions or encounter problems traversing the network.
The NNSC, which has information and documents online and in printed
form, distributes news through network mailing lists, bulletins, and
online reports. NNSC publications include a hardcopy newsletter, the
NSF Network News, which contains articles of interest to network
users and the Internet Resource Guide, which lists facilities (such
as supercomputer centers and on-line library catalogues) accessible
from the Internet. The Resource Guide can be obtained via anonymous
ftp to nnsc.nsf.net in the directory resource-guide, or by joining
the resource guide mailing list (send a subscription request to
Resource-Guide-Request@NNSC.NSF.NET.)
Mail Reflectors
The way most people keep up to date on network news is through
subscription to a number of mail reflectors (also known as mail
exploders). Mail reflectors are special electronic mailboxes which,
when they receive a message, resend it to a list of other mailboxes.
This in effect creates a discussion group on a particular topic.
Each subscriber sees all the mail forwarded by the reflector, and if
one wants to put his "two cents" in sends a message with the comments
to the reflector.
The general format to subscribe to a mail list is to find the address
reflector and append the string -REQUEST to the mailbox name (not the
host name). For example, if you wanted to take part in the mailing
list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends a
request to NSFNET-INFO-REQUEST@MERIT.EDU. This may be a wonderful
scheme, but the problem is that you must know the list exists in the
first place. It is suggested that, if you are interested, you read
the mail from one list (like NSFNET-INFO) and you will probably
become familiar with the existence of others. A registration service
for mail reflectors is provided by the NIC in the files
NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT,
Krol [Page 5]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
NETINFO:INTEREST-GROUPS-3.TXT, through NETINFO:INTEREST-GROUPS-9.TXT.
The NSFNET-INFO mail reflector is targeted at those people who have a
day to day interest in the news of the NSFNET (the backbone, regional
network, and Internet inter-connection site workers). The messages
are reflected by a central location and are sent as separate messages
to each subscriber. This creates hundreds of messages on the wide
area networks where bandwidth is the scarcest.
There are two ways in which a campus could spread the news and not
cause these messages to inundate the wide area networks. One is to
re-reflect the message on the campus. That is, set up a reflector on
a local machine which forwards the message to a campus distribution
list. The other is to create an alias on a campus machine which
places the messages into a notesfile on the topic. Campus users who
want the information could access the notesfile and see the messages
that have been sent since their last access. One might also elect to
have the campus wide area network liaison screen the messages in
either case and only forward those which are considered of merit.
Either of these schemes allows one message to be sent to the campus,
while allowing wide distribution within.
Address Allocation
Before a local network can be connected to the Internet it must be
allocated a unique IP address. These addresses are allocated by
SRI-NIC. The allocation process consists of getting an application
form. Send a message to Hostmaster@NIC.DDN.MIL and ask for the
template for a connected address. This template is filled out and
mailed back to the hostmaster. An address is allocated and e-mailed
back to you. This can also be done by postal mail (Appendix B).
IP addresses are 32 bits long. It is usually written as four decimal
numbers separated by periods (e.g., 192.17.5.100). Each number is
the value of an octet of the 32 bits. Some networks might choose to
organize themselves as very flat (one net with a lot of nodes) and
some might organize hierarchically (many interconnected nets with
fewer nodes each and a backbone). To provide for these cases,
addresses were differentiated into class A, B, and C networks. This
classification had to with the interpretation of the octets. Class A
networks have the first octet as a network address and the remaining
three as a host address on that network. Class C addresses have
three octets of network address and one of host. Class B is split
two and two. Therefore, there is an address space for a few large
nets, a reasonable number of medium nets and a large number of small
nets. The high order bits in the first octet are coded to tell the
address format. There are very few unallocated class A nets, so a
very good case must be made for them. So as a practical matter, one
Krol [Page 6]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
has to choose between Class B and Class C when placing an order.
(There are also class D (Multicast) and E (Experimental) formats.
Multicast addresses will likely come into greater use in the near
future, but are not frequently used yet).
In the past, sites requiring multiple network addresses requested
multiple discrete addresses (usually Class C). This was done because
much of the software available (notably 4.2BSD) could not deal with
subnetted addresses. Information on how to reach a particular
network (routing information) must be stored in Internet gateways and
packet switches. Some of these nodes have a limited capability to
store and exchange routing information (limited to about 700
networks). Therefore, it is suggested that any campus announce (make
known to the Internet) no more than two discrete network numbers.
If a campus expects to be constrained by this, it should consider
subnetting. Subnetting (RFC-950) allows one to announce one address
to the Internet and use a set of addresses on the campus. Basically,
one defines a mask which allows the network to differentiate between
the network portion and host portion of the address. By using a
different mask on the Internet and the campus, the address can be
interpreted in multiple ways. For example, if a campus requires two
networks internally and has the 32,000 addresses beginning
128.174.X.X (a Class B address) allocated to it, the campus could
allocate 128.174.5.X to one part of campus and 128.174.10.X to
another. By advertising 128.174 to the Internet with a subnet mask
of FF.FF.00.00, the Internet would treat these two addresses as one.
Within the campus a mask of FF.FF.FF.00 would be used, allowing the
campus to treat the addresses as separate entities. (In reality, you
don't pass the subnet mask of FF.FF.00.00 to the Internet, the octet
meaning is implicit in its being a class B address).
A word of warning is necessary. Not all systems know how to do
subnetting. Some 4.2BSD systems require additional software. 4.3BSD
systems subnet as released. Other devices and operating systems vary
in the problems they have dealing with subnets. Frequently, these
machines can be used as a leaf on a network but not as a gateway
within the subnetted portion of the network. As time passes and more
systems become 4.3BSD based, these problems should disappear.
There has been some confusion in the past over the format of an IP
broadcast address. Some machines used an address of all zeros to
mean broadcast and some all ones. This was confusing when machines
of both type were connected to the same network. The broadcast
address of all ones has been adopted to end the grief. Some systems
(e.g., 4.3 BSD) allow one to choose the format of the broadcast
address. If a system does allow this choice, care should be taken
that the all ones format is chosen. (This is explained in RFC-1009
Krol [Page 7]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
and RFC-1010).
Internet Problems
There are a number of problems with the Internet. Solutions to the
problems range from software changes to long term research projects.
Some of the major ones are detailed below:
Number of Networks
When the Internet was designed it was to have about 50 connected
networks. With the explosion of networking, the number is now
approaching 1000. The software in a group of critical gateways
(called the core gateways) are not able to pass or store much more
than that number. In the short term, core reallocation and
recoding has raised the number slightly.
Routing Issues
Along with sheer mass of the data necessary to route packets to a
large number of networks, there are many problems with the
updating, stability, and optimality of the routing algorithms.
Much research is being done in the area, but the optimal solution
to these routing problems is still years away. In most cases, the
the routing we have today works, but sub-optimally and sometimes
unpredictably. The current best hope for a good routing protocol
is something known as OSPFIGP which will be generally available
from many router manufacturers within a year.
Trust Issues
Gateways exchange network routing information. Currently, most
gateways accept on faith that the information provided about the
state of the network is correct. In the past this was not a big
problem since most of the gateways belonged to a single
administrative entity (DARPA). Now, with multiple wide area
networks under different administrations, a rogue gateway
somewhere in the net could cripple the Internet. There is design
work going on to solve both the problem of a gateway doing
unreasonable things and providing enough information to reasonably
route data between multiply connected networks (multi-homed
networks).
Capacity & Congestion
Some portions of the Internet are very congested during the busy
part of the day. Growth is dramatic with some networks
experiencing growth in traffic in excess of 20% per month.
Krol [Page 8]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
Additional bandwidth is planned, but delivery and budgets might
not allow supply to keep up.
Setting Direction and Priority
The Internet Activities Board (IAB), currently chaired by Vint Cerf
of NRI, is responsible for setting the technical direction,
establishing standards, and resolving problems in the Internet.
The current IAB members are:
Vinton Cerf - Chairman
David Clark - IRTF Chairman
Phillip Gross - IETF Chairman
Jon Postel - RFC Editor
Robert Braden - Executive Director
Hans-Werner Braun - NSFNET Liaison
Barry Leiner - CCIRN Liaison
Daniel Lynch - Vendor Liaison
Stephen Kent - Internet Security
This board is supported by a Research Task Force (chaired by Dave
Clark of MIT) and an Engineering Task Force (chaired by Phill Gross
of NRI).
The Internet Research Task Force has the following Research Groups:
Autonomous Networks Deborah Estrin
End-to-End Services Bob Braden
Privacy Steve Kent
User Interfaces Keith Lantz
The Internet Engineering Task Force has the following technical
areas:
Applications TBD
Host Protocols Craig Partridge
Internet Protocols Noel Chiappa
Routing Robert Hinden
Network Management David Crocker
OSI Interoperability Ross Callon, Robert Hagen
Operations TBD
Security TBD
The Internet Engineering Task Force has the following Working Groups:
ALERTMAN Louis Steinberg
Authentication Jeff Schiller
Krol [Page 9]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
CMIP over TCP Lee LaBarre
Domain Names Paul Mockapetris
Dynamic Host Config Ralph Droms
Host Requirements Bob Braden
Interconnectivity Guy Almes
Internet MIB Craig Partridge
Joint Management Susan Hares
LAN Mgr MIB Amatzia Ben-Artzi
NISI Karen Bowers
NM Serial Interface Jeff Case
NOC Tools Bob Enger
OSPF Mike Petry
Open Systems Routing Marianne Lepp
OSI Interoperability Ross Callon
PDN Routing Group CH Rokitansky
Performance and CC Allison Mankin
Point - Point IP Drew Perkins
ST and CO-IP Claudio Topolcic
Telnet Dave Borman
User Documents Karen Roubicek
User Services Karen Bowers
Routing
Routing is the algorithm by which a network directs a packet from its
source to its destination. To appreciate the problem, watch a small
child trying to find a table in a restaurant. From the adult point
of view, the structure of the dining room is seen and an optimal
route easily chosen. The child, however, is presented with a set of
paths between tables where a good path, let alone the optimal one to
the goal is not discernible.
A little more background might be appropriate. IP gateways (more
correctly routers) are boxes which have connections to multiple
networks and pass traffic between these nets. They decide how the
packet is to be sent based on the information in the IP header of the
packet and the state of the network. Each interface on a router has
an unique address appropriate to the network to which it is
connected. The information in the IP header which is used is
primarily the destination address. Other information (e.g., type of
service) is largely ignored at this time. The state of the network
is determined by the routers passing information among themselves.
The distribution of the database (what each node knows), the form of
the updates, and metrics used to measure the value of a connection,
are the parameters which determine the characteristics of a routing
protocol.
Under some algorithms, each node in the network has complete
Krol [Page 10]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
knowledge of the state of the network (the adult algorithm). This
implies the nodes must have larger amounts of local storage and
enough CPU to search the large tables in a short enough time
(remember, this must be done for each packet). Also, routing updates
usually contain only changes to the existing information (or you
spend a large amount of the network capacity passing around megabyte
routing updates). This type of algorithm has several problems.
Since the only way the routing information can be passed around is
across the network and the propagation time is non-trivial, the view
of the network at each node is a correct historical view of the
network at varying times in the past. (The adult algorithm, but
rather than looking directly at the dining area, looking at a
photograph of the dining room. One is likely to pick the optimal
route and find a bus-cart has moved in to block the path after the
photo was taken). These inconsistencies can cause circular routes
(called routing loops) where once a packet enters it is routed in a
closed path until its time to live (TTL) field expires and it is
discarded.
Other algorithms may know about only a subset of the network. To
prevent loops in these protocols, they are usually used in a
hierarchical network. They know completely about their own area, but
to leave that area they go to one particular place (the default
gateway). Typically these are used in smaller networks (campus or
regional).
Routing protocols in current use:
Static (no protocol-table/default routing)
Don't laugh. It is probably the most reliable, easiest to
implement, and least likely to get one into trouble for a small
network or a leaf on the Internet. This is, also, the only method
available on some CPU-operating system combinations. If a host is
connected to an Ethernet which has only one gateway off of it, one
should make that the default gateway for the host and do no other
routing. (Of course, that gateway may pass the reachability
information somehow on the other side of itself.)
One word of warning, it is only with extreme caution that one
should use static routes in the middle of a network which is also
using dynamic routing. The routers passing dynamic information
are sometimes confused by conflicting dynamic and static routes.
If your host is on an ethernet with multiple routers to other
networks on it and the routers are doing dynamic routing among
themselves, it is usually better to take part in the dynamic
routing than to use static routes.
Krol [Page 11]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
RIP
RIP is a routing protocol based on XNS (Xerox Network System)
adapted for IP networks. It is used by many routers (Proteon,
cisco, UB...) and many BSD Unix systems. BSD systems typically
run a program called "routed" to exchange information with other
systems running RIP. RIP works best for nets of small diameter
(few hops) where the links are of equal speed. The reason for
this is that the metric used to determine which path is best is
the hop-count. A hop is a traversal across a gateway. So, all
machines on the same Ethernet are zero hops away. If a router
connects connects two networks directly, a machine on the other
side of the router is one hop away. As the routing information is
passed through a gateway, the gateway adds one to the hop counts
to keep them consistent across the network. The diameter of a
network is defined as the largest hop-count possible within a
network. Unfortunately, a hop count of 16 is defined as infinity
in RIP meaning the link is down. Therefore, RIP will not allow
hosts separated by more than 15 gateways in the RIP space to
communicate.
The other problem with hop-count metrics is that if links have
different speeds, that difference is not reflected in the hop-
count. So a one hop satellite link (with a .5 sec delay) at 56kb
would be used instead of a two hop T1 connection. Congestion can
be viewed as a decrease in the efficacy of a link. So, as a link
gets more congested, RIP will still know it is the best hop-count
route and congest it even more by throwing more packets on the
queue for that link.
RIP was originally not well documented in the community and people
read BSD code to find out how RIP really worked. Finally, it was
documented in RFC-1058.
Routed
The routed program, which does RIP for 4.2BSD systems, has many
options. One of the most frequently used is: "routed -q" (quiet
mode) which means listen to RIP information, but never broadcast
it. This would be used by a machine on a network with multiple
RIP speaking gateways. It allows the host to determine which
gateway is best (hopwise) to use to reach a distant network. (Of
course, you might want to have a default gateway to prevent having
to pass all the addresses known to the Internet around with RIP.)
There are two ways to insert static routes into routed; the
/etc/gateways file, and the "route add" command. Static routes
are useful if you know how to reach a distant network, but you are
Krol [Page 12]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
not receiving that route using RIP. For the most part the "route
add" command is preferable to use. The reason for this is that
the command adds the route to that machine's routing table but
does not export it through RIP. The /etc/gateways file takes
precedence over any routing information received through a RIP
update. It is also broadcast as fact in RIP updates produced by
the host without question, so if a mistake is made in the
/etc/gateways file, that mistake will soon permeate the RIP space
and may bring the network to its knees.
One of the problems with routed is that you have very little
control over what gets broadcast and what doesn't. Many times in
larger networks where various parts of the network are under
different administrative controls, you would like to pass on
through RIP only nets which you receive from RIP and you know are
reasonable. This prevents people from adding IP addresses to the
network which may be illegal and you being responsible for passing
them on to the Internet. This type of reasonability checks are
not available with routed and leave it usable, but inadequate for
large networks.
Hello (RFC-891)
Hello is a routing protocol which was designed and implemented in
a experimental software router called a "Fuzzball" which runs on a
PDP-11. It does not have wide usage, but is the routing protocol
formerly used on the initial NSFNET backbone. The data
transferred between nodes is similar to RIP (a list of networks
and their metrics). The metric, however, is milliseconds of
delay. This allows Hello to be used over nets of various link
speeds and performs better in congestive situations.
One of the most interesting side effects of Hello based networks
is their great timekeeping ability. If you consider the problem
of measuring delay on a link for the metric, you find that it is
not an easy thing to do. You cannot measure round trip time since
the return link may be more congested, of a different speed, or
even not there. It is not really feasible for each node on the
network to have a builtin WWV (nationwide radio time standard)
receiver. So, you must design an algorithm to pass around time
between nodes over the network links where the delay in
transmission can only be approximated. Hello routers do this and
in a nationwide network maintain synchronized time within
milliseconds. (See also the Network Time Protocol, RFC-1059.)
Krol [Page 13]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
Gateway Gateway Protocol (GGP RFC-823)
The core gateways originally used GGP to exchange information
among themselves. This is a "distance-vector" algorithm. The new
core gateways use a "link-state" algorithm.
NSFNET SPF (RFC-1074)
The current NSFNET Backbone routers use a version of the ANSI IS-
IS and ISO ES-IS routing protocol. This is a "shortest path
first" (SPF) algorithm which is in the class of "link-state"
algorithms.
Exterior Gateway Protocol (EGP RFC-904)
EGP is not strictly a routing protocol, it is a reachability
protocol. It tells what nets can be reached through what gateway,
but not how good the connection is. It is the standard by which
gateways exchange network reachability information with the core
gateways. It is generally used between autonomous systems. There
is a metric passed around by EGP, but its usage is not
standardized formally. The metric's value ranges from 0 to 255
with smaller values considered "better". Some implementations
consider the value 255 to mean unreachable. Many routers talk EGP
so they can be used to interface to routers of different
manufacture or operated by different administrations. For
example, when a router of the NSFNET Backbone exchanges routing or
reachability information with a gateway of a regional network EGP
is used.
Gated
So we have regional and campus networks talking RIP among
themselves and the DDN and NSFNET speaking EGP. How do they
interoperate? In the beginning, there was static routing. The
problem with doing static routing in the middle of the network is
that it is broadcast to the Internet whether it is usable or not.
Therefore, if a net becomes unreachable and you try to get there,
dynamic routing will immediately issue a net unreachable to you.
Under static routing the routers would think the net could be
reached and would continue trying until the application gave up
(in 2 or more minutes). Mark Fedor, then of Cornell, attempted to
solve these problems with a replacement for routed called gated.
Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and
Hello to Hello'ers. These speakers frequently all live on one
Ethernet, but luckily (or unluckily) cannot understand each others
ruminations. In addition, under configuration file control it can
Krol [Page 14]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
filter the conversion. For example, one can produce a
configuration saying announce RIP nets via Hello only if they are
specified in a list and are reachable by way of a RIP broadcast as
well. This means that if a rogue network appears in your local
site's RIP space, it won't be passed through to the Hello side of
the world. There are also configuration options to do static
routing and name trusted gateways.
This may sound like the greatest thing since sliced bread, but
there is a catch called metric conversion. You have RIP measuring
in hops, Hello measuring in milliseconds, and EGP using arbitrary
small numbers. The big questions is how many hops to a
millisecond, how many milliseconds in the EGP number 3.... Also,
remember that infinity (unreachability) is 16 to RIP, 30000 or so
to Hello, and 8 to the DDN with EGP. Getting all these metrics to
work well together is no small feat. If done incorrectly and you
translate an RIP of 16 into an EGP of 6, everyone in the ARPANET
will still think your gateway can reach the unreachable and will
send every packet in the world your way. Gated is available via
anonymous FTP from devvax.tn.cornell.edu in directory pub/gated.
Names
All routing across the network is done by means of the IP address
associated with a packet. Since humans find it difficult to remember
addresses like 128.174.5.50, a symbolic name register was set up at
the NIC where people would say, "I would like my host to be named
uiucuxc". Machines connected to the Internet across the nation would
connect to the NIC in the middle of the night, check modification
dates on the hosts file, and if modified, move it to their local
machine. With the advent of workstations and micros, changes to the
host file would have to be made nightly. It would also be very labor
intensive and consume a lot of network bandwidth. RFC-1034 and a
number of others describe Domain Name Service (DNS), a distributed
data base system for mapping names into addresses.
We must look a little more closely into what's in a name. First,
note that an address specifies a particular connection on a specific
network. If the machine moves, the address changes. Second, a
machine can have one or more names and one or more network addresses
(connections) to different networks. Names point to a something
which does useful work (i.e., the machine) and IP addresses point to
an interface on that provider. A name is a purely symbolic
representation of a list of addresses on the network. If a machine
moves to a different network, the addresses will change but the name
could remain the same.
Domain names are tree structured names with the root of the tree at
Krol [Page 15]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
the right. For example:
uxc.cso.uiuc.edu
is a machine called "uxc" (purely arbitrary), within the subdomains
of the U of I, and "uiuc" (the University of Illinois at Urbana),
registered with "edu" (the set of educational institutions).
A simplified model of how a name is resolved is that on the user's
machine there is a resolver. The resolver knows how to contact
across the network a root name server. Root servers are the base of
the tree structured data retrieval system. They know who is
responsible for handling first level domains (e.g., 'edu'). What
root servers to use is an installation parameter. From the root
server the resolver finds out who provides 'edu' service. It
contacts the 'edu' name server which supplies it with a list of
addresses of servers for the subdomains (like 'uiuc'). This action
is repeated with the sub-domain servers until the final subdomain
returns a list of addresses of interfaces on the host in question.
The user's machine then has its choice of which of these addresses to
use for communication.
A group may apply for its own domain name (like 'uiuc' above). This
is done in a manner similar to the IP address allocation. The only
requirements are that the requestor have two machines reachable from
the Internet, which will act as name servers for that domain. Those
servers could also act as servers for subdomains or other servers
could be designated as such. Note that the servers need not be
located in any particular place, as long as they are reachable for
name resolution. (U of I could ask Michigan State to act on its
behalf and that would be fine.) The biggest problem is that someone
must do maintenance on the database. If the machine is not
convenient, that might not be done in a timely fashion. The other
thing to note is that once the domain is allocated to an
administrative entity, that entity can freely allocate subdomains
using what ever manner it sees fit.
The Berkeley Internet Name Domain (BIND) Server implements the
Internet name server for UNIX systems. The name server is a
distributed data base system that allows clients to name resources
and to share that information with other network hosts. BIND is
integrated with 4.3BSD and is used to lookup and store host names,
addresses, mail agents, host information, and more. It replaces the
/etc/hosts file or host name lookup. BIND is still an evolving
program. To keep up with reports on operational problems, future
design decisions, etc., join the BIND mailing list by sending a
request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also be
obtained via anonymous FTP from ucbarpa.berkeley.edu.
Krol [Page 16]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
There are several advantages in using BIND. One of the most
important is that it frees a host from relying on /etc/hosts being up
to date and complete. Within the .uiuc.edu domain, only a few hosts
are included in the host table distributed by SRI. The remainder are
listed locally within the BIND tables on uxc.cso.uiuc.edu (the server
machine for most of the .uiuc.edu domain). All are equally reachable
from any other Internet host running BIND, or any DNS resolver.
BIND can also provide mail forwarding information for interior hosts
not directly reachable from the Internet. These hosts an either be
on non-advertised networks, or not connected to an IP network at all,
as in the case of UUCP-reachable hosts (see RFC-974). More
information on BIND is available in the "Name Server Operations Guide
for BIND" in UNIX System Manager's Manual, 4.3BSD release.
There are a few special domains on the network, like NIC.DDN.MIL.
The hosts database at the NIC. There are others of the form
NNSC.NSF.NET. These special domains are used sparingly, and require
ample justification. They refer to servers under the administrative
control of the network rather than any single organization. This
allows for the actual server to be moved around the net while the
user interface to that machine remains constant. That is, should BBN
relinquish control of the NNSC, the new provider would be pointed to
by that name.
In actuality, the domain system is a much more general and complex
system than has been described. Resolvers and some servers cache
information to allow steps in the resolution to be skipped.
Information provided by the servers can be arbitrary, not merely IP
addresses. This allows the system to be used both by non-IP networks
and for mail, where it may be necessary to give information on
intermediate mail bridges.
What's wrong with Berkeley Unix
University of California at Berkeley has been funded by DARPA to
modify the Unix system in a number of ways. Included in these
modifications is support for the Internet protocols. In earlier
versions (e.g., BSD 4.2) there was good support for the basic
Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform
nicely on IP Ethernets and smaller Internets. There were
deficiencies, however, when it was connected to complicated networks.
Most of these problems have been resolved under the newest release
(BSD 4.3). Since it is the springboard from which many vendors have
launched Unix implementations (either by porting the existing code or
by using it as a model), many implementations (e.g., Ultrix) are
still based on BSD 4.2. Therefore, many implementations still exist
with the BSD 4.2 problems. As time goes on, when BSD 4.3 trickles
Krol [Page 17]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
through vendors as new release, many of the problems will be
resolved. Following is a list of some problem scenarios and their
handling under each of these releases.
ICMP redirects
Under the Internet model, all a system needs to know to get
anywhere in the Internet is its own address, the address of where
it wants to go, and how to reach a gateway which knows about the
Internet. It doesn't have to be the best gateway. If the system
is on a network with multiple gateways, and a host sends a packet
for delivery to a gateway which feels another directly connected
gateway is more appropriate, the gateway sends the sender a
message. This message is an ICMP redirect, which politely says,
"I'll deliver this message for you, but you really ought to use
that gateway over there to reach this host". BSD 4.2 ignores
these messages. This creates more stress on the gateways and the
local network, since for every packet sent, the gateway sends a
packet to the originator. BSD 4.3 uses the redirect to update its
routing tables, will use the route until it times out, then revert
to the use of the route it thinks is should use. The whole
process then repeats, but it is far better than one per packet.
Trailers
An application (like FTP) sends a string of octets to TCP which
breaks it into chunks, and adds a TCP header. TCP then sends
blocks of data to IP which adds its own headers and ships the
packets over the network. All this prepending of the data with
headers causes memory moves in both the sending and the receiving
machines. Someone got the bright idea that if packets were long
and they stuck the headers on the end (they became trailers), the
receiving machine could put the packet on the beginning of a page
boundary and if the trailer was OK merely delete it and transfer
control of the page with no memory moves involved. The problem is
that trailers were never standardized and most gateways don't know
to look for the routing information at the end of the block. When
trailers are used, the machine typically works fine on the local
network (no gateways involved) and for short blocks through
gateways (on which trailers aren't used). So TELNET and FTP's of
very short files work just fine and FTP's of long files seem to
hang. On BSD 4.2 trailers are a boot option and one should make
sure they are off when using the Internet. BSD 4.3 negotiates
trailers, so it uses them on its local net and doesn't use them
when going across the network.
Krol [Page 18]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
Retransmissions
TCP fires off blocks to its partner at the far end of the
connection. If it doesn't receive an acknowledgement in a
reasonable amount of time it retransmits the blocks. The
determination of what is reasonable is done by TCP's
retransmission algorithm.
There is no correct algorithm but some are better than others,
where worse is measured by the number of retransmissions done
unnecessarily. BSD 4.2 had a retransmission algorithm which
retransmitted quickly and often. This is exactly what you would
want if you had a bunch of machines on an Ethernet (a low delay
network of large bandwidth). If you have a network of relatively
longer delay and scarce bandwidth (e.g., 56kb lines), it tends to
retransmit too aggressively. Therefore, it makes the networks and
gateways pass more traffic than is really necessary for a given
conversation. Retransmission algorithms do adapt to the delay of
the network after a few packets, but 4.2's adapts slowly in delay
situations. BSD 4.3 does a lot better and tries to do the best
for both worlds. It fires off a few retransmissions really
quickly assuming it is on a low delay network, and then backs off
very quickly. It also allows the delay to be about 4 minutes
before it gives up and declares the connection broken.
Even better than the original 4.3 code is a version of TCP with a
retransmission algorithm developed by Van Jacobson of LBL. He did
a lot of research into how the algorithm works on real networks
and modified it to get both better throughput and be friendlier to
the network. This code has been integrated into the later
releases of BSD 4.3 and can be fetched anonymously from
ucbarpa.berkeley.edu in directory 4.3.
Time to Live
The IP packet header contains a field called the time to live
(TTL) field. It is decremented each time the packet traverses a
gateway. TTL was designed to prevent packets caught in routing
loops from being passed forever with no hope of delivery. Since
the definition bears some likeness to the RIP hop count, some
misguided systems have set the TTL field to 15 because the
unreachable flag in RIP is 16. Obviously, no networks could have
more than 15 hops. The RIP space where hops are limited ends when
RIP is not used as a routing protocol any more (e.g., when NSFnet
starts transporting the packet). Therefore, it is quite easy for
a packet to require more than 15 hops. These machines will
exhibit the behavior of being able to reach some places but not
others even though the routing information appears correct.
Krol [Page 19]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
Solving the problem typically requires kernel patches so it may be
difficult if source is not available.
Appendix A - References to Remedial Information
-----------------------------------------------
[1] Quarterman and Hoskins, "Notable Computer Networks",
Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October
1986.
[2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
[3] Hedrick, C., "Introduction to the Internet Protocols", Via
Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,
file tcp-ip-intro.doc.
[4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
and Architecture", Copyright 1988, by Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.
Appendix B - List of Major RFCs
-------------------------------
This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds. This
is the 30 August 1989 edition of the list.
RFC-768 User Datagram Protocol (UDP)
RFC-791 Internet Protocol (IP)
RFC-792 Internet Control Message Protocol (ICMP)
RFC-793 Transmission Control Protocol (TCP)
RFC-821 Simple Mail Transfer Protocol (SMTP)
RFC-822 Standard for the Format of ARPA Internet Text Messages
RFC-826 Ethernet Address Resolution Protocol
RFC-854 Telnet Protocol
RFC-862 Echo Protocol
RFC-894 A Standard for the Transmission of IP
Datagrams over Ethernet Networks
RFC-904 Exterior Gateway Protocol
RFC-919 Broadcasting Internet Datagrams
RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets
RFC-950 Internet Standard Subnetting Procedure
RFC-951 Bootstrap Protocol (BOOTP)
RFC-959 File Transfer Protocol (FTP)
RFC-966 Host Groups: A Multicast Extension to the Internet Protocol
RFC-974 Mail Routing and the Domain System
RFC-1000 The Request for Comments Reference Guide
RFC-1009 Requirements for Internet Gateways
RFC-1010 Assigned Numbers
Krol [Page 20]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
RFC-1011 Official Internet Protocols
RFC-1012 Bibliography of Request for Comments 1 through 999
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation
RFC-1042 A Standard for the Transmission of IP
Datagrams over IEEE 802 Networks
RFC-1048 BOOTP Vendor Information Extensions
RFC-1058 Routing Information Protocol
RFC-1059 Network Time Protocol (NTP)
RFC-1065 Structure and Identification of
Management Information for TCP/IP-based internets
RFC-1066 Management Information Base for Network
Management of TCP/IP-based internets
RFC-1084 BOOTP Vendor Information Extensions
RFC-1087 Ethics and the Internet
RFC-1095 The Common Management Information
Services and Protocol over TCP/IP (CMOT)
RFC-1098 A Simple Network Management Protocol (SNMP)
RFC-1100 IAB Official Protocol Standards
RFC-1101 DNS Encoding of Network Names and Other Types
RFC-1112 Host Extensions for IP Multicasting
RFC-1117 Internet Numbers
Note: This list is a portion of a list of RFC's by topic that may be
retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of
course).
The following list is not necessary for connection to the Internet,
but is useful in understanding the domain system, mail system, and
gateways:
RFC-974 Mail Routing and the Domain System
RFC-1009 Requirements for Internet Gateways
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation and Specification
RFC-1101 DNS Encoding of Network Names and Other Types
Krol [Page 21]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
Appendix C - Contact Points for Network Information
---------------------------------------------------
Network Information Center (NIC)
DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025
(800) 235-3155 or (415) 859-3695
NIC@NIC.DDN.MIL
NSF Network Service Center (NNSC)
NNSC
BBN Systems and Technology Corporation
10 Moulton St.
Cambridge, MA 02238
(617) 873-3400
NNSC@NNSC.NSF.NET
NSF Network Information Service (NIS)
NIS
Merit Inc.
University of Michigan
1075 Beal Avenue
Ann Arbor, MI 48109
(313) 763-4897
INFO@NIS.NSF.NET
CIC
CSNET Coordination and Information Center
Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02238
(617) 873-2777
INFO@SH.CS.NET
Krol [Page 22]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
Glossary
--------
autonomous system
A set of gateways under a single administrative control and using
compatible and consistent routing procedures. Generally speaking,
the gateways run by a particular organization. Since a gateway is
connected to two (or more) networks it is not usually correct to
say that a gateway is in a network. For example, the gateways
that connect regional networks to the NSF Backbone network are run
by Merit and form an autonomous system. Another example, the
gateways that connect campuses to NYSERNET are run by NYSER and
form an autonomous system.
core gateway
The innermost gateways of the Internet. These gateways have a
total picture of the reachability to all networks known to the
Internet. They then redistribute reachability information to
their neighbor gateways speaking EGP. It is from them your EGP
agent (there is one acting for you somewhere if you can reach the
core of the Internet) finds out it can reach all the nets on the
Internet. Which is then passed to you via Hello, gated, RIP. The
core gateways mostly connect campuses to the ARPANET, or
interconnect the ARPANET and the MILNET, and are run by BBN.
count to infinity
The symptom of a routing problem where routing information is
passed in a circular manner through multiple gateways. Each
gateway increments the metric appropriately and passes it on. As
the metric is passed around the loop, it increments to ever
increasing values until it reaches the maximum for the routing
protocol being used, which typically denotes a link outage.
hold down
When a router discovers a path in the network has gone down
announcing that that path is down for a minimum amount of time
(usually at least two minutes). This allows for the propagation
of the routing information across the network and prevents the
formation of routing loops.
split horizon
When a router (or group of routers working in consort) accept
routing information from multiple external networks, but do not
Krol [Page 23]
<FF>
RFC 1118 The Hitchhikers Guide to the Internet September 1989
pass on information learned from one external network to any
others. This is an attempt to prevent bogus routes to a network
from being propagated because of gossip or counting to infinity.
DDN
Defense Data Network the collective name for the ARPANET and
MILNET. Used frequently because although they are seperate
networks the operational and informational foci are the same.
Security Considerations
Security and privacy protection is a serious matter and too often
nothing is done about it. There are some known security bugs
(especially in access control) in BSD Unix and in some
implementations of network services. The hitchhikers guide does not
discuss these issues (too bad).
Author's Address
Ed Krol
University of Illinois
195 DCL
1304 West Springfield Avenue
Urbana, IL 61801-4399
Phone: (217) 333-7886
EMail: Krol@UXC.CSO.UIUC.EDU
Krol [Page 24]
<FF>