jln@casbah.acns.nwu.edu (John Norstad) (02/09/91)
At Northwestern University, we currently support two different mail systems for the Mac, QuickMail and Eudora. I've worked very extensively with both of them for a long time now, and one of my main jobs in our networking group at Academic Computing and Network Services (ACNS) is supporting both of them for use throughout the NU community. I have come to the conclusion that, in our environment, in most cases Eudora and POP clients in general are better than QuickMail and commercial local-area mail programs in general. I would like to present my arguments in some detail here. Although I know very little about IBM PCs, from what I've read and heard I think that many of my arguments apply to the PC world as well. This is the first paragraph of a very long (26K) paper I wrote last night and posted to one of our local Northwestern newsgroups. The paper is of general interest, but I felt it was much too big to post worldwide. If you'd like a copy, you can get it via anonymous FTP to ftp.acns.nwu.edu [129.105.113.52] in the file pub/jlnstuff/desktop-mail. If you can't FTP, send me a note and I'll mail you a copy. John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
sanders@parc.xerox.com (Rex Sanders) (02/10/91)
John, Thanks for writing your paper. You asked for a public discussion of issues raised. In spite of your disclaimer about remote mail issues, you write: > Academics need to be able to access their mail from many different places > - at the office, at home, from other universities, from conferences, etc. > This is very easy with the POP clients, because the user's mailbox resides > on an Internet host. The host is reachable from anywhere on the Internet. > If the user has access to a networked Mac or PC at the remote location, > he can even take a copy of his POP client software with him and use it > from half-way around the world! If necessary, he can also telnet to the > UNIX host and use the UNIX mail programs. Unfortunately, the POP client/server model meets only half the need for remote mail access. A Very Important Feature to many users is accessing *old* mail remotely. The POP model is basically "download from mainframe and delete". With Eudora, you can leave ALL your old unsorted mail piling up forever on the POP host. You will soon be visited by a system administrator threatening bodily harm! If your old mail is stored on your Mac (or PC or whatever), you must remember to back up your files. Honestly now, when was the last time YOU backed up your hard disk? How about the average user you support? If your old mail stayed on the server, the server administrator could back up the files regularly. The IMAP protocol, from what I understand, solves these problems. The server is manipulated with remote commands to read, delete, store, search, and retrieve mail. Your old mail, in folders, is stored on the server, and may be retrieved remotely as John describes above. Your old mail is backed up regularly, etc. IMAP servers are available for Unix and other hosts; IMAP clients are available for Macs, PCs, and Unix workstations. Unfortunately, the Mac IMAP client I've tried is yucky, especially compared to Eudora. If only Steve had used IMAP instead... Don't get me wrong - I love Eudora. Eudora/POP just doesn't solve some important problems. -- Rex sanders.parc@xerox.com
mst@ms.secs.csun.edu (Mike Temkin) (02/10/91)
In article <1991Feb10.022029.105@parc.xerox.com> sanders@parc.xerox.com (Rex Sanders) writes: >Unfortunately, the POP client/server model meets only half the need for >remote mail access. A Very Important Feature to many users is >accessing *old* mail remotely. The POP model is basically "download >from mainframe and delete". With Eudora, you can leave ALL your old >unsorted mail piling up forever on the POP host. You will soon be >visited by a system administrator threatening bodily harm! > >The IMAP protocol, from what I understand, solves these problems. The >server is manipulated with remote commands to read, delete, store, >search, and retrieve mail. Your old mail, in folders, is stored on the >server, and may be retrieved remotely as John describes above. Your >old mail is backed up regularly, etc. IMAP servers are available for Unix >and other hosts; IMAP clients are available for Macs, PCs, and Unix >workstations. >-- Rex Okay Rex, I fail to see the difference between keeping your mail on a POP host and keeping it on an IMAP host. Both mean that the mail will be taking up disk space somewhere (unless you know something the rest of us don't). There is nothing special about Eudora in regards to the "keep mail on server". Unless a DELE command is specifically sent to the POP server, the mail will remain. Above you state that it "is basically "download from mainframe and delete" this is clearly incorrect. The fault for this is in the client, not the server. You also point out that IMAP is available on platforms other than UNIX, well so is POP. poper is available for the Mac and I am sure there are or will be POP servers for the PC. POP is a viable alternative in a multi-platform environment. Mike. -- Mike Temkin mst@csun.edu Cal. State U. Northridge, School of Engineering and Computer Science Voice phone: (818) 885-3919
sanders@parc.xerox.com (Rex Sanders) (02/10/91)
In article <1991Feb10.033212.1320@csun.edu> mst@secs.csun.edu (Mike Temkin) writes: >Okay Rex, I fail to see the difference between keeping your mail on a POP >host and keeping it on an IMAP host. Both mean that the mail will be taking >up disk space somewhere (unless you know something the rest of us don't). - With Eudora/POP, *every* piece of mail you ever received is stored in cronological order in one file on the server (if you don't delete ALL of it). Each time a POP client requests new mail, a serial search is done (in current implementations), meaning longer response times as you receive more mail. - With IMAP, you sort your mountain of incoming mail into different categories, and *throw away* the messages you no longer care about. Only the mail you want to keep is stored on the server, separately from your incoming mail. I get more than 100 mail messages a day, about 5,000 kilobytes of mail a week. I save about 170 kilobytes a week. I know many other people with similar or larger mail volumes. >Unless a DELE command is specifically sent to the POP server, the mail will >remain. Above you state that it "is basically "download from mainframe and >delete" this is clearly incorrect. The fault for this is in the client, >not the server. The POP *server* has no selective delete, save, search, and retrieve functions. Eudora can do all of those, *on your Mac's local hard disk*. You cannot realistically expect your mail server to keep every piece of mail you ever received. With Eudora, you can see your old mail only by deleting it from the server. >You also point out that IMAP is available on platforms other than UNIX, >well so is POP. I only meant to point out IMAP's availability, not imply that POP wasn't widely available. -- Rex sanders.parc@xerox.com
jln@casbah.acns.nwu.edu (John Norstad) (02/11/91)
In article <1991Feb10.022029.105@parc.xerox.com> sanders@parc.xerox.com (Rex Sanders) writes: ... lots of interesting stuff about leaving mail on servers, POP vs. IMAP, etc. I agree. > Don't get me wrong - I love Eudora. Eudora/POP just doesn't solve some > important problems. Yes, you're right. But it's much, much better than QuickMail! As another example, It would be neat to see Eudora and the POP protocols extended so that Mac users could access the mail forwarding and "vacation" facilities without having to log on to the UNIX host. John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/12/91)
In article <1991Feb10.022029.105@parc.xerox.com> sanders@parc.xerox.com (Rex Sanders) writes: >With Eudora, you can leave ALL your old >unsorted mail piling up forever on the POP host. You will soon be >visited by a system administrator threatening bodily harm! >If your old mail stayed on the server, the server administrator could >back up the files regularly. And if you could only have your cake, and eat it too, then... >The IMAP protocol, from what I understand, solves these problems. The >server is manipulated with remote commands to read, delete, store, >search, and retrieve mail. IMAP has a problem of its own: IMAP2 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more fundamental manner, reflecting the differing architectures of MM-D and PCMAIL. PCMAIL is either an online ("interactive mode"), or offline ("batch mode") system. MM-D is primarily an online system in which real-time and simultaneous mail access were considered important. Translated from RFC-ese, this means that if your network is down, your old mail is UNAVAILABLE. It also means that users with dialups must tie up their phone lines to use old mail. It also means that users with slow connections must wait for messages they want to read (old ones) to be downloaded again. In other words, you only use IMAP on a fast, reliable Internet connection. The other protocol referred to (PCMAIL) is hard to implement, but is the One True Way (IMHO). Mail stays on the central server, but is cached (as disk permits) on any number of 'client' systems. These systems periodically 'sync' themselves with the server, so that you get a consistent view of your mail from anyplace you read it. Nifty, nifty, nifty. If I had my way, I'd be teaching Eudora PCMAIL; unfortunately, the people who sign my paycheck feel differently. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/12/91)
In article <3391@casbah.acns.nwu.edu> jln@casbah.acns.nwu.edu (John Norstad) writes: >As another example, It would be neat to see Eudora and the POP protocols >extended so that Mac users could access the mail forwarding and "vacation" >facilities without having to log on to the UNIX host. One of the departments here has an ongoing project in AI-assisted mail. What John wants would be a trivial example of what they do. We are considering a joint project to bring their "Mail Assistant" stuff into (a version of) Eudora. I dunno if it will fly, but it may be interesting if it does. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
mxmora@sri-unix.SRI.COM (Matt Mora) (02/12/91)
In article <1991Feb10.022029.105@parc.xerox.com> sanders@parc.xerox.com (Rex Sanders) writes: >Unfortunately, the Mac IMAP client I've tried is yucky, especially >compared to Eudora. If only Steve had used IMAP instead... > >Don't get me wrong - I love Eudora. Eudora/POP just doesn't solve some >important problems. > >-- Rex I have to agree. I love Eudora but I wish it had the features you mentioned. I eagerly await the next version with these features. -- ___________________________________________________________ Matthew Mora | my Mac Matt_Mora@QM.SRI.COM SRI International | my SUN mxmora@unix.sri.com ___________________________________________________________
bin@primate.wisc.edu (Brain in Neutral) (02/12/91)
From article <1991Feb11.175443.7553@ux1.cso.uiuc.edu>, by dorner@pequod.cso.uiuc.edu (Steve Dorner): > IMAP has a problem of its own: > > IMAP2 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more > fundamental manner, reflecting the differing architectures of MM-D > and PCMAIL. PCMAIL is either an online ("interactive mode"), or > offline ("batch mode") system. MM-D is primarily an online system in > which real-time and simultaneous mail access were considered > important. I don't know if it solves any of the problems being discussed in this thread, but a new RFC for IMAP*3* has come out: |A new Request for Comments is now available from the Network Information |Center in the online library at NIC.DDN.MIL. | | RFC 1203: | | Title: Interactive Mail Access Protocol - Version 3 | Author: J. Rice | Mailbox: RICE@SUMEX-AIM.STANFORD.EDU | Pages: 49 | Characters: 123,325 | Obsoletes: RFC 1064 | | pathname: RFC:RFC1203.TXT | | |This RFC suggests a method for workstations to access mail dynamically |from a mailbox server ("repository"). This RFC specifies a standard |for the SUMEX-AIM community and an Experimental Protocol for the |Internet community. Discussion and suggestions for improvement are |requested. Please refer to the current edition of the "IAB Official |Protocol Standards" for the standardization state and status of this |protocol. Distribution of this memo is unlimited. | |RFCs can be obtained via FTP from NIC.DDN.MIL, with the pathname |RFC:RFCnnnn.TXT (where "nnnn" refers to the number of the RFC). Login |with FTP, username "anonymous" and password "guest". | |The NIC also provides an automatic mail service for those sites which |cannot use FTP. Address the request to SERVICE@NIC.DDN.MIL and in the |subject field of the message indicate the RFC number, as in "Subject: |RFC nnnn". | |RFCs can also be obtained via FTP from NIS.NSF.NET. Using FTP, login |with username "anonymous" and password "guest"; then connect to the RFC |directory ("cd RFC"). The file name is of the form RFCnnnn.TXT-1 |(where "nnnn" refers to the number of the RFC). | |The NIS also provides an automatic mail service for those sites which |cannot use FTP. Address the request to NIS-INFO@NIS.NSF.NET and leave |the subject field of the message blank. The first line of the text of |the message must be "SEND RFCnnnn.TXT-1", where nnnn is replaced by |the RFC number. | |Requests for special distribution should be addressed to either the |author of the RFC in question, or to NIC@NIC.DDN.MIL. Unless |specifically noted otherwise on the RFC itself, all RFCs are for |unlimited distribution. | |Submissions for Requests for Comments should be sent to |POSTEL@ISI.EDU. Please consult RFC 1111, "Instructions to RFC |Authors", for further information. | |Requests to be added to or deleted from this distribution list should |be sent to RFC-REQUEST@NIC.DDN.MIL. | | |Joyce K. Reynolds |USC/Information Sciences Institute Paul DuBois Dubois@primate.wisc.edu
jln@casbah.acns.nwu.edu (John Norstad) (02/13/91)
In article <1991Feb11.180742.10056@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: > In article <3391@casbah.acns.nwu.edu> jln@casbah.acns.nwu.edu (John Norstad) writes: > >As another example, It would be neat to see Eudora and the POP protocols > >extended so that Mac users could access the mail forwarding and "vacation" > >facilities without having to log on to the UNIX host. > > One of the departments here has an ongoing project in AI-assisted mail. > What John wants would be a trivial example of what they do. > > We are considering a joint project to bring their "Mail Assistant" stuff > into (a version of) Eudora. I dunno if it will fly, but it may be > interesting if it does. Wonderful! This stuff just keeps getting better and better. A third thing I forgot to mention is changing the account password - this is another thing that the user has to actually log on to the UNIX host to do. I know it's no big deal, but the whole point of this stuff (from my point of view) is to avoid having to log on to the host at all. Someone wrote me a note today and asked how I thought Apple's plans to support some kind of desktop mail as a built-in system feature affected this whole discussion. God, I don't know! But it should be interesting. John Norstad Academic Computing and Network Services Northwestern University jln@casbah.acns.nwu.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (02/13/91)
In article <3452@casbah.acns.nwu.edu> jln@casbah.acns.nwu.edu (John Norstad) writes: >Someone wrote me a note today and asked how I thought Apple's plans to >support some kind of desktop mail as a built-in system feature affected >this whole discussion. God, I don't know! But it should be interesting. Before I wrote Eudora, the director of my department asked Apple to give us an idea of what their plans were in this direction. Apple sent some people who listened to what we had to say, and told us they were going to release MacTCP. Can you say "big help"? Anytime I suggest enhancements to Apple software (eg, TCP Tool or SLIP) someone from Apple protests loudly that Apple doesn't want to cut into "third-party markets". So my *guess* is that Apple may write a mail protocol for AppleTalk, or an inter-application communication specification for sending mail, but that they won't come out with their own mail application. Of course, there's always the possibility that the people I've talked to at Apple are mistaken or lying about Apple's reluctance to compete with third parties. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
bin@primate.wisc.edu (Brain in Neutral) (02/14/91)
From article <3452@casbah.acns.nwu.edu>, by jln@casbah.acns.nwu.edu (John Norstad): > Wonderful! This stuff just keeps getting better and better. A third > thing I forgot to mention is changing the account password - this is > another thing that the user has to actually log on to the UNIX host to do. > I know it's no big deal, but the whole point of this stuff (from my point > of view) is to avoid having to log on to the host at all. 1) The amount of coding necessary to support this operation may be all out of proportion to the frequency with which one might want to perform it. How often do you change your password? (Yes, I know you should do it every now and then, but I would be surprised if many of us consider "now and then" to mean daily, or even weekly.) 2) Changing passwords isn't a mailer issue anyway (in my opinion), it's a system administration issue. I would prefer that Eudora not be a kitchen sink. -- Paul DuBois dubois@Primate.wisc.edu