dkovar@VAX.BBN.COM (04/22/88)
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? -David Kovar DKovar@BBN.COM