home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / phrk2 / phrack23.5 < prev    next >
Text File  |  1992-09-26  |  27KB  |  496 lines

  1.  
  2.  
  3.                                ==Phrack Inc.==
  4.  
  5.                       Volume Two, Issue 23, File 5 of 12
  6.  
  7.        <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
  8.        <>                                                            <>
  9.        <>                Foundations Upon The Horizon                <>
  10.        <>                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~                <>
  11.        <>         Chapter Two of The Future Transcendent Saga        <>
  12.        <>                                                            <>
  13.        <>      Using Servers And Services In The World Of Bitnet     <>
  14.        <>                                                            <>
  15.        <>                Presented by Knight Lightning               <>
  16.        <>                       January 2, 1989                      <>
  17.        <>                                                            <>
  18.        <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
  19.  
  20.  
  21. Welcome to the second chapter of The Future Transcendent Saga.  In this file,
  22. I will present the servers and services of Bitnet (although there are some
  23. services and servers on other networks as well).  You will learn what the
  24. servers are, how they differentiate, how to use them, and come to a better
  25. understanding of how these Foundations Upon The Horizon help make Bitnet a
  26. virtual Utopia.
  27. _______________________________________________________________________________
  28.  
  29. What Is A Server?
  30. ~~~~~~~~~~~~~~~~~
  31. One of most useful features of Bitnet is the variety of file servers, name
  32. servers, relays, and so on.  They might be described as "virtual machines" or
  33. "server machines."
  34.  
  35. A "server" is a userid a lot like yours.  It may exist on your computer (node)
  36. or on some other BITNET node.  The people who set up this userid have it
  37. running a program that will respond to your commands.  This is a "server."  The
  38. commands you send and the way in which the server responds to them depends on
  39. the particular program being run.  For example, the servers UMNEWS@MAINE and
  40. 107633@DOLUNI1 offer different types of services, and require different
  41. commands.  The various kinds of servers are described later in this document.
  42.  
  43. You can send your commands to most servers in one of two formats:   MAIL or
  44.                                                                     MESSAGE.
  45.  
  46. Not all servers accept commands via both formats, but this information is
  47. included in the document BITNET SERVERS which can be obtained from
  48. LISTSERV@BITNIC.  Because there are so many servers I will not even begin to
  49. list them here.  Different servers are created and disconnected everyday so it
  50. would be difficult to name them all.
  51.  
  52. People on VM/CMS systems would send commands something like this:
  53.  
  54.      TELL userid AT node command   (AT = @)
  55.  
  56. For example:
  57.  
  58.      TELL NETSERV@MARIST HELP
  59.  
  60. People on VAX/VMS systems using the JNET networking software would use this
  61. syntax:
  62.  
  63.      SEND userid@node "command"
  64.  
  65. For example:
  66.  
  67.      SEND NETSERV@MARIST "HELP"
  68.  
  69. Many servers can also accept commands via mail.  Indeed, some will only accept
  70. your commands in that format, such as the servers on the non-Bitnet nodes.  The
  71. syntax for the commands you send remain the same.  You send mail to the server
  72. as if you were sending the mail to a person.  The text of your message would be
  73. the command.  Some servers will take the command as the first line of a text
  74. message, others require it in the "Subject:" line.  Some servers will accept
  75. more than one command in a mail message, others will take only one.   Here is
  76. an example of a mail message sent to LISTSERV@BITNIC requesting a list of
  77. files:
  78.  
  79.  
  80.      Date:         Fri, 30 Dec 88 23:52:00 EDT
  81.      From:         Taran King <SYSOP@MSPVMA>
  82.      To:           Listserv <LISTSERV@BITNIC>
  83.      ========================================================================
  84.      INDEX
  85.  
  86.  
  87. Throughout this file I will use examples where commands are sent to servers via
  88. message.   However, for many of the cases we will present you have option of
  89. using mail.  The choice is yours.
  90.  
  91. There are two particularly confusing aspects of servers of which you should be
  92. aware.  First, servers in the same category (say, file servers) do not always
  93. accept the same commands.  Many of them are extremely different.  Others are
  94. just different enough to be annoying.  There are many approaches to setting up
  95. a server, and everyone is trying to build a better one.
  96.  
  97. The second problem is that there are many servers that fill two, sometimes
  98. three categories of server.  For example, LISTSERV works as a list server and a
  99. file server.  Many LISTSERVs have been modified to act as name servers as well,
  100. but they are rather inefficient in this capacity.  If you do not understand
  101. this terminology, bear with me.  The best is yet to come.
  102.  
  103.  
  104. File Servers
  105. ~~~~~~~~~~~~
  106. Remember that a server runs on a userid much like yours.  Like your userid, it
  107. has many capabilities, including the ability to store files (probably with a
  108. much greater storage capacity though).  The program that a file server runs
  109. enables it to send you files from its directory, as well as a list of files
  110. available.  These may be programs or text files.  You might look at these
  111. servers as Bitnet versions of dial-up bulletin boards or AE Lines.
  112.  
  113. You can generally send three types of commands to a file server.  The first
  114. type is a request for a list of files the server offers.  The second is a
  115. request that a specific file be sent to your userid.  The third, and most
  116. important is a HELP command.
  117.  
  118. The HELP command is very important because it is one of the few commands that
  119. almost all servers accept, no matter what the type.  Because the commands
  120. available differ from server to server, you will often find this indispensable.
  121. Sending HELP to a server will usually result in a message or file sent to your
  122. userid listing the various commands and their syntax.  You should keep some
  123. of this information handy until you are comfortable with a particular server.
  124.  
  125. To request a list of files from a server, you will usually send it a command
  126. like INDEX or DIR.  The list of files will be sent to you via mail or in a
  127. file.  For example:
  128.  
  129.      VM/CMS:      TELL LISTSERV@BITNIC INDEX
  130.      VMS/JNET:    SEND LISTSERV@BITNIC "INDEX"
  131.  
  132. To request a specific file from the list you receive, you would use a command
  133. like GET or SENDME.  For example to request the file BITNET TOPOLOGY from
  134. LISTSERV@BITNIC you would type on of the following:
  135.  
  136.      VM/CMS:      TELL LISTSERV@BITNIC SENDME BITNET TOPOLOGY
  137.      VMS/JNET:    SEND LISTSERV@BITNIC "SENDME BITNET TOPOLOGY"
  138.  
  139. In many cases the files are organized into subdirectories or filelists.  This
  140. can make requesting a file more complicated.  This makes it even more essential
  141. that you keep documentation about a particular server handy.  Some file servers
  142. offer programs that you can run which will send commands to the server for you.
  143.  
  144.  
  145. Name Servers
  146. ~~~~~~~~~~~~
  147. Name servers serve two purposes; to assist you in finding an address for
  148. someone or to help you find people with specific interests.  I doubt you are
  149. going to care about tracking down people by their interests, so I am not going
  150. to discuss those aspects of nameservers.  The servers that acutally let you
  151. look up people are few and far between.  Because there are so few I have
  152. composed this list;
  153.  
  154. Columbia University                            FINGER   @ CUVMA
  155. Cork University                                INFO     @ IRUCCIBM
  156. Drew University                                NAMESERV @ DREW
  157. North Dakota State University                  FINGER   @ NDSUVM1
  158. Ohio State University                          WHOIS    @ OHSTVMA
  159. Pennsylvania State University                  IDSERVER @ PSUVM
  160. Rochester Institute Of Technology              INFO     @ RITVAXD
  161.                                                LOOKUP   @ RITVM
  162. State University of New York (SUNY) at Albany  WHOIS    @ ALBNYVM1
  163. University of Calgary                          NAMESERV @ UNCAMULT
  164. University of Kentucky                         WHOIS    @ UKCC
  165. University of Illinois at Urbana-Champagne     PHSERVE  @ UIUCVMD
  166. University of Louisville (Kentucky)            WHOIS    @ ULKYVM
  167. University of Regina                           VMNAMES  @ UREGINA1
  168. University of Tennessee                        UTSERVER @ UTKVM1
  169. Weizmann Institute of Science                  VMNAMES  @ WEIZMANN
  170.  
  171. So as not to be misleading, these servers do not neccesarily cover the entire
  172. school.  Example:  The server at University of Louisville covers people on the
  173. node ULKYVM, but not the nodes ULKYVX0x (x = 1 - 8 I believe).  ULKYVX is a
  174. VAXcluster of nodes at University of Louisville, but the people on those
  175. systems are NOT indexed on the server at ULKYVM.  In contrast, the nameserver
  176. at University of Illinois contains online listings for every student and staff
  177. member whether they have accounts on the computer or not.  You can get phone
  178. numbers and addresses using this.  Please note that the above list is only to
  179. the best of my knowledge and others may exist.
  180.  
  181. There are also many Listservs that have a command to search for people, but
  182. with Listserv, signing up is by choice and not mandatory.  You also will end up
  183. getting listings for people from nodes other than the one you are searching.
  184.  
  185. Ok, lets say I am trying to find an account for Oryan QUEST and I am told by a
  186. friend that he is going to school at Ohio State University.  Ohio State
  187. University has a nameserver and if he has an account on their computer I should
  188. be able to find him.
  189.  
  190.      VM/CMS:      TELL WHOIS@OHSTVMA Quest
  191.      VMS/JNET:    SEND WHOIS@OHSTVMA "Quest"
  192.  
  193. This particular nameserver only requires that you enter the persons name with
  194. no "search" command.  Some servers require this.  Your best bet is to send the
  195. command "HELP" first and you'll receive documentation.
  196.  
  197. Ok, back to the example... unfortunately, there is no entry for "Quest" and I
  198. am out of luck.  I should have been smart enough to realize that no college
  199. would be likely to let Oryan QUEST enroll in the first place -- my mistake.
  200.  
  201. In any case, I highly recommend that you register yourself with UMNEWS@MAINE
  202. and BITSERVE@CUNYVM.  These are popular nationwide servers that are often used
  203. to locate people.
  204.  
  205.  
  206. Forums, Digests, and Electronic Magazines
  207. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  208. The concept of mailing lists has been given new life with the creation of
  209. computer networks.  Let me explain what I mean.  Almost everyone is on some
  210. sort of mailing list; magazines, bills, or even pamplets from your congressman.
  211. The computer networks have brought a whole new degree of speed and
  212. functionality to mailing lists, as you will see.
  213.  
  214. In Bitnet, mailing lists are used mainly to keep people with similar interests
  215. in contact.  There are several formats in which this contact can take place.
  216. These are "forums," "digests," and "electronic magazines".
  217.  
  218. FORUMS are a good example of how the utility of mailing lists has been expanded
  219. in Bitnet.  Let's say that you have subscribed to a forum for people interested
  220. in Cyberpunks.  How you could subscribe to such a list will be described later.
  221. Another person on the mailing list sends mail to a server where the list is
  222. kept.  This server forwards the mail to all of the people in the forum.  When
  223. mail from a forum arrives in your computer mailbox, the header will look much
  224. like this:
  225.  
  226.      Date:         Fri, 10 Sep 88 23:52:00 EDT
  227.      Reply-To:     CYBER Discussion List <CYBER-L@PUNKVM>
  228.      Sender:       CYBER Discussion List <CYBER-L@PUNKVM>
  229.      From:         Sir Francis Drake <DRAKE@WORMVM>
  230.      Subject:      Invasion From X-Neon!
  231.      To:           Solid State <SEKER@PLPVMA>
  232.      ========================================================================
  233.  
  234. This may look a little confusing, but there really isn't much to it.  In this
  235. example, Sir Francis Drake ("From:") sent mail to the CYBER-L list address.
  236. This server then forwarded the mail to everybody on the list, including Solid
  237. State ("To:").  Note the line named "Reply-To:".  This line tells your mail
  238. software that when you reply to the note (if you reply) that the reply should
  239. go to the list... meaning *everybody* on the list.  People will in turn reply
  240. to your mail, and you have a forum.
  241.  
  242. Some forums are very interesting, but using the digests can lead to problems.
  243. First among these is the volume of mail you can receive.  If you are in a very
  244. active forum, you can get 50 or more pieces of electronic mail in a single day.
  245. If you are discussing a controversial or emotional topic, expect more.
  246.  
  247. Many people have a tendency to "flame" (the Bitnet term for ragging).  The
  248. speed and immediacy of electronic mail makes it very easy to whip out a quick,
  249. emotional response, to which there will be similar replies.  I advise you to
  250. take some time and think out your responses to forum postings before
  251. inadvertently starting a "flame war."  Hopefully anyone able to gain access to
  252. college computers will be mature enough to have outgrown these battles.
  253.  
  254. DIGESTS provide a partial solution to the these problems.  In this case, mail
  255. that is sent to a mailing list is stored rather than sent out immediately.  At
  256. some point the "Moderator" for the list organizes and condenses all of the
  257. correspondence for the day or week.  He then sends this out to the people on
  258. the mailing list in one mailing.
  259.  
  260. The drawback with this setup is that it requires a lot of human intervention.
  261. If the moderator gets sick, goes on vacation, or quits, activity for a
  262. particular digest can come to a screeching halt.
  263.  
  264. ELECTRONIC MAGAZINES take the digest concept a step further.  These mailing
  265. lists actually duplicate the organization and format of "real" magazines.
  266. Bitnet is used as a convenient and inexpensive distribution method for the
  267. information they contain.  The frequency of distribution for these electronic
  268. magazines ranges ranges from weekly to quarterly to "whenever the editor feels
  269. like it" (sort of like Phrack releases).  This is the most formal, structured
  270. form of Bitnet communication.  Where a digest is simply a group of letters
  271. organized by topic, an electronic magazine includes articles, columns, and
  272. features.  Perhaps the only feature of paper magazines that they do *not*
  273. include is advertisements.  Bitnet NetMonth and NetWeek are two of the better
  274. magazines on Bitnet and they contain useful information if you know what you're
  275. looking for.  I will discuss how to subscribe to these magazines as well as the
  276. other forms of media in the next part of this file.
  277.  
  278.  
  279. List Servers
  280. ~~~~~~~~~~~~
  281. In the previous section, I mentioned that some servers are used to control
  282. mailing lists.  A server that performs this function is called a "list server."
  283. Almost all of these listservers have the userid of LISTSERV, such as
  284. LISTSERV@BITNIC.  One of these servers can control subscriptions to many
  285. mailing lists.  The other concept behind Listservs are the list-ids, but as
  286. these are rather unimportant and vary from server to server I am not going to
  287. discuss them here.  If you would like to learn about these, consult your local
  288. listserv and request documentation with the HELP command.
  289.  
  290. To subscribe to a mailing list, you would send a LISTSERV a SUBSCRIBE command,
  291. which has the following syntax:
  292.  
  293.      SUBscribe listname (whatever name you want)
  294.  
  295. In this example, SpyroGrya is sending LISTSERV@BITNIC the command to
  296. subscribe to ETHICS-L:
  297.  
  298.      VM/CMS:      TELL LISTSERV@BITNIC SUB ETHICS-L SpyroGyra
  299.      VMS/JNET:    SEND LISTSERV@BITNIC "SUB ETHICS-L SpyroGyra"
  300.  
  301. If you misspell your name when entering a SUBscribe command, simply resend it
  302. with the correct spelling.  To delete his name from the mailing list,
  303. SpyroGyra would enter an UNSUBscribe command:
  304.  
  305.      VM/CMS:      TELL LISTSERV@BITNIC UNSUB ETHICS-L
  306.      VMS/JNET:    SEND LISTSERV@BITNIC "UNSUB ETHICS-L"
  307.  
  308. In many cases the SIGNOFF command is used instead of UNSUB, but those are the
  309. basic commands you need to know in order to access Listserv controlled mailing
  310. lists.  However, Listserv has a multitude of features, so it would be a good
  311. idea to read the Listserv documentation.
  312.  
  313. *Note*  If you are on a VAXcluster, you should send SUBSCRIBE and UNSUBSCRIBE
  314. commands to LISTSERV via MAIL.
  315.  
  316.  
  317. Relays
  318. ~~~~~~
  319. Relay might be one of the easier types of servers to understand.  If you have
  320. used the CB Simulator on CompuServe or are familiar with Diversi-Dials (or
  321. maybe even ALTOS Chat) you will catch on to the concept quickly.  The idea
  322. behind Relay is to allow more than two people to have conversations by
  323. interactive message.  Without Relay-type servers, this would not be possible.
  324.  
  325. Let's set up a scenario:
  326.  
  327. Sluggo, Taran, and Mentor are at different nodes.  Any two of them can have
  328. a conversation through Bitnet.  If the three of them want to talk, however,
  329. they have a problem.  Sluggo can send Mentor messages, but Taran can't see
  330. them.  Likewise, Taran can send Sluggo messages, but then Mentor is in the
  331. dark.  What they need is a form of teleconferencing.  Alliance doesn't exist on
  332. Bitnet so they created Relays.
  333.  
  334. Each of these users "signs on" to a nearby Relay.  They can pick a channel
  335. (0-999 although there are more, but they are reserved for special use).
  336. Instead of sending messages to Taran or Sluggo, Mentor sends his commands to
  337. the Relay.  The Relay system then sends his message to *both* Taran and Sluggo.
  338. The other users can do the same.  When they are done talking, they "sign off."
  339.  
  340. Relays can distinguish commands from the text of your messages because commands
  341. are prefixed with a slash "/".  For example, a HELP command would look like
  342. this:
  343.  
  344.      VM/CMS:      TELL RELAY@UIUCVMD /HELP
  345.      VMS/JNET:    SEND RELAY@UIUCVMD "/HELP"
  346.  
  347. A message that is part of a conversation would be sent like so:
  348.  
  349.      VM/CMS:      TELL RELAY@UIUCVMD Hello there!
  350.      VMS/JNET:    SEND RELAY@UIUCVMD "Hello there!"
  351.  
  352. When you first start using Relay, you must register yourself as a Relay user
  353. using the /SIGNUP or /REGISTER commands:
  354.  
  355.      VM/CMS:      TELL RELAY@UIUCVMD /REGISTER (Choose a name)
  356.      VMS/JNET:    SEND RELAY@UIUCVMD "/REGISTER (Choose a name)"
  357.  
  358. They want you to use your real name, do so if you want, but they really have no
  359. way to check unless one of the operators is a user consultant at your node and
  360. looks up your account.  Just use names that look real and you'll be fine.
  361.  
  362. You can then sign on.  You can use a nickname or handle.  In the following
  363. example, I am signing on to Channel 260 with a nickname of "KLightning":
  364.  
  365.      VM/CMS:      TELL RELAY@UIUCVMD /SIGNON KLightning 260
  366.      VMS/JNET:    SEND RELAY@UIUCVMD "/SIGNON KLightning 260"
  367.  
  368. You can then start sending the Relay the text of your messages:
  369.  
  370.      VM/CMS:      TELL RELAY@UIUCVMD Good evening.
  371.      VMS/JNET:    SEND RELAY@UIUCVMD "Good evening."
  372.  
  373. Relay messages will appear on your screen like this.  Note the nickname near
  374. the beginning of the message.  When you send conversational messages to the
  375. Relay, it automatically prefixes them with your nickname when it forwards it to
  376. the other users:
  377.  
  378.      FROM UIUCVMD(RELAY): <Taran_King> Hello KLightning.
  379.  
  380. You can find out who is on your channel with a /WHO command.  In the following
  381. example, someone is listing the users on Channel 260.
  382.  
  383.      VM/CMS:      TELL RELAY@UIUCVMD /WHO 260
  384.      VMS/JNET:    SEND RELAY@UIUCVMD "/WHO 260"
  385.  
  386. The response from the Relay would look like this:
  387.  
  388.      FROM UIUCVMD(RELAY): Ch    UserID @ Node     Nickname
  389.      FROM UIUCVMD(RELAY): 260   C483307@UMCVMB   (KLightning)
  390.      FROM UIUCVMD(RELAY): 260    MENTOR@PHOENIX  (The_-e,]KWRP     FROM UIUCVMD(RELAY): 260   C488869@UMCVMB   (Taran_King)
  391.      FROM UIUCVMD(RELAY): 260   PROPHET@PHOENIX  (  Prophet )
  392.      FROM UIUCVMD(RELAY): 260     DRAKE@WORMVM   (   Sfd    )
  393.      FROM UIUCVMD(RELAY): 260    JESTER@NDSUVM1  (  Sluggo  )
  394.      FROM UIUCVMD(RELAY): 260       TUC@RACS3VM  (   Tuc    )
  395.      FROM UIUCVMD(RELAY): 260     VINNY@LODHVMA  (Lex_Luthor)
  396.  
  397. When you are done with your conversation, you can sign off the Relay:
  398.  
  399.      VM/CMS:      TELL RELAY@UIUCVMD /SIGNOFF or /BYE
  400.      VMS/JNET:    SEND RELAY@UIUCVMD "/SIGNOFF" or "/BYE"
  401.  
  402. There are several commands for listing active channels, sending private
  403. messages, and so on.  When you first register as a Relay user, you will be sent
  404. documentation.  You can also get this information with the /INFO command.  To
  405. determine which Relay serves your area, send any of the Relays listed in
  406. BITNET SERVERS the /SERVERS command.  Also, because of Bitnet message and file
  407. traffic limits, many Relays are only available during the evening and weekends.
  408.  
  409. To help illustrate how the Relays work I have included this map;
  410.                    [United States of America locations only]
  411.  
  412.                                                       ----------------------
  413.                                 Non-USA Relays        | RELAY  @  CLVM     |
  414.                                      ^                | (TwiliteZne)       |
  415.                                     /|\               | Potsdam N.Y.       |
  416.                                      |                ----------------------
  417.                                      |                          |
  418. ----------------------     ----------------------     ----------------------
  419. | RELAY  @ VILLVM    |     | RELAY  @ ORION     |     | RELAY  @ YALEVM    |
  420. | (Philadelph)       |-----| (New_Jersey)       |-----| (Yale)             |
  421. | Villanova  PA.     |     |  New Jersey        |     | New Haven CT.      |
  422. ----------------------     ----------------------\    ----------------------
  423.                                      |       |    \
  424. ----------------------               |        \    \  ----------------------
  425. | RELAY  @NDSUVM1    |               |         \    \ | RELAY  @NYUCCVM    |
  426. | (No_Dakota )       |\              |          \    \| (   Nyu    )       |
  427. | North Dakota       | \             |           \    | New York           |
  428. ----------------------  \            |            \   ----------------------
  429.                          \           |             \
  430. ----------------------    \----------------------  |  ----------------------
  431. | RELAY  @JPNSUT10   |     | RELAY  @ BITNIC    |  |  | CXBOB  @ASUACAD    |
  432. | (  Tokyo   )       |-----| ( NewYork  )       |  |  | (Tempe_Ariz)       |
  433. | Japan              |     | New York-Singapore |  |  | Arizona            |
  434. ----------------------     ----------------------  |  ----------------------
  435.                                               |    |            |
  436. ----------------------                         \   |  ----------------------
  437. | MASRELAY@  UBVM    |                          \  |  | RELAY  @ USCVM     |
  438. | ( Buffalo  )       |\                          --+--| (LosAngeles)       |
  439. | New York (N)       | \                          /   | California         |
  440. ----------------------  \                        /    ----------------------
  441.                          \                      /               |
  442. ----------------------    \                    /      ----------------------
  443. | RELAY  @ WATDCS    |     \                  /       | RELAY  @ UWAVM     |
  444. | ( Waterloo )       |      \                /        | ( Seattle )        |
  445. | Ontario/E. Canada  |       |              /         | Washington         |
  446. ----------------------       |             /          ----------------------
  447.          |                   |             |                    |
  448. ----------------------     ----------------------     ----------------------
  449. | RELAY  @CANADA01   |     | RLY   @CORNELLC    |     | 556   @OREGON1     |
  450. | ( Canada01 )       |-----| (Ithaca_NY )       |     | ( Oregon )         |
  451. | Ontario (Guelph)   |     | New York           |     | Oregon             |
  452. ----------------------     ----------------------\    ----------------------
  453.          |                          |             \
  454. ----------------------              |              \  ----------------------
  455. | RELAY  @UREGINA1   |              |               \ | RELAY  @ VTVM2     |
  456. | ( Regina_Sk )      |              |                \| ( Va_Tech  )       |
  457. | Saskatoon/Manitoba |              |                 | Virginia           |
  458. ----------------------              |                 ----------------------
  459.          |                          |                           |
  460. ----------------------              |                 ----------------------
  461. | RELAY  @UALTAVM    |              |                 | RELAY  @  UWF      |
  462. | ( Edmonton )       |              |                 | (Pensacola )       |
  463. | Alberta/B.C.       |              |                 | Florida            |
  464. ----------------------              |                 ----------------------
  465.                                     |
  466. ----------------------     ----------------------     ----------------------
  467. | RELAY  @PURCCVM    |     | RELAY  @CMUCCVMA   |     | RELAY  @ UTCVM     |
  468. | (  Purdue  )       |-----| (Pittsburgh)       |-----| (Tennessee )       |
  469. | Lafayette IN.      |     | Pensylvania        |     | Tennessee          |
  470. ----------------------     ----------------------     ----------------------
  471.                                     |                          |
  472. ----------------------              |                 ----------------------
  473. | RELAY  @TECMTYVM   |              |                 | RELAY  @ GITVM1    |
  474. | (Monterrey )       |              |                 | ( Atlanta  )       |
  475. | Mexico             |              |                 | Georgia            |
  476. ----------------------              |                 ----------------------
  477.         |                           |
  478. ----------------------     ----------------------     ----------------------
  479. | RELAY  @ TAMVM1    |     | RELAY  @UIUCVMD    |     | RELAY  @ TCSVM     |
  480. | (Aggieland )       |-----| (Urbana_IL )       |-----| ( Tulane )         |
  481. | Texas              |     | Illinois           |     | New Orleans LA.    |
  482. ----------------------     ----------------------     ----------------------
  483.  
  484.  
  485. Conclusion
  486. ~~~~~~~~~~
  487. So what lies beyond the boundaries of Bitnet?  There are many other networks
  488. that are similar to Bitnet both in function and in services.  How to mail to
  489. these networks will be discussed in the next chapter of The Future Transcendent
  490. Saga -- Limbo To Infinity.
  491.  
  492. :Knight Lightning
  493. _______________________________________________________________________________
  494.  
  495. Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
  496.