alex@comp.vuw.ac.nz (Alex Heatley) (04/26/88)
Electronic Mail Between Mac and Mainframe Mail System
WARNING - LONG POSTING.
Well, it seems that I have produced a considerable amount of discussion from
what I thought to be a trivial question. I've collected all the replies I've
recieved and sumarised them below. I've also added my comments where
appropiate and at the end I'll talk about what I was after when I asked about
whether there were any mail systems that did what I wanted. My thanks to all
those who replied and posted. With luck we might all get a mail system out of
this.
First off are the names and addresses of all the people interested in such a
system. I'm including these so that they can be contacted if anyone comes up
with something.
Mark Meredith (Unisys, Salt Lake City, Ut)
{ihnp4, hpda, uplherc}!sp7040!mjm
meredith@cs.utah.edu
801-594-6319
JOACHIM LINDENBERG <JOACHIM@iravcl.ira.uka.de>
Joachim Lindenberg, University of Karlsruhe
Federal Republic of Germany - West Germany.
Michael Helm (Arpanet: M_Helm@lbl.gov)
LBL ( uunet!Lbl.gov!M_Helm has been known to work...)
Now for the postings and email that had things of interest..
From: cetron@utah-cs.UUCP (Edward J Cetron)
Date: 20 Apr 88 04:23:14 GMT
Reply-To: cetron@cs.utah.edu.UUCP (Edward J Cetron)
Organization: Center for Engineering Design, Univ of Utah
I think the first question to answer is the physical distribution method. If
every Mac is directly connected to a VMS/UNIX box, I know of at least one
(maybe more) Public Domain packages which will work. I also know of several
Appletalk-only Mac to Mac systems (Intermail, Inbox, TOPSsomething, etc).
What I DON'T see is a mechanism which:
1. can be used Mac to Mac via localtalk transport.
2. can ALSO be used Mac to ??? via localtalk to ethertalk.
My suggestion (and yes it is just MY suggestion based on our facilities
preferences after trying lots of mailers on the Macs AND the two flavors of
vaxen):
1. use 'standard' SMTP as the transport mechanism from ??? mainframe to a
centralized Mac. Currently, Mac-PMDF seems to be the most versatile package
for this. What needs to be added is the transport via ethernet to localtalk
for those sites, serial line support is already there.
2. use Intermail as the Mac to Mac package.
3. write the code and hooks to gateway the mail from Mac-PMDF to Intermail.
This will likely be the hardest part. Also, if a very clean job is done here,
many other Mac-Mac mailers could be added here.
Well, that's my two cents worth....now if only I could find to time to check
how reasonable the above is.... maybe Microsoft (who know owns Intermail)
would be interested?
-ed
[Alex comments: This sounds interesting. My major objection is the implied use
of a Mac as a server. Ideally, the server should reside on the Mainframe, if
possible, in much the same way that using the CAP software, you can have an
AppleServe server residing on a UN*X box. My reason for wanting to do it this
way is that Macs are expensive and if you have a CPU running the Gateway, it
might as well run on the mainframe.
I'd also note that the reason while I use the term mainframe is that our main
e-mail hub is actually a IBM 4381 complete with custom mailer and user
interface. It works very well and we would like to expand it through to the
Macs. From our point of view, this can be done by using a combination of a
UN*X box and a Multigate box, gatewaying from the IBM to the UNIX box, then
out onto the LocalTalk network via the Multigate box.
What I had hoped would happen when I posted, was that someone such as THINK
would say "Hi, here is the protocol for our InBox server. You can use this to
write your own server sitting on whatever CPU you like." That didn't happen.
So what I might do is write a LocalTalk monitor and work out their protocol
myself. Do people think this is a reasonable approach?]
From: joachim@iravcl.ira.uka.de
Subject: Re: Macintosh mail systems.
Date: 18 Apr 88 21:15:33 GMT
Organisation: Universitaet Karlsruhe, IRA, F.R. Germany
There has been an ongoing discussion about Macintosh mail systems in the past
days, and as David suggested, anyone should state his/her requirements.
The following text will outline the requirements/interface that I see. This is
not intended to be a full spec, although we are thinking about implementing
it. I am a student of computer science at University of Karlsruhe, Federal
Republic of Germany, and I am involved in Macintosh projects at that
university. I am a computer consultant, too. There is no big difference
between the requirements at our university and large companies in Germany.
1. Macintoshes are turned on and off frequently, and may be off for long
periods of time (e.g. during holidays). Mail must not be returned
UNDELIVERABLE because of that. This implies that there must be a mail server.
Because most universities and companies already use a UNIX/VMS/other host for
mail, using this host to serve Macintosh mail is the most likely solution.
This does not imply however, that s/he is allowed to login to that host.
There are a number of possibilities, how the Macintosh front-end might
communicate to the host, two of them are MacWorkstation and an AppleTalk
service (based on CAP, AlisaTalk, ..), others might be SMTP, NNTP which I am
not familar with. The protocol may be proprietary, because it is only used to
communicate to the mail server, not to the world.
Of course if Apple released their specification of the AppleTalk Messaging
Protocol (Larry Taylor of Apple talked about it at EUC Heidelberg, April 8th,
1988), I'd go with that, if it suits all needs.
2. There must be a unified interface to mail and news, like the integration
present on unix hosts. I don't want to use a mac application to read/send mail
and another one to read/post news - or even worse, login on to (different)
host to do that. The application should also support digests (whether received
by mail or news), and interpret reply or followup sensibly, i.e., reply to the
originator of the message, not to the sender of the digest, mail followups to
the origin of the digest.
[Alex again: I think that reading/sending news is making the requirement
needlessly complex. I use rn for reading usenet and mail for sending mail, I
don't see why we have to have both a newsreader and a email facility in the
same package. I think that having the facility to read news should come later
as a different project/application]
3. Unlike the present mail applications, INBOX and INTERMAIL one cannot
assume that all possible recipients are known to the mail server. This
could be reasonable for one university or company, but not with the
internet behind. Of course, if your site already has a nameserver, the mail
application should be able to lookup local mail addresses by name.
[Alex: I'm not sure this makes sense, I imagined that we would have addresses
which flagged whether or not they were local or needed to be passed to the
mail server hub. For example, if I want to speak to Bill on another Mac
connected to my LocalTalk then I send email to Bill. If I want to talk to Bill
at MIT I go Bill@MIT (or whatever the correct RFC822 address form is), the
Mac server looks at the address, realises that it doesn't know about MIT and
throws it at the email server.]
4. One cannot assume that anybody is going to use a Macintosh to read her/his
mail. This has two consequences:
First, if files are to be transferred - and there is definitely a need to
include support for that - they must be included in a way that allows them to
be extracted manually and processed by some other tool. A simple but
sufficient solution is to include them binhexed, each preceeded by a line
standard mail will read this just as he always did and fire up binhex or
stuffit. A user using the mac mail will read a message that this mail contains
files, and choose extract from the file menu...
Even if I am using a mac to read mail, I may want to process/archive files on
the host. Someone might have mailed me a shar archive for use on the
(unix)host, or I may use unxbin on a unix computer and store the files
directly to AUFS volumes (that's how I install new stuff).
Second, there must be a character set conversion included. If you are only
going to mail in English, this is not required. If however, you receive mail
from any country, this is important. Imagine German umlauted characters. Of
course these characters are included in the Macintosh character set. But they
aren't ASCII. If I know that the recipient of the mail is using a mac too, and
that the mailers in between don't discard characters with the eigth bit on, I
may send the character unchanged, otherwise it has to be mapped to the closest
ASCII equivalent, possibly combined by several characters. Alternatively, some
other German user is using the German version of the ISO character set. This
is ASCII with the special characters [\]{\}~ replaced by German characters. I
want to tell my Macintosh that any mail received from this user is to be
interpreted using that character set. Another example: VAX/VMS supports
multinational characters using an ASCII extension, proprietary to DEC.
The point is, that there must be a possibility to convert both incoming and
outgoing characters, depending upon the sender/receiver and/or system
defaults. I emphasized this point, because this is crucial to our environment
- you won't sell your mail program in Germany, if the user gets beeps or
garbage typing umlauted characters. Of course this is a marketing decision.
Most of the points above are technically, not related to the user interface.
The following highlite some of the user related aspects.
5. It should include an editor. It does however not need to be a full blown
word processor. If you want to pass your new novel to another mac user,
include the document as an attached file. Anything within the range of
TeachText and MPW Shell is possible. No styles or justification is required
(imagine an IBM PC user, reading your letter on his monochrome card), but font
and size should be user selectable. Word wrap should be automatic, based on
charcter count, not on the window size.
[Alex: Because this thing has to send mail to people using other machines, it
must insert a <CR><LF> at the end of a line so that people, like myself who
read their mail on misbegotten IBM systems don't end up with messages that go
off the end of the screen]
The program should be able to manage arbitrarily large files. This may
however be limited to viewing/archiving them, not editing. The largest
mail I received was 2 MB and consisted of a uuencoded tar archive. Of
course this mail was to be decoded by unix tools, but you don't want your
mac to crash because of a large mail.
6. It has become a habit to comment on text by preceeding it with some special
character like > and inserting new text. While this is not the only way to
point out what you are going to reply to, and especially the mac could provide
a more graphic feedback (at least different fonts), this technique is common
sense. If the user chooses a function like reply, the macintosh mail program
should copy selected text (discontinous selections should be supported) to a
new window and mark it as comment.
[Alex: This feature is something that can be added later. It should not
necessarily be part of the initial design]
7. The program must provide for a list of name aliases. This should be
entirely transparent to the rest of the program. I.e. there should be no
special dedicated menus, but editing the list should be allowed whenever a
mail address is required and selected from the list. Selection should be
possible by both scrolling/clicking or typing as in standard file. New aliases
should be created automatically if you reply to mail. There must be an option
to delete no longer used names.
8. While incoming mail should be presented in separate windows automatically,
this may not be appropriate for news. A scrolling list of items that can
individually or collectively be opened or discarded comes to my mind. There
should be either no (prefered) or a very large limit to the number of open
windows - aren't you bothered by the finder's limit of 12 windows?
[Alex: I don't think that having three mail messages up at the same time is an
important feature]
9. There must be an automatic archive feature. I want any incoming mail to
be saved automatically, say in a folder named after the sender and with
the filename taken from the subject. There should be a flag associated
with each newsgroup, whether it should be archived (local or remotely) or
not, and this flag should be independent from whether I want to read it or
not - I don't read binaries.
[Alex: I would prefer to be able to save mail messages, with the default of
them being destroyed (user switchable)]
There should be an option that asks me where to put the file and when it
should be resubmitted. I consider this to be an important feature if mail is
going to be used in your administration. This will also provide a simple
reminders utility, although a real appointment calendar is more superior.
[Alex: again the requirement that the application also serve as a news reader
and manipulator is needlessly complicating the design.]
10. There should be an INIT that checks for mail on startup (this could be a
RDEV that selects among several mail hosts). There should also be a
possibility for the mail host to tell you about new mail arriving during your
macintosh work. This could be done using the broadcast mechanism I published
in the past (you can get it free, send mail to ry77@dkauni11.bitnet, I'll mail
it to you).
[Alex: To me, the ability to notify a user that mail has arrived, while they
are using their Mac is essential. Furthermore it should not rely on
applications running in the background under multifinder.]
Joachim Lindenberg, University of Karlsruhe
Federal Republic of Germany - West Germany.
From: dkovar@VAX.BBN.COM
Subject: Mac Mail - more thoughts
Date: 21 Apr 88 19:41:08 GMT
A lot of messages came in on this subject, many requesting any information
that I received but some providing information on their own needs and
enironments. Most of the latter were cross posted to info-appletalk or
comp.protocols.appletalk and thus you've already seen them.
The following is fairly general and is mostly intended to spark more comments
and input. Please bear this in mind as you read it. Also bear in mind that
I'm writing this at 11PM .... I'm waiting on more information from several
places but didn't want to hold everything up 'til next week.
Several mail products for the Macintosh exist, most notably CE Software's
QuickMail which is currently in beta test. It will provide hooks for external
mail interfaces. Byron Han described it earlier in this forum and I have
nothing to add to his comments at this point. Stanford will have Mac/MH in
the near future for universities with SU-Mac/UP licenses. Kinetics cannot
comment on future marketing policy for the Stanford system. It would surprise
me if Apple was not working on something as well but as I am not a developer
at the moment they would not provide me with any information. The best thing
to do may be to sit back and wait. If you're not the waiting type, read on ...
One thing should be clarified: I am not working on this as a BBN employee at
the moment and thus have little resources of my own to do anything but serve
as a clearinghouse of information and to test, define, and haggle on my own
time. Don't expect me to sit down and start writing anything just yet ....
I've used many different mail systems, from Berkeley's BSD mail to several
version of MH (one of which I am using now) to front ends to mail written for
Gosling's Emacs to some abomination on a TOPS-20 to CMU's Andrew Message
system. The latter was by far the most useful, which is not terribly
surprising as it ran under Andrew and made extensive use of the window system.
Unfortunately, it is also deeply tied to the entire Andrew environment as is
the MacMessages currently under development at CMU unless things have changed
drastically since I left.
The Macintosh obviously provides a window manager of sufficient power to
support an ellegant user interface. With a hard disk there is only one good
reason for the Mac not to be a mail client rather than just a interface (via a
terminal emulator if need be) into a mail system running on a timesharing
host. The one good reason that I'm aware of is that the Macintosh is
frequently not present to receive mail. The Mac on my desk is usually up and
running but what about the Mac at home? Which actually leads to a second good
reason: I've two Macs that I read mail from and if mail was delivered to one
then the mail would be unavailable from the other Mac. [RFC 993 (PCMAIL)
addresses these problems and is worth reading.]
These problems indicate a need for a mail server running on some central host.
I believe the majority of us operate in an environment that includes some UNIX
machine thus providing a possible common server machine. Yet I am aware of at
least two groups using mostly Macs and Lisp machines of various flavours who
would be unable to access a UNIX server and would need the ability for the Mac
to send a legal mail message to both an Internet site across the country and
to the Mac across the lab. I tend to fit into the latter group with the added
complication that my Mac at home isn't even sitting on a network. Perhaps I
just lose out on that situation but I suspect that many others have a Mac at
home and would appreciate the ability to compose, send, and receive mail at
home using a serial line. This would fit well into the server model but I do
not see a clean way to fit it into the model of a Mac as its own host.
The other obvious problem is how to reliably get the mail message from the
Mac, in either model, into the normal distribution system for the environment.
Once again, most of us are running TCP/IP but there are still exceptions to
this. CMU is using CUI/SNAP on a TCP/IP network, Dartmouth is using KSP on an
Appletalk network (Kevin will correct me if I am wrong again ....), PCMAIL
uses DMSP on top of USP (Unified Stream Protocol), Stanford Network Services'
Mac/MH uses SMTP and MHPOP on a TCP/IP network, and a UMich system uses MVP
(Mail View Protocol) on a TCP/IP network (I presume). A common system is going
to need a common mail protocol. Done correctly, the stream protocol can be
left up to the user. (From what I understand of PCMAIL it relies heavily on
features in USP.)
If a common system is to be developed then two things must happen: 1) We must
decide on a model or figure out some way to combine the two and b) given a
server model we must decide on a transport mechanism. Or on several of them.
Once you have the model and the transport done then you should be able to
customize your user interface to suit. If your low level routines provide the
ability to deliver a message to a specific address, to file a message in a
folder, to accept an incoming message, to maintain mailing lists, and a few
other basic services then you're most of the way there. I am *not* implying
that the user interface issue is simple, but that it is a distinct problem.
With the lower level services available you can drag an icon of your mail
message into a mailbox or pull down a menu and select "Deliver". Such
decisions are certain to start a religious war.
One specific idea that came up was the question of mail notification. It
would be desireable to have a task listening for a message indicating that new
mail arrived. This is a necessity if the Mac is to be a mail host, obviously.
If the mail is actually delivered to a server somewhere for collection when
the user so desires he still would like to know that it is there without
starting up a full mail session.
That is the lot of it for the moment. Please comment, submit ideas, et al.
I've nothing available for anyone to test and nothing for anyone to commit
development resources to. Development, I suspect, will be up to those
interested in having a major say in what such a system looks like. If
commerical products are satisfactory, then we're all set .... If this is
getting beyond the scope of info-appletalk we might think about setting up a
different mailing list for it. Does anyone mind seeing all this mail traffic
going around?
[Alex: Again, I think that making the problem too general may retard the
design. Most of us have UN*X boxes speaking TCP/IP, some of us have K-boxes or
Multigate boxes that act as bridges between Ethernet and LocalTalk. Perhaps
our mail application should be designed around these common factors first.
Then it can be adapted to other systems.]
-David Kovar
DKovar@BBN.COM
Date: Wed, 13 Apr 88 16:17:49 PDT
From: 98820000 <johnroc@ucscf.UCSC.EDU>
I saw your posting and was wondering what the responses were.
We will be trying to get something like that up and running from our Sun and
some VAXes here. We also would like to make it possible to access the
spelling checker and person locater we have as well.
John Rocchio
johnroc@ssyx.ucsc.edu
johnroc@ucscf.ucsc.edu
[Alex: If you want to add additional features such as you describe, you have
two courses of action, 1. provide the facility to log into a target machine.
2. perhaps use NFS (I'm just guessing here) to access the files you want from
a specialist application.]
Date: Fri, 15 Apr 88 12:58:35 MET DST
From: thschulz@ira.uka.de
Subject: Re: E-mail Mac/Mainframe
To: alex@comp.VUW.AC.NZ
Organization: University of Karlsruhe, W.-Germany
Yes , it is exactly whtat we need right now. A facility to read and post News
from the Macs and an interface to the mainframe mail systems.
I do not know of any existing system of that kind; at Karlsruhe University we
have two or three people who are almost motivated to do such a thing. For
mail we must write a server for the Unix-host. For the Macs we need TCP/IP
software and a nice interface. A protocol for News exists : NNTP, for mail we
can perhaps use SMTP or invent something similar to NNTP.
Problems are: 1) identification of the Mac-User and 2) security on the
AppleTalk because everybody can tap on AppleTalk and listen to passwords etc.
Please keep me informed on any progress you hear of.
Thanks, tom.
[Alex: we are not terribly worried about security issues, UUCP is also
unsecure, that does not prevent people from using it. To solve this problem we
need to look at a complete solution that makes a message I send to you from my
Mac in New Zealand (Aotearoa) to your Mac in Germany secure, every step of the
way. If that is not our goal, then we need not worry so much about security.]
Date: Thu, 14 Apr 88 13:20:00 PDT
Sorry I don't have anything useful to tell you (some Real Soon Nows, but...)
Date: 14 Apr 1988 1407-PST (Thursday)
From: Raman Khanna <khanna@jessica.stanford.EDU>
Subject: Re: E-mail Mac/Mainframe
At Stanford we have developed a mail system for Macs that uses regular Arpanet
mail. Incoming mail is stored in a Mail Box on a Unix machine and users can
retrieve it at their convenience. Outgoing mail is sent directly from
individual Macs using SMTP. We are currently working on a user manual for the
package. I expect that we will be able to start shipping the package in a
month or so. This package is available to any university (in US or abroad)
for free (We charge $100 to recover copying and distribution costs).
In case you are interested, please send a message to:
macip@jessica.stanford.edu
raman khanna
Networking and Communication Systems
Stanford University
[Alex: This system meets my requirements, except for incoming mail. I can't
see the difference in using this system and having Mac users log onto a
mainframe to receive and *send* their mail. The whole point of having a mail
system on the Mac is to avoid having the Mac users learn another user
interface.]
Date: Thu, 14 Apr 88 13:45:35 -0800
From: morgan@jessica.stanford.EDU
Subject: Mail system for Macs
Alex:
Here at Stanford, we are putting the finishing touches on a package called
Mac/MH, which might be capable of meeting your needs. Mac/MH allows a Mac to
retrieve mail from a Post Office server, using the MH/POP (Post Office
Protocol) that is supplied with the standard MH distribution from UC Irvine
(MH is a mail front end for Unix systems, if you're not familiar with it).
This is all designed to work on a LocalTalk connected to an Ethernet via a
Kinetics FastPath. It can also work on a Mac II directly on an Ethernet. The
POP server currently runs only on BSD-type Unix systems.
The Mac user has a mailbox account on the server (which is *not* a
regular login-able account), to which his/her correspondents direct
mail, using any of the Unix methods (we use IP/SMTP mostly here). The
Mac users fetches mail from the server, which shows up in an Inbox
folder. A display similar to view-by-name shows the messages in the
Inbox (or other folders) with an icon for read/not-read, etc.
For outgoing mail, the Mac user creates a message in the Mac/MH
application, which provides To:, Subject:, etc fields automatically.
Text files can be inserted. Outgoing mail is sent using SMTP, most
likely to a local host which can forward it to its destination.
Mac/MH doesn't do automatic notification, but it is MultiFinder aware,
so it could be left running continuously on a MultiFinder machine.
We currently license Mac/IP (which provides Telnet and FTP) to
Universities for $100 (binary only). Mac/MH, when released, will most
likely be distributed similarly.
If you're interested, wait about a month, then send an inquiry to
networking@jessica.Stanford.Edu
Cheers,
- RL "Bob" Morgan
Networking Systems
Stanford University
[Alex: I could live with this package. It only fails in not automatically
notifying the user of incoming mail.]
From: ech@spuxll.UUCP
Subject: Re: E-mail Mac/Mainframe
There is a little-known product family from AT&T called "Private Message
Exchange" (PMX, supposed to remind you of PBX) which may do what you want.
PMX-TERM is a curses-based unix-based screen interface to the mail system.
PMX-PC is an xmodem-based unix-side "Message server." On the back end, it
interfaces to rmail and /usr/mail/*; on the front end, it talks to:
Access I - a blue-clone based "User Agent." Nice windows, etc.
Access III - a Mac-based User Agent.
The interface presented by PMX-TERM, Access I, and Access III are as similar
as practical, a plus if you are operating a mixed environment like most folks.
The pmx-pc interface to the Access programs is a subset of the (also little
known) AT&T Mail common-carrier service (although that is likely to be of
limited interest to an Aussie!). PMX-PC and PMX-TERM have been ported to a
wide variety of Unix platforms -- I haven't a complete list handy, but
certainly PDP-11, Vax, 3B(1,5,20), Pyramid, Amdahl(UTS) are there.
I am not entirely disinterested here -- I am the author of Access III, and I'm
currently giving it an overhaul. Although asynch-based (not AppleTalk) both
Access products run in background (the new Access III, available 6/88, runs
happily in background under MultiFinder.
If you'ld like more details let me know.
=Ned Horvath=
[Alex: Yes I would like some more details, could you post them to the net so
that others who are interested may also be informed?]
Date: Thu, 14 Apr 88 17:59:53 PDT
From: ack@caldwr.UUCP
Subject: Re: E-mail Mac/Mainframe
I have often considered writing a Mac implementation of SMTP. I talked to CE
Software at Macworld SF a few months ago about the fact that they might want
to add SMTP support to their new mail product. They were not aware of what
SMTP was, but I gave them some pointers to info about it so maybe they will
add it.
In case you don't know what SMTP is, it is the protocol that sits on top of a
transport protocol (such as TCP/IP or X.25) to handle mail. Since you have a
Kinetics box and can spool LaserWriter output to lpr, I assume you have some
sort of TCP/IP. According to your map entry, your machine is a Pyramid
connected via X.25, so your mail can at least be delivered that way. If your
TCP/IP stuff does not support SMTP, you could implement the server under X.25,
but I have no idea how difficult it would be. If either of these is true, all
you would have to write is the server for the Mac side, since the server for
the UNIX side is built into sendmail or whatever daemon handles mail via X.25.
You will only have sendmail if you have Berkeley UNIX or something similar. If
you have a SysV system, you will probably have to go the X.25 route.
If you would like to write such a server using the TCP/IP implementation, you
might want to start with the NCSA Telnet source for the networking part, and
modify it to implement the SMTP protocol as specified in RFC 821. I don't know
where you would get sample code for X.25, but you could probably post on the
net and get some. It would also be a *very* good idea to make sure your
outgoing mail messages conform to RFC 822. If you need these RFC's, I would be
glad to send them.
If none of this makes any sense, please let me know what needs clarifying. If
this makes a lot of sense, let me know if you want to do it. If you do, I'm
sure there are a lot of organizations and universities that would want it.
Please let me know what you think of this idea.
David Ackerman
California Department of Water Resources caldwr!ack@ucdavis.edu (Internet)
"It's the water, and a lot more..." ...!ucbvax!ucdavis!caldwr!ack (UUCP)
The opinions expressed above are mine, not those of the State
of California or the California Department of Water Resources.
[Alex: This was extremely helpful. It allowed me to further define what I was
after. Which is a gateway that sits between sendmail and a Mac mail package
such as Inbox with the gateway perferably running on a mainframe.]
Date: Fri, 15 Apr 88 18:28:43 cdt
From: Farhad Xerxes Anklesaria <farhad@ux.acss.umn.EDU>
Subject: E-mail Mac/Mainframe
To: alex@comp.VUW.AC.NZ
Greetings Alex,
Read your posting on USENET. We have a similar system: Un*x boxes, K-boxes,
CAP. Starting work to build something like you are describing. We'll keep
you posted on how/what we're doing. If you find out anything interesting....
or a ready made solution, please drop us an electric line.
Thanx
Farhad Anklesaria fxa@berlin.acss.umn.edu
Microcomputer and Workstation Systems Group farhad@ux.acss.umn.edu
University of Minnesota farhad@vx.acss.umn.edu
Minneapolis, MN 55455 farhad@UMNACVX.BITNET
So that's all the information I've managed to acquire so far. I'm looking at
writing to THINK to find out whether it's feasible to develop a UN*X based
InBox server (although it appears that Stanford have already got there) in the
same manner as the Aufs UN*X server. Another option is to explore the new
QUICKMAIL release from CE Software. Does anyone know how to reach CE Software
via electronic means?
My thanks to all of you who responded
--
Alex Heatley: Computing Services Centre
Domain: alex@comp.vuw.ac.nz Victoria University of Wellington
Path: ...!uunet!vuwcomp!alex P.O Box 600, New Zealand
Trolls can often be found under bridges ... or in Computing Departments.