Re: Bitnet vs. Internet

[Lynn Ward <ward -at- UX1 -dot- CSO -dot- UIUC -dot- EDU>]

>My predecessor here at UIUC wrote a very nice piece called "Understanding
>e-mail Addresses."  I'll see if I can dredge up the original file and
>convert it to ASCII for this group.
>Lynn,

>I, for one, would really appreciate the receipt of that file.  Please try to
>find it.

>Cindy Hollingsworth
>cholling -at- indycms -dot- iupui -dot- edu

Here is the piece called "Understanding E-mail Addresses."  I did a very
quick and dirty Pagemaker to ASCII conversion.  Most bold or italiciaed
items are now surrounded with double quotes and the punctuation is
DELIBERATELY outside of the closing quote, so as not to be confused with
part of the addresses or terms used in the article.



                Understanding E-Mail Addresses

written by Carolyn A. Gedney

(based on an award-winning article series originally appearing in
the Vol. 3 #2 and  #3 of "UIUCnet," a publication of the
University of Illinois Computing Services Office.)

Introduction
------------
Thankfully, the age has come where different networks have been
integrated and made compatible with one another, at least to the
point where mail messages can be exchanged between them.  Network
evolution has not yet reached the point, however, of having a
uniform e-mail addressing scheme that is independent of the
network each user resides on.  It doesn't take long to realize
that electronic mail addresses take on a variety of formats and
syntaxes.  These formats may seem confusing and difficult to
interpret even to the long-time network user.  Yet  one only needs
a bit of patience to better understand them.

Network mail exchange depends not only on hardware arrangements of
the systems involved but on the software packages, such as
"mailers," that are responsible for routing incoming and outgoing
messages on any one machine.  Hardware as well as software
environments will vary from system to system on the path between
the sender and recipient of a message, and heterogenous e-mail
address formats abound as a result. This User Guide is designed to
help the typical UIUCnet user understand the e-mail address
environment.

1.  The Domain Naming System (DNS)
----------------------------------------
The syntax of an e-mail address which UIUCnet users probably see
most is based upon the Domain Name System (DNS).  This is due to
the fact that UIUCnet constitutes part of the Internet, and DNS is
incorporated in the Internet standard of mail addressing.  Strong
familiarity with DNS is stressed because other wide-area networks
are gradually converting to this system as individual network
addressing conventions are being phased out.  This turnover is far
from complete, however.  In Sections 4-8, specific address
conventions between the three primary networks to which UIUCnet
has e-mail access will be discussed.

The DNS is a distributed, hierarchical structure of names used by
most Internet applications including e-mail, telnet and file
transfer protocol (ftp).  This naming structure reflects
administrative levels of organization and/or geography on the
Internet.  The e-mail address "jsmith -at- uxa -dot- cso -dot- uiuc -dot- edu"
exemplifies a DNS-style address, and a simple analysis of this
address will help explain the system and how it relates to mail.
A good place to begin in this case, as with many e-mail addresses,
is at the "@" sign, since this delimiter typically occurs only
once in any given address.  Generally speaking, everything to the
left of the @ delimiter is referred to as the local part of the
address, usually a "mailbox" where a user reads his/her mail.  A
mailbox name often serves as a person's login name as well.  In
the example, "jsmith" is the local part, here signifying a mailbox
as well as a login name.  DNS is generally not involved in the
local part of an address.

Everything to the right of the "@" sign, on the other hand, is
referred to as the "domain" name, which is based upon DNS and
outlines where a mailbox is located.  The complete domain name,
also called the Fully Qualified Domain Name, in the example is
"uxa.cso.uiuc.edu".  It consists of a sequence of symbolic labels,
called subdomains, separated by periods.  In most Internet
addresses, as in this example, the first subdomain (in listing
from left to right) refers to an actual computer, or host, on
which the mailbox resides.  "Uxa" is the name of the host where
the mailbox for "jsmith" is found.  The next subdomain, "cso",
refers to the Computing Services Office (CSO), the local
organization which owns or runs the host uxa.  CSO categorically
falls under the next listed subdomain, "uiuc", which denotes the
University of Illinois.  The subdomain listed farthest to the
right in a complete domain name is called the top-level-domain.
In this example, "edu" is the top-level-domain signifying the
broad category of educational institutions.

It should be apparent that subdomains are listed in order from
most specific to least, with each subdomain falling "inside" the
one the the right.  The general e-mail address with DNS format is
as follows:

"localpart -at- domain", often seen as the more specific form
"user -at- host -dot- subdomain -dot- subdomain -dot- top-level-domain"

Top-level domains are the broadest category of domain names, and
in the U.S., "generic" top-level domains denote the type of
Internet site an address corresponds to: "edu"(educational
institutions), "com" (commercial), "gov" (U.S. government), and
"mil" (U.S. military), among others.  Worldwide, top-level domain
names are two letter abbreviations called "country codes" which
specify the national affiliation of an address: au (Australia),
"fr" (France), "se" (Sweden), "uk" (United Kingdom), etc.

Some popular addressing conventions resemble DNS but don't
strictly conform to the system's model.  One of these variations
is the use of "pseudo"-top-level-domain names, which indicate a
host computer's association with a wide-area, non-Internet
network.  Though accepted by many machines' mailer programs, these
names are considered invalid by the Internet's formal DNS rules.
Prominent examples of pseudo-top-level-domain names are "bitnet",
"uucp" and "hepnet".  An address with one of these pseudo-top-
level-domains will typically only have one other subdomain listed
(to the right of the @ sign), and that subdomain name will usually
specify a certain host belonging to the designated network.  Thus
the general address format would be "user -at- host -dot- pseudo-top-level-
domain" and an example of this type of address would be
"cgedney -at- uiucvmd -dot- bitnet".  A local mailer environment that is
friendly toward pseudo-top-level-domain names in an address would
have to intercept such messages and perform preliminary routing
accordingly.

Another widely used variation of DNS is related to the abridging
of the complete, or Fully Qualified Domain Names (i.e.
"user -at- host -dot- subdomain -dot- subdomain -dot- top-level-domain") if the sender
and recipient belong to the same subdomain.  For example, the most
abridged form of an address consists solely of the mailbox name,
with no "@" sign or other delimiters and subsequent domain names
involved.  This form may usually be used if the sender and
recipient mailboxes are located on the same host computer.  This
means that the remainder of their domain names would be exactly
equivalent, and mailer systems provide for this typing shortcut.
When sending e-mail anywhere outside of such a very local mailing
environment (with the exception of some users' ability to create
mail "aliases" or "nicknames"), it is strongly encouraged to use
the Fully Qualified Domain Name.


2.  Mail Gateways' Effect on Addressing
----------------------------------
Different networks have different sets of rules, or protocols, for
communication between devices.  "Gateways" are computers used
primarily to connect dissimilar networks by translating between
the protocols and allowing data traffic, such as mail, to pass
between the two systems.  Gateways may be placed between networks
on the local level, or they may be used to connect otherwise
incompatible wide-area networks.  For example, many gateways exist
at different geographical points between the Internet and BITNET
and between the Internet and UUCP-based networks like Usenet.

Gateways' role in linking networks relates to another significant
variation of e-mail addresses that incorporates DNS.  In many
cases, "intelligent" mailer software will automatically forward
messages being sent between different networks to an appropriate
gateway. This would occur in a "transparent" manner, that is,
without the user who is sending the message knowing anything about
the gateway involvement.  For example, a message sent from a
UIUCnet user on the CSO Unix machine, "uxh", to the user "doug" at
a remote BITNET site called "vmaway", would probably rely on an
address of the form "doug -at- vmaway -dot- bitnet".  The local mailer on
"uxh" would transparently rewrite the address such that the
message is sent first to UIUCnet's local BITNET/Internet gateway
(CSO's IBM mainframe "vmd"), which would in turn route the message
to the remote BITNET host vmaway.

Other times, mail must be explicitly sent through one or more
gateways, requiring the user to specifically invoke them in the e-
mail address.  These addresses appear in the general format of
"mailbox%domain0%domain1 -at- domain2" , where "domain0" refers to the
host where the mailbox is found, and "domain2" and "domain1"
represent the sequence of gateways needed to get there,
respectively.

In such an address it may be unclear as to how network machines
interpret and evaluate the names and symbols in proper order such
that the message arrives at its correct destination.  An example
would probably clarify this.  As complex as it may appear, it is
not difficult to determine the routing order of a message
addressed to "maryk%greco -dot- hepnet%dove -dot- uucp -at- blintz -dot- bio -dot- uiuc -dot- edu".
Since the singular "@" sign has highest precedence, the portion of
the e-mail address to its right would be evaluated first.  Thus,
the message would initially be routed to the the host "blintz" of
the "bio"subdomain.  "Blintz", serving as one gateway, would in
turn examine the still remaining part of the address, interpreting
the rightmost "%" sign as a secondary "@" sign.  This figuratively
produces "maryk%greco -dot- hepnet -at- dove -dot- uucp" .  The second routing
task, then, would focus on sending the message on to "dove" of the
"uucp" pseudo-domain.  "Dove", the name of another gateway, would
examine the as yet "unconsumed" address portion, where the one
remaining "%" sign would be changed into an "@" sign, resulting in
"maryk -at- greco -dot- hepnet" .  The mail would then be forwarded to the
host "greco" (of the pseudo-domain "hepnet"), home of the mailbox
"maryk".

The "@-% "form of addressing will be seen less and less as strict
DNS-based addressing becomes more universal on other networks
besides the Internet.

Of course, several other e-mail address formats are encountered
besides those derived from DNS.  These addresses will use
different syntaxes and have different punctuation marks as
delimiters between fields.  Such addresses will vary as networks
with different e-mail systems vary.  Not all types can be covered
by the scope of this user guide, but since the greatest amount of
e-mail traffic in UIUCnet flows between Internet, BITNET and UUCP-
based sites, these addressing conventions will be discussed in the
following sections.


3.  Internal Addressing Conventions
-------------------------------
BITNET, the Internet, and UUCP-based networks like Usenet each
claim their own particular addressing conventions for sending e-
mail.  Typically, there is one general way to form an address if
the e-mail destination is internal to the given network.  However,
if the sender and recipient reside on different networks,
addresses usually need to be modified such that the different
mailer programs between the networks will accept and correctly
route the messages.  In other words, there are often different
address syntaxes needed depending on where a message is going.

A brief review of the characteristics and capabilities of each of
these wide-area networks, along with a description of addressing
schemes for "internal" e-mail messages will be presented first.
Sections 4-8 discuss how those address methods will vary for
outside mail.

INTERNET
--------
The Internet refers to a large collection of national and
international networks that are based on the Transmission Control
Protocol/Internet Protocol (TCP/IP) protocol suite and which share
a common addressing scheme based on the Domain Name System (DNS).
Sites on the Internet are currently linked over long distances
with 56kbps, T1 (1.54 Mbps), or T3 (45 Mbps) lines, with links on
the local levels approaching 80Mbps or more in signalling speed.
Network services offered on the Internet include e-mail exchange,
file transfer, remote login and bulletin board news exchange (e.g.
Usenet).

The Internet internal mail addressing scheme uses the Domain Name
System (DNS), with a general address format of
"localpart -at- domain", often of the more specific form,
"user -at- host -dot- domain" where domain consists of one or more subdomains
and a top-level-domain, separated by periods. An example of an
address for internal Internet mail might be
"carolyn -at- uxh -dot- cso -dot- uiuc -dot- edu".

BITNET
------
BITNET is a national network with similar counterpart networks in
other countries, and is based on IBM's Remote Spooling
Communications Subsystem (RSCS).  The majority of BITNET sites,
called nodes, are connected by 9.6 kbps dedicated leased telephone
lines.  BITNET offers e-mail exchange, file transfer and an
interactive messaging utility.

BITNET's internal mailing scheme relies on every BITNET node
having a unique name.  Sites have "routing tables" that are based
on these names.  The tables are used for the forwarding of e-mail
messages to their correct BITNET destinations.  BITNET's internal
mail uses an uncomplicated address syntax that also relies on
these specific node names.  Depending on the mail program being
used, this internal address format will appear as something
similar to "user at node" or "user -at- node" .  For example, "cgedney
at uiucvmd" might be used.

UUCP
----
UUCP-based networks, like Usenet, are based on the Unix to Unix
Copy Program (UUCP), a transport protocol implemented with dial-up
telephone lines among primarily Unix machines.  UUCP-based
networks offer e-mail exchange and file transfer; both of these
services are used to exchange Usenet news articles among sites.

In its most basic form, internal mail of a UUCP-based network is
addressed according to the routing path from source host to
destination host.  The sender specifies an address consisting of a
sequential list of host machines through which to send the mail,
followed by the login name of the recipient.  Each item is
separated by a  "!" sign.  Thus, the general format is
"host1!host2!host3!...endhost!user " where "host1" is the source
of the message and "endhos"t is the destination host where the
recipient's mailbox ("user") is located.  "Host2", "host3",... are
the machines in between.

An example of the address of a message from a UUCP user named
sbaker to his friend jcook at another UUCP site might look
something like:  "pie!chili!pizza!jcook" .  To respond, "jcook"
would reverse the order of the named hosts in the path, as in the
address: "pizza!chili!pie!sbaker ".

This system can get complicated since a UUCP user's e-mail address
depends upon who sends him/her a message.  In practice, a few
things help ease this situation.  One is that many UUCP machines
now have intelligent mailer programs that perform most of the
routing task themselves.  For users of these machines, it often is
sufficient to provide only the name of the recipient's destination
UUCP machine, as well as his/her user name.  The sender's UUCP
machine will take care of the rest.  This address syntax would
appear something as "endhost!user ".  Some UUCP hosts support
domain-like mailers, and their users may use an internal mail
address of the form "user -at- endhost -dot- uucp" .

Alternatively, many people advertise their UUCP addresses relative
to some well-known point (host).  That leaves the sender of mail
with the task of getting the mail message to that known point;
from there, he/she just copies the address that the other person
has provided.  Such a practice is best for users at un-registered
UUCP sites, which are unknown to the rest of the UUCP network and
thus can't be reached through automatic routing methods.

4.  Using Correct Machine Names
---------------------------
Having a basic familiarity of internal address schemes for each
wide area network makes it easier to understand address methods
for sending mail between those networks.  Of course to send
someone e-mail, some sort of destination address would have to
have been supplied by the intended recipient.  If the recipient
belongs to an outside network, he/she may not know the correct
address syntax to use for sending from other networks.  That
person may just supply his/her address as used for internal mail,
which will most likely have to be modified.  While this isn't
necessarily a difficult task, in some cases many alternative
address syntaxes will have to be tried before a solution is found.

One reason for complication in e-mail addresses between networks
is related to formal host names as cited within e-mail addresses.
Often machines, or hosts, belonging to a certain wide-area network
(such as BITNET, the Internet or UUCP-based networks) have
officially registered names for identification and routing
purposes.  Some machines, especially those serving as gateways,
belong to more than one network, and their proper host names, as
used in an e-mail address, may depend on which network's
addressing convention is being invoked.  In other words, when
using the address scheme of one network, the host will be called
one name, but if using the addressing convention of a another
network (to which the same host also belongs), it may be referred
to by a different name.

For example, CSO's IBM mainframe serves as the UIUCnet local
gateway between BITNET and the Internet.  In the internal BITNET
address format, it is referred to by its designated BITNET node
name of "uiucvmd " (as in the example address "cgedney at
uiucvmd").   Since the machine is also part of the Internet,
within the Internet's DNS-based e-mail syntax, it is cited  as vmd
within its complete domain name of "vmd.cso.uiuc.edu"(for example,
"cgedney -at- vmd -dot- cso -dot- uiuc -dot- edu").  The same is true for another CSO
Unix machine which serves as the local UIUCnet gateway between the
Internet and UUCP-based connections.  In a conventional DNS-based
Internet address, this host is referred to as "uxc" within its
complete domain name of uxc.cso.uiuc.edu (for example
"jsmith -at- uxc -dot- cso -dot- uiuc -dot- edu") but in a UUCP-style e-mail address, it
is invoked in its officially registered UUCP name of "uiucuxc"
(for example, "uiucuxc!jsmith").

This aspect of differentiating between multiple names for the same
machine is especially relevant when dealing with "pseudo"-top-
level-domain names (to be referred to from here on as pseudo-
domain names) within an address.  Recall that "pseudo"-domain
names in an e-mail address indicate association with a wide-area,
non-Internet network.  Some examples of pseudo-domain names are
"uucp" and "bitnet".  Although the use of these names in an e-mail
address is accepted by many local mailer systems, they are
considered invalid on the Internet at large.  Pseudo-domains
appear to be based in DNS but don't really conform to DNS rules.
They will appear in the general form of: "user -at- host -dot- pseudo-
domain", where host is specified by its official name within the
network cited by the pseudo-domain name (as opposed to an Internet
name for that host).  For example, in the address
"cgedney -at- uiucvmd -dot- bitnet", bitnet is the pseudo-domain name, and
uiucvmd is the formal name of a node on BITNET.  As mentioned
before, within an Internet DNS-based address, that same host would
have been cited as vmd.cso.uiuc.edu.  In another example address
"doug -at- uiucuxc -dot- uucp", uucp is the pseudo-domain name and uiucuxc is
an officially registered UUCP host name.  If a mailer does accept
addresses based on pseudo-domains, it means that some preliminary
routing will have to be performed on the local level.  This
usually consists of the mailer program transparently rewriting the
address such that the message is first sent to an appropriate
gateway, which will in turn forward the message on to its
appropriate destination.


5.  Addressing Internet to BITNET mail:
---------------------------------------
If given an internal BITNET address of the typical form "user at
node", transform it to a pseudo-domain-based address of the form
"user -at- node -dot- bitnet" .  This type of address can be resolved by most
mailer programs in the UIUCnet community.  For example the address
"joe at vmusa" should be written "joe -at- vmusa -dot- bitnet" before being
sent out from an Internet host.  (In a more locally pertinent
example, mail can be sent to people on campus that use the AISS
PROFS e-mail system, which resides on a BITNET node machine named
UICVMC.  One may use an address of the form "user -at- uicvmc -dot- bitnet",
where user is the person's PROFS "id.")

If the sender's Internet host doesn't have a modern mailer program
installed, that style of address won't be accepted.  In such a
situation, the message would have to first be explicitly sent to
the nearest Internet/BITNET gateway, which could then forward it
on to the appropriate BITNET site.  This is done by making the
address of the previously explained (in Section 2) form:
"mailbox%domain1 -at- domain2 ", or more specifically,
"user%node -dot- bitnet -at- gateway -dot- domain"   where gateway.domain is DNS-
based and may consist of subdomains and a top-level-domain, and
node is the formal BITNET node (host) name.

In the UIUCnet community, that Internet/BITNET gateway is CSO's
IBM machine, vmd, so the general form would be
"user%node -dot- bitnet -at- vmd -dot- cso -dot- uiuc -dot- edu ".   In a continuation of an
example noted above, if a sender's Internet machine in the UIUCnet
community couldn't resolve the address joe -at- vmusa -dot- bitnet, the
sender should send the message to the local  gateway, vmd, though
an address as:   "joe%vmusa -dot- bitnet -at- vmd -dot- cso -dot- uiuc -dot- edu" .


6.  Addressing Internet to UUCP mail:
-------------------------------------
If given an internal UUCP-based address of the form
"host1!host2!host3!...endhost!user", this same format should be
attempted first from an Internet site (like UIUCnet) since it is
an acceptable address to many Internet mailers.  A similar,
abbreviated version appearing as "endhost!user" might also work,
although to use such a format, endhost must be an officially
registered (or "well-known") UUCP site.  If those schemes are
rejected, other options are available.  One could try an address
converted from the original UUCP-style format to a pseudo-domain-
based address of the form "user -at- endhost -dot- uucp".  Again, this format
will only work if the specified endhost is a registered UUCP site.

Explicitly sending the message to the nearest UUCP/Internet
gateway might be necessary, meaning an address of the form
"gateway!endhost!user" where "gateway" is cited by its official
UUCP name, or "user%endhost -dot- uucp -at- gateway -dot- domain", where
gateway.domain is DNS-based.  For some mailer systems, a format
appearing as "endhost!user -at- gateway -dot- domain" will also work.  For
these three formats as well, routing to endhost must be registered
and thus known to the gateway.

If mail is still rejected, it may mean the destination host
machine is an un-registered UUCP site.  In such a case, the
address must specify a UUCP-style path to the destination machine,
at least relative to a well-known (registered)  UUCP site.  In the
UUCP world, such a well-known site is uunet.  Most, if not all
UUCP sites (including UIUCnet's local Internet/UUCP gateway) can
correctly and automatically route mail with an destination address
that begins with "uunet!hosta!hostb!...user".  This also means
that if a provided return address contains many "hops," the
address can be shortened to the right-most well-known site.  For
example, an address like "turkey!gobbler!uunet!potatoe!peas!user"
could probably be shortened to "uunet!potatoe!peas!user"
 and used successfully.
This will carry over into potential addresses of the form
"user%endhost% -dot-  -dot-  -dot-  -dot- host2%host1 -dot- uucp -at- gateway -dot- domain"  or possibly
"host1!host2! -dot-  -dot-  -dot- endhost!user -at- gateway -dot- domain" where in either case
host1 is a "well-known" UUCP site like uunet, and gateway.domain
is DNS-based.


7.  Addressing BITNET to Internet mail:
--------------------------------------
A standard DNS-based Internet address (that is, the form
"user -at- host -dot- domain" where "domain" may consist of subdomains and a
top-level-domain) is also acceptable to most BITNET nodes that
have modern mailer programs.  The sender's node should be able to
recognize the Internet-style address and automatically forward the
message to the appropriate BITNET/Internet gateway.

For other BITNET nodes which have simple mailers and that may have
difficulty in getting Internet-destined mail messages routed
correctly, there exists a VM/CMS "exec" program to help facilitate
this task.  This program is available via the anonymous FTP
utility from CSO's Unix machine "uxc.cso.uiuc.edu", from
net/uiucnet/inetmail.exec .


8.  Addressing UUCP to Internet mail:
-------------------------------------
If an intelligent mailer program exists on the sender's UUCP
machine, the standard type of Internet DNS-based address
("user -at- host -dot- domain" where domain may consist of subdomains and a
top-level-domain) should work.  The sender's machine will then
transparently find an Internet/UUCP gateway to interpret the
address and route the message correctly.  For less intelligent
UUCP machines, the recipient's local UUCP/Internet gateway will
have to be explicitly mentioned as:
"host1!host2!...!gateway!host.domain!user" or perhaps an
abbreviated form like  "gateway!host.domain!user" would work,
where in both cases, gateway is cited by its official UUCP name,
and host.domain is DNS-based.

For example, if someone on a UUCP machine wants to reach someone
on UIUCnet whose internal address is "carolyn -at- uxh -dot- cso -dot- uiuc -dot- edu"
(and whose local Internet/UUCP gateway is uiucuxc), the address
should be converted to something like
"host1!host2!...!uiucuxc!uxh.cso.uiuc.edu!carolyn" ,  or perhaps
the abridged form of   "uiucuxc!uxh.cso.uiuc.edu!carolyn" would be
possible instead.


9.  Final Notes
-------------
Although lower-case letters were used to explain syntaxes and
examples in this article, in general e-mail systems are case-
insensitive.  Mixed and upper-case are usually acceptable as well.
This guide to e-mail addressing is certainly not complete but
should suffice for most cases.  Different mail systems have
varying capabilities and may not always behave according to the
norm.  If suggestions given in this article don't work, feel free
to call the CSO Systems Consultants at 333-6133 for further
assistance with e-mail addressing.



________________

Lynn Ward,  Network Design Office
University of Illinois at Urbana-Champaign
1541 DCL, 1304 West Springfield Ave., Urbana, IL 61801
(217)244-0681, ward -at- ux1 -dot- cso -dot- uiuc -dot- edu