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. First I should briefly review how the two kinds of mail programs work for people who might not be aware of the differences. Both the better commercial mail programs and the better POP client mail programs are fully featured mail programs with all of the customary features: address books, distribution lists, mail folders, replying to and forwarding mail, carbon and blind carbon copies, printing and saving messages, mail logs, attached files, notification of new mail, and so on. In both cases, the user reads and writes mail directly on his workstation using familiar tools. The user does not have to log on to a UNIX host or any other system to deal with his mail. This is the primary benefit of these mail systems, especially for people who do not know or want to learn UNIX or any other timesharing system. Even PC and Mac users who are experts on UNIX, when given reasonable alternatives, usually prefer to deal with mail and other Internet services directly on their PC or Mac desktop. QuickMail, Microsoft Mail, ccMail, InBox and other similar commercial local-area mail programs work on Macs or PCs that have been connected together into a local-area network. One of the Macs or PCs on the network acts as a mail server and runs special server software. In some cases a dedicated Mac or PC is required for the server, while in other cases a user Mac or PC can be used. User's mailboxes actually reside on the server, but the client software on each Mac or PC presents the illusion that mail is being delivered directly to the user's personal workstation. In many cases (but not all), additional commercial software can be installed on the server to connect the mail system to the Internet. These are called "mail gateways." For example, here at NU we use two copies of StarNine's Mail*Link QM/Internet gateway (also known as GatorMail-Q) to serve ten different workgroups on campus using seven different QuickMail servers. At the McCormick Shool of Engineering Dean's office they are currently using a similar ccMail/Internet gateway on their Novell PC network. Eudora, TechMail, POPMail, and other similar "POP clients" present the same illusion to the user, but in this case the user's mailbox actually resides on a UNIX host on the IP Internet. The UNIX host must be running a special "SMTP" server (simple mail transfer protocol) to handle outgoing Internet mail, and a special "POP" server (post office protocol) to handle incoming Internet mail. UNIX systems come with SMTP servers as part of the standard system, while the POP server must be installed specially. The POP servers are very small and simple programs which are very easy to install. At NU we have serveral POP servers installed on several different UNIX boxes, and several departments use POP clients. In both cases, for Internet mail to work, the local-area network must be connected to the IP Internet. For LocalTalk Mac networks this means using an AppleTalk/IP gateway like a Shiva FastPath or Cayman GatorBox. For EtherTalk Mac networks a protocol gateway is not required as long as the Ethernet is also an IP network connected to the Internet. (Dial-up connections are sometimes possible, and dial-up access to Internet mail and other services is a major hot issue, but I'm intentionally ignoring this today as being beyond the scope of these notes. Eudora has a dial-up feature which is supposed to work with Cisco terminal servers like our "Elvex" server at NU, but I haven't worked with this feature yet. It requires special software from Apple which we don't have yet. I hope to investigate this very soon, next week I hope, and I'll report on the results then.) For the commercial local-area programs, the server workstation must be capable of communicating with the IP Internet via the TCP/IP protocols. For the POP clients, each personal workstation must be capable of communicating via TCP/IP. The commercial local-area mail programs work wonderfully in a small homogenous workgroup where the primary use of electronic mail is to communicate with coworkers within the workgroup. The programs were designed for this purpose, and they serve that purpose very well. There's no doubt that the commercial programs are nicer than the POP clients if that's all that you want to do. In the Mac world, the commercial user interfaces are often designed with generous use of icons and other shortcuts to accomplish simple goals, while the POP clients typically rely more heavily on the use of menu commands and command-key equivalents. Novices usually find the commercial programs to be a bit friendlier and easier to learn, although the POP clients are not difficult at all, and the very best POP clients like Eudora are very elegant and easy to learn and use. Commercial programs also sometimes have extra frills. For example, QuickMail has an online-conferencing facility, a primitive bulletin board, an "unsend" feature, and voice-mail capabilities (largely unused to date at NU because few Mac users have microphones). These kinds of extras are usually not including in POP clients, primarily because the Internet mail system does not support the services (although several of them are available via other protocols and programs). In major universities like Northwestern, however, even within a single workgroup (department or office), we often encounter very heterogeneous environments with mixtures of Macs, PCs, and/or UNIX workstations. In addition, in most cases the mail users want to be able to easily communicate not only with their colleagues within the workgroup, but also with other people within their university and at other institutions around the world. In fact, for researchers, communication with colleagues with similar research interests around the world is often a much more important and more frequent activity than is communication within the department. Even administrators, who spend the majority of their time communicating with each other, still need to communicate with other adminstrators on campus, many of whom will typically be in different workgroups and using different kinds of computers and mail systems. The commercial mail programs have many drawbacks in this more complex heterogeneous and world-wide Internet environment. Many of the commercial mail programs do indeed have supposedly compatible versions for both the Mac and the PC, but in fact one of the versions is almost always greatly inferior to the other one. Few of them have UNIX versions, and when they do, more often than not, the UNIX hackers just snear at them and refuse to use them, and rightly so, given the typical excellent UNIX mail facilities they're already using (like ELM.) For example, QuickMail was originally designed for the Mac, and it works very well on Macs. All of the major Mac magazine and network reviews consistently rate it as the best Mac mail program in head-to-head comparisons with its competitors, with Microsoft Mail usually coming in a not-too-distant second, and with ccMail and InBox always far behind. CE Software recently released a PC version which is so poorly designed that it is horrible to use and very, very slow even when it doesn't crash, which it does often. We have had very bad experiences with the PC version of QuickMail. As another example, ccMail is one the most popular commercial local-area mail programs for the PC, and several departments at NU use it, but I've heard from usually reliable sources that the Mac version is very bad, much inferior to QuickMail. The major Mac magazine and network reviewers agree with this assessment. The commercial local-area mail programs were not designed as Internet mail programs. In order to send a message to an Internet recipient, the user must send the message to the special Internet gateway. In general, the gateway appears to the local-area mail system as a separate "mail center" or "post office" and it appears to the IP Internet as an SMTP peer host. The gateway converts messages back and forth between the formats used by the local-area system and the Internet. This interposition of a gateway between the mail user and the Internet mail system invariably makes Internet mail a second-class facility on such systems. Addressing mail to an Internet recipient is usually much more clumsy than addressing mail to a local recipient, and many Internet conventions and features common on UNIX-based mail systems are not available to the user. For example, with QuickMail, the user must wade through several special nested dialogs and type lots of irrelevent information in order to address an Internet message, although for frequent correspondents it is possible to add such an address to a private address book and subsequently use it as if the recipient were on the local system. To continue the example, with QuickMail, there's no way to automatically encode attached Mac files in the standard Internet "BinHex" format, there's no way to automatically append a signature to each outgoing message (a ".sig" file), there's no way to quote original message text in a reply or forwarded message using the ">" Internet convention, there's no way to easily correct and resend messages which have bounced because of a bad address, there's no way to import and export address lists in UNIX ".alias" or any other format, there's no way to easily prepare "canned" messages to make it easier to distribute Mac software or other files via mail, and there's no way to easily perform mailbox-wide text searches. With Eudora, on the other hand, message addressing is extremely straightforward - you just type the usual user@domain address in the To, Cc, or Bcc field in the mail window. In addition, all the features mentioned above are built-in to the program and are very easy to use or are even done for you automatically. This is because Eudora was designed from the outset as an Internet mail program. As an even worse example than QuickMail, the current version of ccMail doesn't even permit users to create their own address books - they all must share a common address book maintained by the server administrator! This is a very good example of a scheme which was designed for, and works adequately in, a small isolated workgroup, but is clearly unacceptable in the Internet environment. I've also heard that a single improperly addressed incoming Internet message causes the ccMail gateway to stop working! It's obvious that this system could never be used in a serious campus-wide production environment without major improvements. (This information about ccMail is all second-hand and may be inaccurate.) The commercial gateway packages have only recently appeared on the market, and in some cases they aren't even available yet. None of them are really mature or robust products. They contain many errors and design flaws and require constant monitoring and attention by network administrators. Internet mail, POP servers, and POP clients, on the other hand, are much more mature and robust. This is largely because they are much simpler systems which involve far fewer software and hardware components between the user and the Internet. For example, we have a number of problems with our campus QuickMail system which require constant attention. Servers sometimes crash. Servers sometimes mysteriously stop sending each other messages (the Store&Forward mailcenter backs up). The QM/Internet gateway software sometimes stops sending outgoing Internet mail for no apparent reason (we suspect a MacTCP domain name resolver problem). If a server goes down or becomes unreachable and the gateway server is subsequently restarted (usually for one of the reasons above) before the other server becomes reachable again, all incoming Internet mail destined for the unreachable server is immediately bounced back to the sender rather than being kept in the Store&Forward mailcenter as usual. As more and more servers are serviced by our primary central gateway machine, this becomes more and more of a problem, since the probability that at least one of them is unreachable increases. When the network becomes busy we sometimes experience problems connecting to the server from a client workstation, especially if there's an intervening AppleTalk router, and connections sometimes die unexpectedly. Adjusting the QM timeout delay parameters hasn't helped much. This is just a partial list of problems we've encountered. The system works more than well enough so that it is usable, and many people do use it and rely on it, and according to the network and trade press reviews this is actually one of the best systems of its kind on the market, but it is still very delicate and requires constant monitoring and special attention at least several times per week. I have heard similar reports from other users of QuickMail and other major commercial systems with Internet gateways. 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. Accessing the commercial local-area mail systems from remote locations is often impossible. If it is possible, it's often clumsy. For example, we do have a modem connected to our ACNS QuickMail server, but it can only be used by ACNS staff and only one person can use it at a time. The remote interface for access from both Macs and non-Macs is not nearly as nice as QuickMail itself. It's impossible to Telnet into QuickMail to read your mail. Internet mail users are also accustomed to features such as automatically forwarding mail from one account to another and sending back automatic "vacation" replies when they're out of town. Most commercial local-area mail systems don't support these features, although sometimes these features are available via separate software products. For example, in the case of QuickMail, there's a product from Information Electronics called "QM Concierge" which will do this, but it costs an extra $200 per server, and it has problems with things like replies to distribution list messages, etc. With POP clients, on the other hand, these features are automatically available as part of the underlying UNIX mail system. For example, although Eudora does not directly support these features (maybe it will some day, but it doesn't now), Eudora users can still access them by logging on to the UNIX host and using the UNIX facilities. For example, a Eudora user can log on to the UNIX host and create a ".forward" file to have his mail forwarded to some other address. With the commercial systems, each separate workgroup normally has it's own mail server machine. Usually it's the department's responsibility to purchase the necessary hardware resources and monitor and maintain the server. With POP clients, a centrally funded, monitored, and maintained UNIX host can be used as the server. For example, at NU we use our SUN Sparc 475 server "casbah" as a central POP server. Any university student, staff member, or faculty member can get a free mail account on casbah. Some departments with existing UNIX boxes choose to run their own POP servers instead, but they don't have to. At NU we have some departments with only a few user Macs and no spare Mac which can be used as a gateway machine. These Macs are on IP Ethernets which don't have AppleTalk connectivity to the rest of the campus (no FastPath or GatorBox), so they can't use our central gateway machine. Using QuickMail in these situations is impossible without spending lots of money, but using Eudora presents no problems and costs nothing. Industrial Engineering and Management Science and Neurobiology and Physiology are two examples of departments where we have used Eudora for this reason. POP clients are also more flexible than commercial local-area mail programs. They are much more easily tailored to specific needs. For example, in one department there is a person who wants his coworkers within the department to be able to send him electronic mail directly, but he wants all mail from outside the department to go automatically to his assistant. This is not possible with QuickMail, but with Eudora it would be quite easy to write a special custom "mail filter" on the UNIX host which would do just what he wants. The commercial mail programs are just that - commercial, and that means they cost real money. Some of them are quite expensive, while others are more reasonable. For example, QuickMail, one of the more reasonable ones, costs about $30 per user, and we got a very good deal on our unrestricted site license for the QM/Internet gateway (we got lucky and bought it quite a long time ago directly from StarNine before they made a deal with Cayman to market it as GatorMail-Q - it would cost much, much more today from Cayman). POP servers and POP clients, on the other hand, are almost always free (although there are commercial ones for the Mac, I'm not familiar with any of them). The better POP clients come with good machine-readable user documentation. For example, for Eudora a technical writer has prepared both an excellent short tutorial document and a complete reference manual. The commercial mail programs come with even fancier printed manuals, but they aren't machine readable, and in some cases you have to pay extra for additional user copies. With QuickMail, for example, we are making do with only one copy of the user manual per department, and we have only one copy of the administrator's manual for the whole University! With Eudora each user can have his own manual, and there's no need for an administrator's manual since there's no administrator. QuickMail is licensed software. We have been buying copies directly from CE Software in batches of 100. We charge departments by the copy to recover our licensing costs. Departments have to come to us to get copies because we are not permitted to make it available for distribution on a file server. We are supposed to keep careful track of how many copies have been installed, but in practice this has proved to be impossible, and we actually only have a rough estimate of this number. All of this involves lots of record keeping, paperwork, and walking around campus. With Eudora we just put a copy on our Plato file server along with the manuals and let people take copies themselves. No charges, no paperwork, no wasted time, and no fuss. When a new department wants to get QuickMail, we have to meet with them to discusss what machine they want to use as the server and we have to help them install the server software. When updated versions of the software become available, they have to be laboriously redistributed and reinstalled in each department all over again. With Eudora, departments don't need to set up a server - each user just gets a copy of the workstation software and manuals from Plato and installs and begins using it himself. New versions are distributed the same way. It's much less bother and effort for everybody concerned. You might be surprised to learn that the better free POP software is often much better supported than is the commercial software. Even though Northwestern has very close special relationships with both CE Software and StarNine, and we have been beta testers of both their products, we still have to wait many months in some cases and forever in most cases before errors are fixed and other concerns are addressed. With Eudora, on the other hand, I have actually sent email complaints to the author, Steve Dorner, and received fixed versions within a few hours! This is my best experience, of course, and your mileage may vary, and Steve has announced that he's moving on to other projects now, but it's still remarkable, and completely unheard of in the commercial world. Source code is available for many of the POP clients (including Eudora) and all of the POP servers, but it's never available for the commercial products. Until recently we had no central public UNIX service at Northwestern, and we were therefore unable to provide POP service to the general university community. POP clients were only used internally at ACNS and in a few other departments with their own UNIX machines, most notably at the Institute for Learning Sciences. Now that we have casbah we can provide this service to the general university community. This lack of a public UNIX service is one of the reasons that we invested so heavily in QuickMail in the past. This reason for using and promoting QuickMail no longer exists. I do not propose that we abandon our current QuickMail users or discontinue support or availability of the product, but I do propose that we encourage the use of Eudora in the future and that we discourage the use of QuickMail. Due to my ignorance, I am not prepared to make the same strong statement with regard to PCs, but I suggest that a similar policy deserves careful and fair consideration. Eudora is a mature, reliable, efficient, well-designed program. As is often the case, the quality of this program is not only just as good as the quality of the commercial alternatives, it is in fact better. It infrequently crashes on my Mac, but both Steve and I suspect that the cause is an error in MacTCP, not Eudora. It is certainly much, much more robust overall than the QuickMail system. Again, I am quite ignorant in the MS-DOS world, but I know that there are a variety of PC POP clients available. Bill Kath of Applied Math is a PC expert and he has long had an interest in POP clients. He tells me that the newest release of the University of Minnesota's POPMail server and client system for MS-DOS is quite nice, and that Rob Kurtz of Industrial Engineering and Management Science has installed it in that department and they are making successful use of it. I feel that investigating PC POP clients within our ACNS networking group and supporting and promoting their use on campus like I do with Eudora for the Mac should be one of our highest priorities. Mail systems are notoriously finicky and labor-intensive. Nobody installs an electronic mail system and just forgets about it and lets it run on its own. They always have problems and they need lots of baby-sitting. I spend a great deal of my time solving problems with our campus QuickMail system, and I know that my UNIX counterparts in our networking group also spend a large portion of their time solving various mail problems on their UNIX systems. One major advantage of POP clients for network managers like me is that they use the existing UNIX mail infrastructure, and thus there's only one large mail mess to maintain rather than two (or three or four if, as is often the case, there are several mail systems from different vendors on campus). Given that we are in the typical situation where our networking group is very overworked and understaffed, reducing the workload for our group is a major consideration. In summary, I have come to the conclusion that commercial local-area mail systems are inferior to POP clients in environments at large universities like Northwestern. For heterogeneous environments and for significant use of Internet mail, POP clients are clearly superior. The only major obstacles are that you do need a campus IP internet in place, and you do need significant public UNIX resources. We are fortunate enough to have these facilities at Northwestern. As always, I not only welcome but heartily encourage your comments, either via email or USENET postings, especially if you disagree with me. I think it would be great fun to debate this issue in public, and less fun but still fun if you'd prefer to do it in private. Bringing the many services of the Internet to the personal computer desktop so that people who aren't UNIX hackers can benefit from them is one of my current passions. It's an important issue, and we need to figure out the "right" way to do it. A disclaimer is certainly necessary: These are my personal opinions, and they do not necessarily reflect the policy or opinions of ACNS management. John Norstad Academic Computing and Network Services Northwestern University email@example.com
Up to my home page.