maas@JESSICA.STANFORD.EDU (andy maas) (05/04/89)
Billy Brackenridge <billy@venera.isi.edu> wrote: >The question of mail on a workstation has come up on the PC/IP and >InfoAppleTalk lists about how best do do mail on a workstation. > >Several years ago at ISI.EDU we experimented with POP based mail servers >on PCs. A few people still use the system, but it never caught on. > >I have been working at a company called IPT Inc. We make a product called >uShare which provides AFP based services on Unix machines. A Unix machine >appears as a File, Print and Mail server to Macintoshes. Our original >Macintosh mail server used a POP like protocol. > >I decided to build our mail system on top of the File Server protocol. >While we did our system on top of AFP, it could be done on top of NFS, or >Novell or any other file server protocol. > >A work station manipulates mail as files. When a user connects to his >server we have some aliased files that point to his Unix in basket and >Unix output mail queue. We have a Macintosh desk accessory that reads and >writes these files and an IBMPC program that does the same. > >Any Unix mail reading program written in C could be ported to the MAC or >PC under this kind of system. As the program is written in C and only >manipulates files you don't even need to be connected to your system. You >could download your input mail queue via Kermit take it home on your >floppy disk, answer your mail and Kermit back the responses to your >friendly Unix machine for delivery. > >I was around in the days when POP was invented. Macs and PCs still are >not robust enough to do real SMTP delivery (unless you forward everything >through a local mail server), however, had we reliable file servers in >1983 we never would have invented POP. It is an obsolete idea. I can't >see writing a POP based mail system for Macs and PCs in 1989. While POP might not be the best mail retrieval protocol, it does give you a standard way of retrieving mail from a mail server which is better than not having standard at all and no interoperability between different mail systems. POP also had gone several modification/improvement since it was first established. But the most important thing is that POP runs on IP network which give you wider access than mail system based on file server. There are many different file servers run on many different network protocols. Implementing in only one of them is not sufficient while doing for all of them will take some effort. They also do not operate interchangably. Another advantage of using POP is that POP client is available on both Macs/PCs and UNIX systems which allow users to access mail from either system. This let you access your mail in many different ways: 1. direct access from PC/MAC connected on local network. 2. direct serial line access using SLIP. 3. serial line connection to one of your UNIX host and use POP to do you mail. 4. telnet from any IP site to your UNIX host and again use POP to read mail (in case you don't bring your laptop with you). Since a machine running POP server can be assumed to have SMTP or similar kind. It is not necessary for the PC/Macs to do SMTP delivery. They can just forward it to the POP server. Until a better (and standard) way of doing mail from Mac/PC is available, POP seems to be the only solution. ::POP is already implemented on UNIX (client and server, public domain) and PC/Mac (client only). Andy Maas Stanford University
austins@GARNET.BERKELEY.EDU (Austin Shelton, 415/642-6158) (05/05/89)
I have to agree with Andy Maas' assessment of POP and his comments concerning the recent posting by Billy Brackenridge. I can understand that POP may not have been a smashing success some time ago. But perhaps this was due to inadequacies in the implementation. The value in POP lies in the fact that it is a network protocol that is independant of an underlying file structure. In other words, POP clients and servers can be implemented on a variety of architectures and (if true to the protocol) can communicate with one another irregardless of the platform. Some people have criticized POP because they are unhappy with the Rand POP server implementation. Since Rand mh 6.6 does not completely meet our needs, we are looking at developing our own POP server, more tightly coupled with existing BSD 4.3 features (e.g., use password file for authentication, access mail spool instead of separate spool area, etc.) Because this is a protocol-based approach to mail, we know we can continue using the Stanford MacMH program with our server, should we develop one. Furthermore, as MacTCP and TCPort become more widespread, I expect we will see alternate POP client implementations. Again, for those not completely satisfied with MacMH, alternative client interfaces can be developed based on POP that will communicate with the POP server(s). The point is that you really have to look at the advantages of a protocol-based approach to mail services independent from existing implementations. Austin Shelton Data Communication and Network Services University of California at Berkeley
mst@csun.edu (05/05/89)
In article <8905041700.AA13125@garnet.berkeley.edu> austins@GARNET.BERKELEY.EDU (Austin Shelton, 415/642-6158) writes: >Furthermore, as MacTCP and TCPort become more widespread, I expect we > >Austin Shelton I have been seeing MacTCP poping up for a while now, can someone out there explain what this software gives you? How about where it can be purchased? Also TCPort is also mentioned above, how about some info on this one? I have been reading this group for a while now, but when things like these two are mentioned I have notice a great big hole in the conversation. Any help is greatly appreciated. Mike Temkin ...!{sdcrdcf,hplabs,psivax,ttidca}!csun!mst mst@mx.csun.edu Cal. State U. Northridge, School of Engineering and Computer Science Voice phone: (818) 885-3919
veizades@apple.com (John Veizades) (05/06/89)
> I have been seeing MacTCP poping up for a while now, can someone out there > explain what this software gives you? How about where it can be purchased? Well here is what I hope is the definitive answer on MacTCP. MacTCP is available through: Apple Software Licensing 20525 Mariani Ave. MS 38-I Cupertino CA 95014 MacTCP is a driver based implementation of the TCP/IP protocol suite. It is designed to be a developer based product giving interfaces to TCP, UDP and the Domain Name Resolver. MacTCP also provides a configuration utility that allows for the configuration TCP/IP based information (IP address, subnet mask, gateway and so forth). There are single user licenses available through APDA at $100. The package comes with both programmer's and network administrators manuals. Some brief technical information on MacTCP: - It supports all the standard string of protocol acronyms BootP, RIP, RARP, KIP, DNS, Subneting, Van Jacobson congestion control etc. - Memory to memory TCP transfers at about 3.2 MBits/sec over ethernet between to MacIIs. There are several packages that are available for use with MacTCP. - Ungermann Bass will have user interfaces to FTP, Telnet and Mail available shortly. - Intercon has a commercialized version of NCSA Telnet with all kinds of new features. - NCSA Telnet has been ported to use the MacTCP driver and is available on zaphod.ncsa.uiuc.edu (128.174.20.50) - Stanford University has ported SU Mac/IP and their mail package to use the MacTCP driver and should be available from them shortly. - A network news reader should be available through APDA shortly. It is Hypercard based and will include XCMDS for MacTCP (I am using this stack to read the news group and to send this message). - And of course there should be many more applications be announced in the coming months that will use the MacTCP driver. If you have more questions I will be speaking at the Apple Spring Developers Conference (Monday afternoon) on MacTCP. John Veizades Chief engineer MacTCP
GD.WHY@STANFORD.BITNET ("Bill Yundt") (05/07/89)
REPLY TO 05/05/89 03:09 FROM BILLY@VENERA.ISI.EDU "Billy Brackenridge": Mail
for Mac and PC Workstations
In article <CMM.0.88.610155538.billy@venera.isi.edu>, Billy
Brackenridge says:
Several years ago at ISI.EDU we experimented with
POP based mail servers on PCs. A few people still
use the system, but it never caught on.
We at Stanford have been trying it with little success
too...only have about 1,000 users or so.
....working at a company called IPT Inc. We make
a product called uShare which provides AFP based
services on Unix machines. .............I decided
to build our mail system on top of the File Server
protocol.
I can understand basing a mail system on a shared file
system if you happen to have one and use it everywhere.
Unfortunately, many of our Mac users don't have
file servers. I am a little confused, though, by the notion
of building a mail system on top of the server "protocol".
That seems to be the opposite of the notion embodied
in international standards which try to separate the
user and transfer agents and keep mail protocols
independent of file architectures. Mail is, after all,
a message requiring transport, not just a file requiring
indexing and access on a storage medium.
.......you don't even need to be connected to your
system. You could download your input mail queue
via Kermit take it home on your floppy disk,
answer your mail and Kermit back the responses
That works with a POP server too...except the canonical
technique is to transfer incoming mail over the network
at high speed while in the office and take it home to
work on it than dump the outbasket back on the net the
next day .... or use SLIP to dial in from home .... it's
even slower than Kermit!!!
I was around in the days when POP was invented too...long
before, actually, and I don't think it is the ideal solution
either....but it is not nearly so unreasonable in 1989 as
Billy makes it out to be. After all, we load it from a
file server. They are handy to keep programs on but I
see no reason to generate more network I/O than I need
to read the mail once to my own machine.....which is what
POP does!
Cheers all....Bill Y.
To: PCIP@TWG.COM, INFO-APPLETALK@ANDREW.CMU.EDU