Otherware/Otherware_1_SB_Development.iso/mac/misc/document/mactcp.txt

Internet Message Format | 1992-11-05 | 47.6 KB

From: "Eric Behr" <[e-mail]>
Subject: New version of /report/mac-tcp-info.txt
Date: Wed, 8 Jul 92 19:29:43 CDT

Moderator: please replace the file /info-mac/report/mac-tcp-info.txt
with the new version enclosed below. Thank you.    Eric
------


MacTCP and related Macintosh software
=====================================
revision 1.0, July 10, 1992

----------------------------------------------------------------
Copyright Eric Behr, Illinois State University, Mathematics
Department

This document can be freely redistributed in whole or in part,
provided that this copyright notice is included intact, and that
no material profit is generated from such a transaction.
----------------------------------------------------------------


With sincere thanks to:
  David N. Blank-Edelman        [e-mail]
  Steve Dorner                  [e-mail]
  Patrick Hoepfner              [e-mail]
  Peter N. Lewis                [e-mail]
  David S. Saunders             [e-mail]
as well as to several contributors to Usenet newsgroups
(but I'm the sole author of all mistakes, omissions and inanities)

Please send all comments and suggestions to [e-mail] or
to [e-mail]. The newest version of these notes
can be obtained by anonymous ftp to spider.math.ilstu.edu (file
/pub/mac/mac-tcp.txt).

CONTENTS

            PREFACE
         I. General stuff
        II. MacTCP
       III. Applications
        IV. Sources
Appendix A. Peculiarities of Mac file transfers
Appendix B. Dial-in access

PREFACE

Judging by questions and complaints, more and more people are
playing with MacTCP and communications software which uses it;
many of them are having problems with MacTCP.

I've spent many hours installing MacTCP on Macs ranging from the
Plus to a IIci. I also devoted a large part of my free time to
digging up various useful applications for use on the Internet.
Hopefully some of my experiences will be useful to you.

Please note that I'm not a networking expert. Some of the advice
below simply stems from my paranoia and is not necessarily based
on facts. There are many problems with MacTCP which I don't fully
understand, like reported snags with built-in Ethernet on the
Quadras. In addition, please remember that I'm not a technical
writer, and my style may not be to your liking - sorry about that.


I. General stuff

1. Let's begin with a short sermon

   I started using the Internet several years ago, and it has
become an important part of my life - for better or worse. I know
that many people share my feelings about it. For the sake of all
of us, please be considerate! There are lots of things you can
mess up if you don't know what you are doing. Connecting your
computer to the network which spans continents and is used by
millions of people in their work is (or at least should be) a
serious act.

   Please follow this simple advice:

o  when in doubt, don't do anything without consulting manuals
   and/or a knowledgeable system administrator;

o  find out how to access the Internet documents (esp. RFC's) and
   read the relevant ones before doing anything tricky;

o  read newsgroups such as comp.sys.mac.comm, comp.sys.mac.system,
   comp.sys.protocols.tcp-ip, comp.protocols.appletalk;

o  read the flaming manuals! and FAQ lists, too!


2. Where does the Mac fit in?

   The Mac has always been a wonderful network machine. But for
most people "Macintosh networking" means Apple's proprietary
scheme called AppleTalk. The Internet uses a different networking
"language". A major part of it is the protocol known by its
acronym TCP/IP. To access the wonders of the Internet, a computer
must understand TCP/IP.

Even though there are other ways to make the Mac speak TCP/IP, we
will concentrate on the most popular and orthodox one, namely the
"MacTCP driver" from Apple.


3. Various connection methods

   The necessary software is only one part of a network
connection. The other, obviously, is suitable hardware. A
Macintosh can be connected to the outside world in many ways:

o  with a LocalTalk or PhoneNet connector to a LocalTalk network
o  with a modem and suitable software (see Appendix B)
o  with an internal Ethernet card
o  with an external SCSI Ethernet adapter
o  with an internal TokenRing card

Until very recently MacTCP was not compatible with the last method
of connection listed above. In mid-1992 Apple announced MacTCP
1.2, which should do the trick. We haven't had the chance to play
with this setup yet, and udoubtedly this newest version will bring
us a whole new collection of problems, but it is safe to say that
most of the advice below should apply to Macs on Token Ring as
well.

The problem of providing reliable and convenient dial-in access
would require a separate book. A very superficial note on this
subject is found in Appendix B.

Macs on Ethernet can usually connect to the outside TCP/IP world
without a problem, since that protocol was in some sense created
for Ethernet.

Macs on LocalTalk can communicate with the outside TCP/IP world
only if the LocalTalk is connected to a larger network using an IP
gateway such as FastPath (Shiva), Gatorbox (Cayman Systems),
Multiport Gateway (Webster Computer Corp.), EtherRoute/TCP
(Compatible Systems), or one of other equivalent devices; or if
such a gateway is present elsewhere on your internet, and is
visible to your Mac. To our knowledge, none of the software
routers like the Apple Internet Router or Liaison (Inphosphere)
currently provides TCP/IP services, so if that's what you use to
connect to an Ethernet, you must also have a gateway which will
translate the IP packets wrapped in AppleTalk (which your
LocalTalk Mac sends) into genuine IP packets going to the outside
world, and vice versa.

Please note that AppleTalk and TCP/IP are two completely different
animals, even though a single Mac can use both at the same time;
configuring AppleTalk functions, such as printing over the network
or AppleShare, will not be discussed here.


II. MacTCP


1. How to get it?

   MacTCP (version 1.1 at the moment, soon to be superseded) is
sold by APDA (408 974 4667). Don't expect your local Apple dealer
to know much about it. Current price of a single copy is about
$100. A site license is available, and some institutions may
qualify for discounts. Call APDA. If you already have an old
version, you should have no problems upgrading to the current one.

Some public domain TCP/IP applications come bundled with MacTCP.
This is somewhat paradoxical, but completely legal. The developer
has paid Apple a rather stiff fee for a "distribution license".
Technically speaking, you are allowed to use this copy only with
the application it came with. Even though such a restriction seems
a tad ridiculous, it is simply illegal to use a copy of MacTCP
obtained in this fashion with *any* other application. Another
catch is that you do not get manuals or upgrades this way, and
configuring that beast - as you will see below - may be tricky.


2. What is it?

   For the user, it is a Control Panel, configured just as the
Monitors or Sound CP. For applications, it is a set of procedures
which allows them to communicate with other hosts on the network
using the TCP/IP protocol. It is designed to be transparent in the
sense that once it is properly configured, any correctly written
application can make use of it without user intervention. True
enough, life without MacTCP would be hell! In practice however,
both MacTCP and the applications which use it have bugs and
idiosyncrasies which make this software difficult to handle. In my
experience, the Mac SE is the most unstable MacTCP platform,
probably because of the peculiarities of its ROMs; but I admit
that it is a statistical observation, with no theory at all to
back it up.

Apple, in all its charming inconsistency, tells us to use their
Installer even when adding a silly little printer driver, but at
the same time does not provide an Installer script for the rather
intricate procedure of installing and configuring MacTCP.

Here's the way I've successfully done it on many machines. These
are purely empirical findings, so treat these procedures more like
a rain dance than a rational troubleshooting guide.


3. Let's do it!

   If you are installing MacTCP for the first time, or if you
suddenly run into problems such as the dreaded message "Error
opening TCP drivers - possibly no dynamic addressing", you should
follow these steps for maximum effect.

My general advice is: start with virginal (or at least freshly
updated) system files. Problems may result from improperly
installed old version of AppleTalk or other resources. For
example, I could never painlessly install new Ethernet drivers on
any Mac which previously had drivers for the Nuvolink SC box
installed in it (I don't mean to put down Nuvotech's products -
they generally work fine for me). What's worse, some network
applications seem to corrupt the System, and/or other important
files, when they crash. So here we go:

o  This is almost certainly an overkill, but in some cases it is
also a recipe for instant happiness. If you are having major
problems, boot from a system floppy, and trash the following from
the hard disk: System, Finder, Multifinder, MacTCP, AdminTCP,
MacTCP Prep, MacTCP DNR, all network drivers and control panels
(AppleTalk, EtherTalk, Network). These gadgets are found in the
System Folder proper (in pre-7 Systems) or in various subfolders,
such as Control Panels, Preferences and Extensions. Of course,
you'd better first back up all the files which seem important to
you, such as non-standard Extensions or fonts, which will get
erased in the process! Then install a fresh system.

o  Disable all INITs, and non-essential network-related CDEVs,
especially those which may be requesting network services at boot
time (such as Network Time). Again, this probably isn't necessary,
but who knows... As is well-known, many INITs produce mind-
boggling conflicts. When you succeed in making MacTCP work without
them, you should later reinstall them one by one, checking - say -
telnet after activating each of them. If MacTCP conks out, you'll
know the culprit! If that happens, please publicize your findings,
or at least send a note to me!

o  If you will be using MacTCP over Ethernet, install network
drivers according to manufacturer's instructions. For some
inexplicable reason I had better luck when I turned off AppleTalk
in the Chooser before doing this. If you are installing Apple's
drivers, make sure to use the latest Network Installer disk.

If you will be using MacTCP through the serial (printer) port,
activate AppleTalk in the Chooser now.

o  Put fresh MacTCP, AdminTCP in the System folder. Make sure that
you are using the newest version, and not some old beta copy
obtained from shady sources. Under System 7+, they will go into
the proper subfolder automatically. If you do have to use the
older version 1.0 of MacTCP with System 7, you need to put these
files in the top level directory (i.e. don't let the Mac put them
in the Control Panels Folder; this is best done by dragging them
into an open System Folder window, rather than onto the System
Folder icon). Then make aliases to both of them and drop the
aliases in the Control Panels folder. Otherwise MacTCP 1.0 will
get confused.

o  In the next few steps in our procedure, MacTCP will create two
files: MacTCP DNR and MacTCP Prep (under System 7 the latter
should end up in the Preferences folder). You did remove the old
ones, didn't you? Since some virus protection utilities might
think that the new files that MacTCP is installing in the System
folder are viruses, it is a good idea to shut off all virus
protection before you go any further.

o  Configure MacTCP or AdminTCP (you will find more about that in
later sections). Make sure you set the right network class and
subnet mask if you use static addressing. You don't have to worry
about that if you use a server such as FastPath or EtherRoute/TCP
to assign addresses. For the time being, don't do anything with
the "gateway" (should be 0.0.0.0) and "nameservers" (blank)
fields.

o  Remember to set the correct physical layer setting ("LocalTalk"
or "Ethernet Built-in") in the MacTCP panel (if it gives you that
choice).

If the MacTCP panel does not show any choices at all, it might
help to zap the parameter RAM by holding down:
command-option-p-r while restarting the mac .(system 7)
command-option-shift while opening the Control Panel (pre-7 systems)
(reported by Mike Wiese of MIT in a Usenet posting).

Note that the physical link setting has nothing to do with the
network resource (selected in the "Network" CDEV) which you will
be using for AppleTalk functions, such as printing or AppleShare:
we're dealing with strictly TCP/IP stuff.

If your Mac is using a direct Ethernet connection for TCP/IP, you
*don't need to* (nor should you, in some specific cases) activate
AppleTalk or choose anything in the Network CP at this point.

However, if you are using TCP/IP through the LocalTalk port, you
must have activated AppleTalk in the Chooser before - otherwise
MacTCP doesn't know how to communicate with the outside world! On
a Mac Plus, trying to reconfigure MacTCP with AppleTalk shut off
will likely result in a horrifying "address error" or "illegal
instruction" message. Don't worry - reboot, turn on AppleTalk and
see if the new MacTCP settings are still there. If not, configure
it one more time. Everything should be fine after that.

o  Even though MacTCP 1.1 doesn't always tell you to do so, REBOOT
now! Check that MacTCP DNR (and usually MacTCP Prep) files show up
in the System folder.

o  Older Macs, notably the Plus, become overworked while running
System 7 (more precisely, the newest versions of AppleTalk,
version 56) and MacTCP 1.1. Apple has just released an unsupported
patch which fixes the problem. You can get it from ftp.apple.com
(see section IV, Sources, below). Do NOT install this patch
unless: you have a Plus, *and* you run AppleTalk vsn. 56 or
higher, *and* you use MacTCP 1.1. Another workaround is to use a
SCSI Ethernet adapter instead of a LocalTalk connection; the SCSI
port can handle this load, while the serial port controller can't.

o  Test MacTCP by running an application such as NCSA Telnet (the
MacTCP version, of course). If the NCSA logo quietly disappears,
you're in business. Try connecting to a *nearby* host by giving
Telnet its decimalized IP address.

As of this writing, newest versions of NCSA/BYU Telnet sometimes
produce a system error when they're run on a Mac Plus under pre-7
System. This might indicate a serious problem, but in 9 cases out
of 10 this happens only the first time you attempt to run Telnet.
Reboot and try again.

o  Assuming all went fine, you can now set the AppleTalk link in
the Network panel if you wish (if AppleTalk was off, that is; this
should also automatically turn on AppleTalk in the Chooser, but
check it just in case). There are some exceptions here. For
example if your Mac is on Ethernet, which in turn is connected to
a Token Ring with the IBM 8209 bridge, activating AppleTalk might
screw up TCP/IP. Details available on request.

o  If you can't connect to remote hosts, tell MacTCP about a
default gateway which should handle traffic beyond your local
network. You may also want to tell it where the local nameserver
for the root domain is (put a period in the "Domain" field, enter
the IP address in the box next to it, click Default). To be on the
safe side, trash MacTCP DNR and MacTCP Prep again and reboot.

o  You should now be able to telnet to a remote host, and Telnet
should be able to resolve symbolic addresses for you: e.g.
nic.ddn.mil or sumex-aim.stanford.edu.

If after all this you are still having problems, first check the
hardware (is Ethernet up? are plugs plugged in? switches switched
on? gateways are gatewaying? etc) Next, consider the possibility
that some other node is using your IP address. See if things work
if you change the IP address to another one from the range
assigned to you. It has been reported that if there is a conflict
in IP numbers, MaTCP returns an error code which most applications
then translate to a less-than-helpful message like "MacTCP is not
installed correctly", or "Error opening TCP drivers - possibly no
dynamic addressing".

If that doesn't help, buy a pair of tickets to Jamaica and invite
your high-school flame along. After all, will you let a piece of
steenkin' iron drive you nuts?!


4. Details...

In the description below, we use the MacTCP control panel. The
only difference between it and AdminTCP is that the latter allows
you to lock and unlock the former; other than that, they are
functionally identical. If the MacTCP panel you have has been
locked, you won't be able to make any changes to it; you have to
unlock it with AdminTCP first, or simply make all changes from
within AdminTCP.

After opening the MacTCP control panel, you should first set the
physical link for the TCP/IP connection; for instance, if you use
MacTCP on a LocalTalk network - whether gatewayed to an Ethernet,
or isolated - select the "LocalTalk" icon. If you are directly on
Ethernet, click the "Ethernet Built-in" icon.

Now click the More button. In the first stage, you will be setting
only three things: address assignment mode, network class, and
network subnet.


-  If you are a "trusted and permanent" user who received a
specially assigned IP address, click the "Manually" radio button.
As a rule, it is best to have a permanent, static IP address. Some
networks, however, have more nodes than addresses available to
them. Such institutions resort to assigning addresses dynamically
to those hosts (usually PCs) which request them; see the next
subsection.

Please remember that choosing an address at random will at best
make your connections unreliable; it can also provoke unrestrained
wrath of some powerful people in your organization. Courts have
been known to drop bodily harm charges under much weaker
extenuating circumstances. Moreover, some network numbers are
illegal on the Internet. If you pick one of those, you'll be
asking for a lot of trouble - in particular, you'll be getting all
e-mail addressed to the University of Mars for the rest of your
life.

o  The IP number you were assigned determines the network class.
MacTCP is smart enough to figure it out by itself. You can also
set it manually: addresses beginning with 1-127 are class A, 128-
191 indicates class B, and 191-254 are class C. Make sure you know
what you are doing.

o  The netmask can be determined by stopping a friendly
administrator in the hall and asking one or two simple questions.
"Do we use subnetting?" And, "If so, how many bits form the subnet
number?" If the first answer is "no", then slide the subnet mask
indicator as far to the left as it will go. Such masks are
255.0.0.0 for class A networks, 255.255.0.0 for class B, and -
guess what - 255.255.255.0 for class C.

If your site does use subnets, the plot thickens. A number of
address bits is set aside as the subnet number. You have to enter
the subnet mask (such as 255.255.255.0, eight bits determining the
subnet in a class B network) in the appropriate field; or you can
delicately slide the subnet indicator to the right until it marks
the right place. For example, if 6 bits are reserved for the
subnet, you slide the thing from the leftmost position to the
right by six little notches.

Be forewarned: it is vital that all hosts which have the same
network part in their address use identical subnet mask. You can
avoid a lot of desperation in the future if you make sure you get
this straight. 'Tis the time to read the manuals, perhaps?

o  Get out of the "inside" panel by clicking OK. Type your IP
address in the edit field in MacTCP. Go back to the subpanel to
verify everything is as it's supposed to be. If anything has
changed all by itself, you are probably trying to set a wrong
network class.


-  If you were told that "dynamic address assignment" is available
to you, then all you need to do is click the Server radio button
in MacTCP. Things should work automagically thanks to built-in
intelligence of devices such as the FastPath, GatorBox, or
EtherRoute/TCP. If there are problems, you have to get together
with the person who maintains your gateway.


-  Many people prefer to stay away from the "dynamic" button in
MacTCP. Others have been using it successfully. I have no well-
founded opinion...


When you have entered all the required information, and you
suspect that the user has itchy hands, it's time to click the
"protected" box, close the panel and reboot right away. Remember
to trash AdminTCP from his disk after you are done setting things
up.

If the user is likely to heed your advice, but might accidentally
change the settings, click the "protected" box in AdminTCP, tell
him not to fiddle with AdminTCP, and leave the control panel on
his disk. This will save you some time and trouble when you have
to change his settings again.

If the prospective user is a TCP/IP sage, then you of course leave
things wide open for him to play with the little buttons during
long winter nights.

There are some other permutations involving, for example, locking
just the network part of the address, but leaving the subnet and
node numbers accessible. Please read the manual!


5. More details

After you have coerced MacTCP to work with this basic
configuration, you may want to enter a few more things.


The "Gateway Address" field in the MacTCP control panel should
contain the IP number of the default gateway, i.e. the place where
MacTCP should send packets if it doesn't know what else to do with
them (i.e. packets addressed to a remote network). On most
networks you will leave that field set to 0.0.0.0, and MacTCP will
locate the default gateway by means of a magic wand called Routing
Information Protocol (RIP).

If your network for some reason does not implement RIP, you must
enter a "real" address there. For example, if your Mac is on
LocalTalk, you would use the address of a FastPath or another
device which connects your network with the Ethernet. If you are
directly on Ethernet, you should use the address of the router
which connects that Ethernet to the campus network, or - if you
don't have routers - the gateway which links your outfit with the
rest of the world.


You will also want to tell MacTCP where to find nameservers. Going
into the details of the Internet Domain Name System (DNS) would
make this document twice as long, so we will stick with the
basics. The Domain Name System is used by computers to convert the
human-friendly names such as "spider.math.ilstu.edu" to numeric
addresses (IP numbers) such as 138.87.132.21. On occasion,
computers use this system to "reverse-map" numeric addresses, i.e.
to verify that your numeric address does correspond to a name
which recognized by the DNS.

If your network is connected to the Internet, your computer lives
in some well-defined "domain". In my case, it is math.ilstu.edu,
and a machine with address 138.87.132.21 is providing name service
for that domain. I thus enter "math.ilstu.edu." (no quotes, but
note the period at the end!) in the Domain field, and
138.87.132.21 in the Server field next to it. I also click the
Default button. This informs MacTCP that my computer is in the
math.ilstu.edu domain, so when I tell my Mac to telnet to "koala",
it will query the nameserver about the address of the computer
"koala.math.ilstu.edu". Here is the first row of edit fields on my
Macs:

 --------------------------------------
| math.ilstu.edu. | 138.87.132.21  | x |  ("default" button on)
 --------------------------------------

If the local nameserver doesn't keep a large table of addresses,
or if it is less than reliable, you will probably want to put in
some backup servers in fields below. In particular, one or more
Domain fields could contain the period alone ("root domain", i.e.
the entire Internet) with the address of a big, reliable machine
next to it.

Clicking the "default" button by no means guarantees that this
particular server will be consulted first; MacTCP first contacts
those nameservers listed in the control panel which seem to match
the domain name included in the query - and only if that fails,
the default server is asked as a last resort. However, all domain
name queries should generally go to your local nameserver first.
You may want to enter your local nameserver's address in the
second row as well, specifying the root domain (period) in the
first field. In my case, the second row would thus look like this:

 --------------------------------------
|   .             | 138.87.132.21  | o |  ("default" button off)
 --------------------------------------

A small text file called Hosts can be put in the System Folder
proper. I was told that some applications (e.g. VersaTerm)
automatically create this file and modify it when needed. The
Hosts file lets you enter additional information which MacTCP
uses. For example, I could enter

spider.math.ilstu.edu.   IN   A   138.87.132.21
math.ilstu.edu.          IN   NS  spider.math.ilstu.edu.
rs6000.cmp.ilstu.edu.    IN   A   138.87.1.2
rs6000.                  CNAME    rs6000.cmp.ilstu.edu.
ilstu.edu.               IN   NS  rs6000.cmp.ilstu.edu.

there to tell MacTCP that the computer spider.math.ilstu.edu has
address 138.87.132.21, that it is a nameserver for my domain, that
rs6000 in Computer Services has address 138.87.1.2, that I connect
to it often enough so I want my Mac to use rs6000.cmp.ilstu.edu
whenever I say "rs6000" (otherwise MacTCP would be looking for
rs6000.math.ilstu.edu!), and that it is a nameserver for the
domain directly above me.

The use of periods at the end of domain names guarantees that
MacTCP treats them as "absolute names", and doesn't try to append
anything to them. If you know what you are doing, you can work
with relative names (without the period) saving some space,
typing, and quite possibly reducing the amount of memory MacTCP
consumes - the current MacTCP implementation is rather limited in
this respect. Assuming that my Macs are placed in the domain
"math.ilstu.edu" by using the 'default nameserver' button in
MacTCP, I could simply use "spider" instead of the absolute
"spider.math.ilstu.edu.", because that extension would be
automatically appended to a relative name without the period.

For a list of specifications allowed in the Hosts file, see the
MacTCP manual.

After modifying the Hosts file or the nameserver information in
the MacTCP control panel, make sure to trash the MacTCP DNR file,
and reboot right away.


III. Applications


There are many commercial programs which use TCP/IP connectivity
(InterCon's family of networking applications, or VersaTerm from
Synergy Software). I will not review them here because I have had
little or no experience with them. Let the vendors speak for
themselves. Some makers of similar commercial products are
mentioned in Section IV for your convenience.

The list of public domain or shareware software which follows will
hopefully be amended and expanded in the near future - please send
in your favorites!


1. Terminal emulation

There are currently two popular freely available programs which
let the Mac connect to other hosts as a terminal using TCP/IP
(telnet): NCSA Telnet and its derivative, tn3270.

The first one is being developed at the Nat'l Center for
Supercomputing Applications in Urbana-Champaign. It emulates a
vt100 terminal and provides some Tektronix graphic terminal
capabilities; it also implements an ftp server function, i.e. when
it's running, you can ftp *from* other hosts *to* your Mac. NCSA's
version was modified somewhat by the Brigham Young University;
NCSA/BYU Telnet implements a simple ftp client function.

The second, tn3270 written at Brown University, is a variant of
Telnet which provides the IBM 3270 terminal emulation. It also
supports file transfers and printer sessions, but I don't know
enough about our IBM big iron to actually try them out...

NCSA Telnet comes in two versions: one which relies on MacTCP, and
one which includes built-in TCP/IP drivers. If all you need is
terminal emulation, the second version might be for you.

Stanford University has developed a comprehensive package of
TCP/IP applications collectively known as SU-Mac/IP. I didn't have
a chance to try it. One advantage of Stanford's software is that
it reportedly gives more informative error messages, which can be
a great asset - especially when you are having problems!
Contact [e-mail] for conditions of a site
license. If you know how to use MacBinary FTP, you can download
the entire SU-Mac/IP documentation in MS Word format from
jessica.stanford.edu (directory netinfo/macip/manuals4.0/users).


2. E-mail

There are several schemes in which a Mac can access Internet mail.
The crudest way, of course, is to telnet to a host on which you
have an account, and use that host's mail facilities. Another is
to keep using whatever mail system you have on the AppleTalk
network (e.g. QuickMail or Microsoft Mail), and then provide a
SMTP gateway which will translate it to Internet mail; this tends
to be expensive and sometimes unreliable.

By far the most popular and convenient system is the client/server
method, in which one computer uses its powerful mail software and
provides service to clients such as Macs or PCs. Macintosh users
have the good fortune of being able to use some excellent mail
clients which work on a Mac. Eudora written by Steve Dorner of
UIUC leads the pack (in my humble opinion), with MIT's Techmail a
close second.

Eudora and other similar clients allow the user to read, compose,
edit mail on the Macintosh desktop, print mail, save messages as
Mac files, and attach Macintosh-specific files (say, formatted
Word documents or even applications) to the letters. When it's
time to process mail, Eudora contacts the server, uploads messages
waiting to be sent and downloads those which the server received
for you. The (supposedly) well-maintained and well-connected
server computer handles the rest, so you don't need to know
anything about Unix or any other alien operating system.

A special "Post Office Protocol" has been defined to handle this.
There are two versions of it: POP2 and POP3. The server and the
client have to agree on the version they speak. Most Mac clients,
in particular Eudora, are POP3. If you succeed in sending mail,
but attempts to check incoming messages fail, then it is very
likely that your POP client and server use different versions of
the protocol.

It is easiest to set up a POP server on a Unix computer (popper
from UC Berkeley seems to be the way to go here), but there are
also servers operating under other systems, including one (POP2)
which runs on a Macintosh. If you use a VAX with VMS, and some
TCP/IP package is already installed, chances are that it includes
a POP server. Talk to your local system administrator.

For those of us who need to worry about PCs too, POPmail from
University of Minnesota runs on MS-DOS machines and is compatible
with both POP2 and POP3. A POP2 server running on a Mac is also
available from that site.

A Macintosh mail client is also included in Stanford's SU-Mac/IP
package, available for a nominal fee.

In case you don't have a reliable machine which may be used as a
POP server, don't worry; your Mac can be made into a full-blown
SMTP mailer, and it then behaves like any other "real" Internet
mail node. Get Lee Fyock's LeeMail and try it out. I haven't, so I
can only rely on second-hand reports which say that LeeMail might
not be as smart as a full-blown Unix mailer, but it works just
fine.

Finally, a Swedish offering - MacPost - is something of a mixture
of both methods; it has both a client and a server running on a
Macintosh, but requires a Unix host as an intermediary for outside
mail. The transactions between the individual clients and a
MacPost server only use AppleTalk, and TCP/IP is only needed by
the server Mac to communicate with the Unix host. I haven't used
this one either, but who knows - it might be just the thing for
you.

Steve Dorner occasionally posts his much more complete list of Mac
POP clients (including commercial ones) to newsgroups such as
comp.protocols.appletalk and comp.sys.mac.comm.


3. FTP

As we mentioned above, Telnet has limited ftp capability. But two
other applications, XferIt and Fetch, are specifically designed to
provide "FTP with a human face". Both present the directory on the
remote host as a Macintosh dialog window, in which the user can
select files to be downloaded. I've found minor quirks in both of
them, but overall they are extremely impressive and useful. There
is also HyperFTP, a HyperCard stack which is similar to the two
applications. It is very solid, but relatively slow, and -
naturally - it requires a reasonably recent version of HyperCard
and consequently quite a bit of RAM.

As with telnet and mail, an ftp application is also available as
part of the SU-Mac/IP software.

When using FTP from a Mac, you should realize that many anonymous
FTP sites do not allow connections from hosts which are unknown to
the Internet nameservers. To connect to such nodes, your Mac's IP
address has to "reverse-map" to a legal Internet name, like
mac1.math.ilstu.edu. The system administrator of your nameserver
computer might be willing to enter your address in his database.

See Appendix A for a very short introduction to the intricacies of
Macintosh file transfers. For more information on the procedures
involved in FTP'ing Macintosh files, read the text file ftp-
primer.txt, which can be found on sumex-aim.stanford.edu in the
directory info-mac/reports.


4. Network news

As with FTP, there are three applications and one HyperCard stack
designed to let you access news: TheNews, Newswatcher, Nuntius,
and NetNews. I have not experimented with Nuntius, so I can only
comment on the other three. There are minor problems with each of
them, compounded by the fact that this method of reading Usenet
articles usually involves downloading humongous lists of articles
over a slow connection such as overloaded LocalTalk, keeping track
of read items, and so on. This is not for the faint of heart. Many
people still stick to the old-fashioned method of logging on to a
bigger host and reading news there. But when it works, it's worth
it! You can finally organize the saved articles on your own disk,
use your favorite word processor to write replies, etc.

News clients require an address of a nearby friendly NNTP server.
The server needs to be friendly in the sense that it must
recognize your Mac as a host which is allowed to post news. This
also requires having a valid domain name (see above under FTP),
and the server must have been configured to accept uploads from
your computer. Even though many servers allow free read access but
limit posting, the Mac clients will usually give up without
explanation unless they are granted both permissions. This causes
a lot of confusion among novice users, who later post complaints
about "broken newsreaders".


5. Miscellaneous gadgets

There are dozens of useful or simply nifty applications which use
MacTCP. Here are two of my favorites.

Network Time written by Peter Resnick is a CDEV which periodically
contacts an Internet timeserver, like merit.edu or nic.ddn.mil,
looks at the Map CDEV to determine your location (and hence time
zone offset; I particularly like this elegant touch), and sets
your Mac's clock. After installing it you can boast that your
screen clock is accurate to a tiny fraction of a second.

Finger and fingerd by Peter Lewis give Macs the Unix "finger"
capability. Finger sends a finger query to a remote host; it's
even smart enough to automatically put people whom you "finger-ed"
in a menu, so you don't have to type their address again. Finderd
simulates a finger daemon on your Macintosh, so other people can
finger you while you are simply working on your Mac.

Peter recently released another fine product - Talk, which
simulates a Unix "talk" client and daemon on the Macintosh. A
third gadget written by him, Chat, turns a Mac into a simple
conferencing center (a la IRC, for those who have used it).

The Internet Gopher searches "gopher servers" on various Internet
hosts and retrieves various information such as directory entries,
class schedules, campus newsletters, etc. One Macintosh client is
a HyperCard stack written at University of Minnesota. A standalone
version, GopherApp - still a bit quirky (e.g. it cannot retrieve
documents larger than 50KB or so) but very promising - comes from
Indiana University.

Wide Area Information Service is a fruit of a joint project of
Apple Computer, Thinking Machines, Peat-Marwick and Dow Jones.
There are several WAIS servers in operation; they can be queried
from a Mac by means of an application called WAIStation. A WAIS
server can also be accessed by telnet to quake.think.com (login
name wais). Check it out! It's a glimpse at the things to come.

MIT's TechInfo is another impressive example of a fast and easy to
use information retrieval system. MIT and a few other institutions
run servers which store and search databases of campus events,
faculty and student directories, etc. Both Mac and PC clients are
available.

If your Macs use the CAP AppleShare server, chances are you'll
want to look at MacDump, which permits automated backups of your
Mac volumes onto the CAP server.

A desk accessory called Client DA (written by Greg Anderson of UC
Santa Cruz) connects to the Unix daemon "supersrv" (by Steven
Grimm), which in turn uses the wonders of Unix to do whatever you
want it to do. For example, a trivial Unix shell script invoked by
supersrv allows our faculty to search all users on the system, or
access the archie ftp search facility directly from their Macs.
Client DA has some problems with smaller Macs, and I wish someone
kept maintaining this wonderful gadget.

On the lighter side, we have GameMaster, which lets you play a
variety of games over AppleTalk and TCP/IP networks.

Please let me know what are your favorites in this category - I'll
be happy to expand this section!


IV. Sources


1. Downloading text files

Use any account available to you on a well-connected host. Type
"ftp sumex-aim.stanford.edu" (or if that doesn't work, try "ftp
36.44.0.6"). Type "anonymous" as login name, and your mail address
as password. In 9 cases out of 10, archives such as this one
accept "ftp" in place of "anonymous", which means that you can
delay the onset of carpal tunnel syndrome. You will also discover
that most sites will accept any password at all, but let's be nice
to those folks who specifically ask for the real id.

Enter "cd /info-mac/report", and then "get ftp-primer.txt". When
you see "Transfer complete", type "quit" and read the file you
just downloaded.

After becoming skilled in using ftp, download some more text files
from the /info-mac directory:

help/accessing-files.txt
report/how-do-i-find.txt
report/internet-access-11.hqx
report/ftp-sites.txt

The anonymous ftp site nnsc.nsf.net run by the National Science
Foundation is a good source of background information about the
Internet (see directories /nsfnet and /info).


2. What next?

When you have learned how to download Macintosh executable files,
it's time to go hunting for specific applications.


WARNING!!!
The minute you start downloading files from the network, you
become more susceptible to viral infection than before. I strongly
suggest that you should first get and set up the wonderful free
virus checker, Disinfectant. Its home is ftp.nwu.edu, in directory
/pub/disinfectant; it can also be found in many other places, e.g.
on sumex-aim.stanford edu in the directory /info-mac/virus. You
may then want to send its author, John Norstad, a nice thank-you
note: we all owe him a great deal! If you have access to Usenet
news, make it a habit to monitor the comp.sys.mac.announce group:
it is probably the most reliable source of inform
ation about newly
discovered viruses.


Here is a list of applications which were mentioned above, and
which can be found on sumex in the directory /info-mac. Asterisk
indicates that the program used to be on sumex, but has recently
disappeared for unknown reasons; such software can be found on
many servers which maintain copies of /info-mac contents, such as
wuarchive.wustl.edu in /mirrors/info-mac.

comm/chat-10.hqx
comm/fetch-206.hqx
comm/finger-135.hqx
comm/hyperftp-13.hqx
comm/lee-mail-124.hqx
comm/ncsa-telnet-24-docs.hqx
comm/ncsa-telnet-standard-245.hqx
comm/ncsa-telnet-tcp-245.hqx
comm/news-watcher-102.hqx
comm/nuntius-11.hqx
comm/the-news-21.hqx
comm/xferit-14.hqx
cp/network-time-111.hqx
game/game-master.hqx (*)


Software found on ftp servers other than sumex:

ClientDA:         ssyx.ucsc.edu (supersrv is there as well)
Eudora:           ftp.cso.uiuc.edu in /pub/mac/eudora
GopherApp:        ftp.bio.indiana.edu in /util/gopher
Gopher stack:     boombox.micro.umn.edu in /pub/gopher
MacDump:          bbn.com
MacPost:          pollux.lu.se in /pub/mac/comm
MacTCP+ patch:    ftp.apple.com in /ftp/dts/mac/netcomm
NCSA/BYU Telnet:  bert.cs.byu.edu
NetNews:          ftp.bio.indiana.edu in /util/mac
POPmail:          boombox.micro.umn.edu, in /pub/POPmail
popper:           lilac.berkeley.edu
SU-Mac/IP:        send e-mail to [e-mail]
TechInfo:         net-dist.mit.edu in /pub/TechInfo
TechMail:         net-dist.mit.edu in /pub/TechMail
tn3270:           brownvm.brown.edu
WAIStation:       think.com in /wais

A list of anonymous FTP sites (not only Macintosh-related) is
maintained on pilot.njin.net. Many Unix hosts (and an increasing
number of other machines) will also let you search an archie
database of anonymous ftp sites.

This should keep you busy for now...


3. Contacts for commercial products

Please remember that I do not in any way endorse commercial
products by listing the vendors here, and I'm not in any way
associated with them. This is simply for your convenience. Phone
numbers are followed by an anonymous ftp server which can be used
to get free upgrades and information, or an e-mail address.

Cayman Systems         [phone]    ftp.cayman.com
Compatible Systems     [phone]    csn.org, in /compatible
Farallon Computing     [phone]    farallon.com
Intercon Systems       [phone]    [e-mail]
Shiva                  [phone]    shiva.com
Synergy Software       [phone]
Webster Computer Corp  011(?) 61 3 764 1100  (Australia)


4. Let's end with a short sermon...

Many of the applications mentioned above are NOT in public domain.
They are either shareware, or there are restrictions on their use
and/or distribution. PLEASE PAY FOR SHAREWARE YOU KEEP!!! Author's
address can almost always be found by pulling down the Apple menu
and selecting "About..." Let's keep this wonderful, affordable
software alive!


Appendix A. Peculiarities of Mac file transfers


Macintosh files differ from files on most other machines in that
they consist of two parts. One contains data (text, executable
program), and the other - resources (icons, the file's creator
code, etc.) I'm simplifying a little, but never mind. This
complicated structure prevents us from sharing such files directly
over the network.

Moreover, there is only one language which practically all
computers understand: the ASCII code (plain text). Even though
this isn't a terribly elegant solution, we simply bring everything
to this lowest common denominator to assure compatibility. For
example, in order to send a file to someone by the current e-mail
systems, it has to be somehow encoded into an ASCII file.

The Mac community has pretty much agreed on a common standard for
doing just that: BinHex. BinHex swallows a Mac file, icons, file
creators and all, and converts all that into a plain text file
filled with something that looks like garbage; it also performs
the reverse procedure. So you need BinHex.

There is one obvious difficulty, however: how do you get a BinHex
decoder (a Macintosh application!), when you don't have BinHex?
You will also need software which will somehow let your Mac do
FTP. The easiest way to "bootstrap" yourself is to simply get a
copy of such a beast from a local Mac guru or a Mac User Group. If
you're lucky, you will lay your hands on an FTP utility which can
also de-BinHex files, such as XferIt or Fetch. You can then tell
it to connect directly to, say, sumex, dowload the interesting
BinHex'ed files, and decode them while they arrive.

Another way is to get NCSA Telnet, log on to a friendly Internet
machine, download the applications you need to that computer in
*binary* form (e.g. the file binhex4.bin available on sumex in
/info-mac/util) using *binary* ftp. Then connect back to your Mac
using the Telnet FTP server and put the files on the Mac using the
MacBinary mode... It sounds (and is) complicated, but remember -
this convoluted process is necessary only in the very beginning.

Once again, we have just licked the surface of this topic here.
For more information, see the file /info-mac/report/ftp-primer.txt
on sumex-aim.stanford.edu.


Appendix B. Dial-in access

In our personal opinion, the most elegant way to connect a Mac to
a TCP/IP network is AppleTalk Remote Access (ARA), a commercial
product of Apple Computer, bundled with PowerBooks, and sold as a
separate product.

ARA uses the Communications Toolbox (built into System 7, and
installable in System 6.0.x) to ship AppleTalk packets over a
modem to an ARA server, which is presumably connected to a "real"
network. MacTCP in turn uses the AppleTalk protocol to transmit
"wrapped" TCP/IP packets (if it is configured to communicate via
AppleTalk). This results in a two-stage translation: TCP/IP-to-
AppleTalk, and AppleTalk-to-modem. The data have to be decoded by
a reverse process at the other end.

This explains the only drawback of ARA: speed. A 2400 baud modem
is next to unusable in this configuration. But a 9600 baud
connection should provide decent response even with the additional
IP encapsulation.

The server Mac, whether it's on Ethernet or LocalTalk, spews out
AppleTalk packets, from which the TCP/IP information has to be
reconstructed by an IP gateway. If you don't have a gateway such
as the Fastpath, GatorBox, EtherRoute, or MultiGate, you can't use
ARA for TCP/IP access to the network.

Since for most of us the primary Internet application is e-mail,
we will mention the "poor man's" dial-up connections which can be
used with the mail client Eudora. You need to know how to edit a
program's resources to patch Eudora in this fashion -- a task
which is not for the faint-hearted. The two alternatives are:

 i) modify "stock" Eudora to navigate through a simple modem
    connection;

ii) use the Simon Fraser University version of Eudora and create
    an intelligent connection script.

The first method is described in the Eudora Q&A stack available
from uxc.cso.uiuc.edu. Additional information is in an appendix in
the Eudora documentation, available from the same source. We have
successfully used this scheme with a direct modem connection to a
Unix POP server.

The second way is to learn a simple programming language which the
SFU Eudora understands, and use it to get through the maze of
terminal servers and multiple logins. This version of Eudora is
available from fraser.sfu.edu.

More esoteric connection schemes, such as SLIP or PPP, are outside
the scope of these notes (this is a cowardly way of saying that
"we have no idea if or how well they work"). PPP software is on
drawing boards or in beta tests, while SLIP connections require
specialized Macintosh software, and a suitable set up at the
network end. If you are interested in this subject, watch the
newsgroups for information about "MacSLIP", "Cisco Telnet", the
"ka9q" package, etc.