Zines/phrack/24/3.txt

                                ==Phrack Inc.==

                      Volume Two, Issue 24, File 3 of 13

       <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
       <>                                                            <>
       <>                      Limbo To Infinity                     <>
       <>                      ~~~~~~~~~~~~~~~~~                     <>
       <>        Chapter Three of The Future Transcendent Saga       <>
       <>                                                            <>
       <>      Traversing The Barriers For Gateway Communication     <>
       <>                                                            <>
       <>                Presented by Knight Lightning               <>
       <>                      February 11, 1989                     <>
       <>                                                            <>
       <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>


Beyond Bitnet lies the other wide area networks.  We will discuss more about
those networks in chapter four.  Right now lets learn how to communicate with
those other realms.
_______________________________________________________________________________

Mailing To Other Networks - Gateway Communications
~~~~~~~~~~~~~~~~~~~~~~~~~
Bitnet, as you already know, is not the only computer network in the world.
What you might be surprised to find out, however, is that when you have access
to Bitnet you also have access to many other networks as well.  Unfortunately,
the methods for communicating with people in these other networks are not as
simple as the ones described earlier.

Bitnet's links to other networks give you access to people and services you
could not contact otherwise (or at least without great expense).  This alone
should make learning a bit about them worthwhile.

In chapter one of this series, I showed you how some Bitnet nodenames can be
broken down into state abbreviations.  To go a step further, try and think of
Bitnet as a country and the links between the Bitnet nodes as highways.
Another network (or country in this example) is connected to our highway system
at one point, which is called a "gateway."  These borders do not let
interactive messages or files through; only mail is allowed past the gateway.

The people in these other networks have addresses just like yours, but you will
need to specify something extra in order to get mail to them.  A userid@node
address is not enough, because that does not tell the Bitnet mail software what
network that node is in.  Therefore, we can extend the network address with a
code that identifies the destination network.  In this example, the destination
network is ARPAnet (a network I'm sure you have heard much about), the code for
which is ARPA.

                 TARAN@MSP-BBS.ARPA
                 +---- +------ +---
                 |     |       |
                 |     |       +-------------------- the network
                 |     |
                 |     +---------------------------- the node
                 |
                 +---------------------------------- the userid


That is about as simple as an address from another network gets.  Generally
they are much more complex.  Because of the variety of networks there can be no
example which will show you what a "typical" address might be.  However, you
should not have to let it worry you too much.  If someone tells you that his
network address is C483307@UMCVMB.MISSOURI.EDU, just use it like that with your
mail software.  As long as you understand that the mail is going to another
network and that the transit time may be longer than usual (although in many
cases I have found that mail going to EDU addresses is delivered much faster
than Bitnet mail) you should not have many problems.


More On Gateways
~~~~~~~~~~~~~~~~
I introduced the gateways in the previous section, but didn't get into too much
detail.  This is because the subject can get more than a little complex at
times.  Actually, understanding gateways isn't difficult at all, but
interpreting network addresses that use them can be.

In the previous example, an address for someone in another network looked like
this:
                 TARAN@MSP-BBS.ARPA


The ".ARPA" in the address tells your networking software that your letter
should go to someone in another network.  What you might not realize is that
your networking software "knows" that the address for the gateway to ARPA may
be at, say INTERBIT.  It might extend the address to look something like this:

                 TARAN%MSP-BBS.ARPA@INTERBIT
                 +---- +------ +--- +-------
                 |     |       |    |
                 |     |       |    +--------------- the node of the gateway
                 |     |       |
                 |     |       +-------------------- the network
                 |     |
                 |     +---------------------------- the node
                 |
                 +---------------------------------- the userid


The gateway is a server machine (userid@node) that transfers files between the
two networks.  In this case, it is ARPA@INTERBIT.  Note that the "%" replaces
the "@" from the previous example.  This is because Bitnet networking software
cannot handle addresses with more than one AT sign (@).  When your mail gets to
the gateway, the "@INTERBIT" would be stripped off, and the "%" would be turned
back into a "@".

Ok, so now you are asking, "If this is so automatic, why do you need to know
this?"  In many cases your networking software is not smart enough to know that
the gateway for SCONNET is at STLMOVM.  If this is the case, you have to type
out the whole address with all of the interesting special characters.

For example, sometimes, you may have to change the addresses around somewhat.
Let's say I'm talking to Lex Luthor one day and he tells me his address is
"lex@plover.COM".  I have found that an address like "lex@plover.COM" would
actually be mailed to as "plover!lex@RUTGERS.EDU".  Now this is just a specific
example of how it works from my particular system and other systems (not to
mention networks) will work differently (this is a guide for people using
Bitnet).  The COM (Commercial) addresses are not recognized by the mailer at
UMCVMB and so I have to route them through Rutgers University.  In chapter
four, I will discuss some of the other networks that are interconnected.

In many cases, a gateway to a network may be in another network.  In this
example, we are sending mail to RED at node KNIGHT in HDENNET.  The gateway to
the network is in, say, ARPAnet.  Our networking software is smart enough to
know where ARPA gateway is, so the address might look something like this:

                   RED%KNIGHT.HDENNET@SRI-NIC.ARPA
                   +-- +----- +------ +------ +---
                   |   |      |       |       |
                   |   |      |       |       +----- the network of the gateway
                   |   |      |       |
                   |   |      |       +------------- the node of the gateway
                   |   |      |
                   |   |      +--------------------- the network
                   |   |
                   |   +---------------------------- the node
                   |
                   +-------------------------------- the userid


As you can see, these addresses can get pretty long and difficult to type.
Perhaps the only consolation is that your address probably looks just as bad to
the people in the destination network.


Foundations Abound
~~~~~~~~~~~~~~~~~~
Just as there are servers and services in Bitnet, there are similar
counterparts in the other networks as well.  There are many electronic digests
and servers that are similar to Bitnet servers available on several of the
other networks.
_______________________________________________________________________________

Gateways To Non-Standard Networks - Intermail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Intermail is perhaps the most interesting exception to standard gateways.  It's
better to just show you what I mean rather than try to really technically
describe the process.  With Intermail, you can access networks you probably
never thought were accessible.

I have included the instructions for using the Intermail system for
transmitting computer mail between users in the MCI-Mail system, the GTE
Telemail system, the Compmail/Dialcom 164 system, and the NFS-Mail/Dialcom 157
system to the ARPA-Mail system.  The Intermail system may be used in either
direction.

Mail to be sent to MCI Mail, GTE Telemail, Compmail, or NSF-Mail is sent to the
"Intermail" mailbox on the local mail system.  The Intermail system operates by
having a program service mailboxes in both the local and the destination mail
systems.  When the right information is supplied at the beginning of a message,
the program forwards those messages into the other mail system.

In order for a message to be delivered to a mailbox in another mail system,
forwarding information must be included at the beginning of the text of each
message.  This forwarding information tells the mail forwarding program which
mail system to forward the message to, and which mailboxes to send it to.  This
information is in the form:

      Forward: <mail system>
      To: <user mailbox>
      <blank line>

The syntax allowed on the "To:" line is that of the system being forwarded
into.  In ARPA-Mail it is also possible to send to a list of CC recipients in
any of the mail gateway systems.  See the examples for further details.

In either direction, the local Subject field of the message to Intermail is
used as the Subject field of the message delivered in the other mail system.


Sending To Non-Standard Networks From Bitnet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In this direction, the Internet user must first send mail to the Intermail
mailbox on the ARPA-Internet.  The address of "Intermail" is
"INTERMAIL@ISI.EDU".  Next, the Mailbox forwarding information must be added at
the beginning of the text of each message.  The names of the mailboxes are
MCI-MAIL, TELEMAIL (for GTE Telemail), COMPMAIL, and NSF-MAIL.

This information is in the form:

      Forward: <Type name of mailbox here>
      To: <a valid address on the system you're forwarding to>
      <blank line>
      <Message...>


Please Note:  Although CompuServe (CIS), Telex, and FAX are accessible from
              MCI-Mail, the Intermail gateway does not support these services.
              However, there is a Bitnet-CompuServe gateway, but that will be
              discussed in the next section of this file.


Sending To Bitnet From Non-Standard Networks
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Supposing that you have an account on MCI-Mail, GTE Telemail, Compmail, or
NSF-Mail and you would like to mail to someone on Bitnet, you would direct
your mail to one of the following addresses;

         "INTERMAIL" (actually MCI-ID "107-8239") in MCI-Mail,
         "INTERMAIL/USCISI" in GTE Telemail,
         "164:CMP00817" in Compmail/Dialcom 164, and
         "157:NSF153" in NSF-Mail

Once you have done this, you actually type the following as the first two lines
in the mail:

     Forward: ARPA
     To: KNIGHT%MSPVMA.BITNET@CUNYVM.CUNY.EDU
     <blank line>
     <Message...>

In this example, KNIGHT is the userid and MSPVMA is the Bitnet node.
CUNYVM.CUNY.EDU is the Internet gateway to ARPAnet.  It's really just that
simple.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

In case of questions or problems using Intermail, please send a message to
Intermail-Request@ISI.EDU.
_______________________________________________________________________________

CompuServe
~~~~~~~~~~
The gateway is not yet live as of this writing.  Testing on it has been delayed
somewhat because of high-priority projects inside CompuServe.  However, it
might be a safe bet that by the time you read this that the gateway will be
complete.

The specific mechanism is that the gateway machine, 3B2/400 named Loquat,
believes that it has a UUCP neighbor "compuserve" which polls it.  In reality,
the UUCP connection is a lie all around, but the gateway starts up on an hourly
basis, pokes through the UUCP queue, finds mail aimed at CompuServe, and
creates script language on the fly suitable for a utility called Xcomm 2.2 to
call CompuServe, download any waiting mail, and upload any queued mail.

Appropriate header hacking is done so that CompuServe looks like just another
RFC-compliant entity on the Internet, and the Internet looks like yet another
gatewayed system from the perspective of the CompuServe subscriber - a very
minor modification to the usual syntax used in their mailer is needed, but
this project has provided the impetus for them to generalize the mechanism,
something they had apparently not needed before.

So that's where it stands.  Loquat speaks with machines at Ohio State.  At the
moment, there is a problem preventing mail passage except between CompuServe
and Ohio State, while they finish development and testing.  Also, part of the
header hacking done is to make CompuServe IDs look right on the Internet - the
usual 7xxxx,yyy is a problem due to the presence of the ",".
_______________________________________________________________________________

Easynet
~~~~~~~
A mail gateway between Easynet and the UUCP network and DARPA Internet
(including CSNET) is provided by the Western Research Laboratory in Palo Alto,
California.  Hopefully this service will provide improved communications
between the DEC community and the Usenet and Internet communities.


Mailing From A Bitnet Site To An Easynet Node
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To mail a message from an Internet site to an Easynet node (say MSPVAX), you
type:

To: user%mspvax.dec.com@decwrl.dec.com

A few other forms are still accepted for backward compatibility, but their use
is discouraged and they will not be described here.


Mailing From Easynet To Bitnet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For people on Easynet who would like to mail to people on Bitnet the following
information may be of interest.

The gateway supports connection to Bitnet using a pseudo-domain syntax.  These
addresses are translated by the gateway to the proper form to address the
gateway into Bitnet.  To address users in Bitnet you type:

To: DECWRL::"user@host.bitnet"

(Example:  To: DECWRL::KNIGHT@MSPVAX.BITNET)
_______________________________________________________________________________

Mailnet
~~~~~~~
The Bitnet-Mailnet Gateway no longer exists.  EDUCOM's Mailnet Service was
discontinued after June 30, 1987 in agreement with MIT.
_______________________________________________________________________________

DASnet
~~~~~~
DASnet is one of the networks that is connected to AppleLink.


Sending to DASnet from Bitnet:

1. In the "TO" field, enter the DASnet gateway address: XB.DAS@STANFORD.BITNET
2. In the "SUBJECT" field, enter the DASnet user id (such as [1234AA]joe)

Example (0756AA is the DASnet address and randy is the user on that system):

To: XB.DAS@STANFORD.BITNET
Subject: [0756AA]randy

3. If you type a "!" after the address in the subject field, you can insert
   comments, but the subject line must be limited to 29 characters.
   Example; Subject:  [0756AA]randy!Networks are cool


Sending to Bitnet from DASnet

1. In the "TO" field, enter the BITNET address followed by "@dasnet"
2. Use the "SUBJECT" field for comments.

Example:

To: knight@umcvmb.bitnet@dasnet#MSubject: Gateways

Don't be confused, there are two @s and a  at the end.
_______________________________________________________________________________

      Gateways Between Bitnet And Other Networks Not Previously Detailed
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            ______________________________________________________
           |              |                   |                   |
           | "u" = UserId | "h" = Host (Node) | "d" = Node (Host) |
           |______________|___________________|___________________|


To: CSNET Phonenet                          <u>@<h>.csnet
To: JANET (Domains: U: uk)                  <u>%<d>.U@ac.uk
To: EAN (Domains: E: cdn, dfn, etc.)        <u>@<d>.E
To: COSAC                                   <h>/<u>@france.csnet
To: Xerox Internet (Domains: R: A registry) <u>.R@xerox.com
To: DEC's Easynet <*Detailed Earlier*>      <u>%<h>.dec.com@decwrl.dec.com
To: IBM's VNET                              <u>@vnet
To: ACSNET (Domains: A: oz.au)              <u>%<d>.A@<g>
To: UUCP                                    h1!h2!<h>!<u>@psuvax1
To: JUNET (Domains: J: junet)               <u>%<d>.J@csnet-relay.csnet
To: JANET                                   <u>%U.<d>@ac.uk

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

To: BITNET

From
ARPA Internet           <u>%<h>.bitnet@cunyvm.cuny.edu
CSNET Phonenet          <u>%<h>.bitnet@relay.cs.net
JANET                   <u>%<h>@uk.ac.rl.earn
EAN                     <u>@<h>.bitnet
COSAC                   adi/<u>%<h>.bitnet@relay.cs.net
ACSNET                  <u>%<h>.bitnet@munnari.oz
UUCP                    psuvax1!<h>.bitnet!<u>
JUNET                   <u>@<h>.bitnet
_______________________________________________________________________________


Conclusion
~~~~~~~~~~
Now that you understand how to mail to the other networks by making use of the
gateways, we will begin looking at the other networks themselves.  As my
greatest area of expertise is Bitnet, I will cover the other networks in less
detail.  If they interest you, I'm sure you will find a way to learn more about
them.  So read Chapter Four of The Future Transcendent Saga -- Frontiers.

:Knight Lightning
_______________________________________________________________________________