[comp.mail.misc] clarification

dzoey@umd5.UUCP (03/31/87)

Thanks to all the people who have taken time to send me information about
their electronic mail setup.  They have been quite informative.  I think
though, a little backround needs to be given.


Here at Maryland, we're thinking of providing email access to anyone who
wants it (not just regular computer users).  For example, Joe Philosophy
would be able to send mail to Sherry Architecture, yet neither of them
are taking courses in which computers are accessed.

Has anyone else had experience with this?

What are the technical pitfalls to look out for?
What are the administrative pitfalls to step over?

Once again, thanks to the people who've already sent me replies,
I very much appreciate it.


			Joe Herman

P.S.  Even if this isn't your situation, any information dealing with a
      large mail user population would be helpful.



dzoey@umd5.umd.edu
dzoey@umdd.bitnet
seismo!umd5.umd.edu!dzoey
-- 
"Everything is wonderful until you know something about it."

dpz@paul.UUCP (04/02/87)

> From: dzoey@umd5.umd.edu (Joe Herman)

> What are the technical pitfalls to look out for?

You probably want to think hard about the kind of environment you are
going to present.  Give a choice, because while some users may be
hackers (ie, those who can stumble through yards of 68030 assembly
without batting an eye), others may just want to use it as a toaster
oven (ie, those who want to press a button and make it go,
essentially).  How much access to the operating system will you want?
Watch out for the crackers, but leave room for the toaster people to
move on a bit if they want to.  Menus can be a large help, if you have
the time and resources to set up a really good looking, logical,
explanatory menu system.  Do you have any mentally/physically
handicapped students?  Will you ever have?  Keep an eye on their needs
- those with learning disabilities need clear, simple, consise menus
that they can understand with little to no help (this is not a small
task from my experience).  Make sure that the terminal stations for
this project are comfortable for someone in a wheelchair, who may
spend a lot of time there.

You can have many kinds of system setups, as you well know.
Standalone Sun clusters, huge mainframes, networks and networks and
networks of IBM PCs, or any combination of these will work.  You may
want to think whether you want them to mail to "user@host" or just
"user".  You may laugh when I say keep it simple, but some people just
may not be interested in the computer revolution, and you don't want
to ram it down their throats.  Am I saying user@host may be too
complicated?  Very possibly, depends on how many hosts there are.  The
simplest thing I can think of is the login shell being mail on a big
black box to which they can send junk mail to their dormmates, and for
those who don't care, this may be all the "view-of-the-world" that
they want.  Of course, if you want to do this for *all* students, a
single box may not be enough.  Then you may have to do some trickery,
like getting 30 multiuser Sun 3/280s or something and pointing all of
their /usr/spools to a single reliable mail server.  Terminals are
probably best on the user input end, simply because they are the
cheapest I/O things around (next to a, yechhh, printer).  IBM clones
might also be cheap, but maintenance of software and hardware would
probably end up being more than terminals, and then you need someone
fairly knowledgable about IBMs to maintain and fix them.  And of
course, you can either telecommunicate through the serial port or
cater to the hackers with an Ethernet board and telenet software ($$$)
- somewhat more flexible than terminals.

> What are the administrative pitfalls to step over?

*Sigh*.  Watch out if you try to get all of the departments to pitch
in to install/support this thing.  If your CS department can handle
the cost of this, then more power to you.  If you can get some kind of
funding above them, like University level funding instead of
department level funding, then you won't have to deal with the
individual deparments.  But I wouldn't expect 100% cooperation from,
say, the athletics department.

Accounting?  Disk space quotas?  ARPA access?  You will have to decide
whether these mean anything to your setup.  Will you really care about
charging students or faculty for online time?  Be careful about
charging students per hour.  If you need to charge them, make it a
one-price-pays-all type of deal for a semester or year or something.
(This is why I *don't* use Compuserve unless my boss happens to be
paying. :-) Disk quotas would not be outrageous, but don't penalize
the users by wiping out their mail or .newsrc files if they can't save
them due to being over quota (or out of disk space!) as we have
unfortunately had problems with here lately.  There is nothing worse
then losing your saved mail and not knowing why.  ARPA access for
those who can intelligently (in many ways) grasp the idea of a network
would not be out of place, I don't think.  And for the sake of sanity,
make them memorize the net-etiquette before releasing them on the
Usenet!  :-)

Whew.  I'll stop now.  Please excuse me if I munged the administrative
and technical divisions of this message.

						dpz
-- 
David P. Zimmerman, Founder of the Society To Make "Hacker" Respectable

Arpa: dpz@rutgers.edu
Uucp: ...{ames,cbosgd,husc6,moss,seismo,ucla-cs,ut-sally}!rutgers!dpz