The Webmail group came to several realizations early in its first meeting:
We realized that we needed to come to a common understanding of how webmail works, or, more specifically, how non-proprietary webmail works (description follows). Our understanding of the webmail model helped us to define the scope and objectives for our work forward.
The diagram may be helpful in understanding the differences between webmail and the terminal-based or client/server products currently in widespread use at Penn. Brief comments:
Webmail employs an additional layer between the user and the e-mail store, that is, a web module that takes input from the user through a browser client, parses or interprets that input, and communicates with the mail store and/or IMAP/POP/SMTP processes. The webmail products we examined generally--although not always--operate with an external mail server, that is, a mail store not integrated into the webmail application itself.
The webmail servers we ultimately chose to test can be installed on the same hosts as the mail servers, can be installed on separate servers from the mail servers, and can, in some cases, provide a front door to multiple mail servers. Thus, Penn could implement a solution whereby each mail server utilized its own webmail impelmentation, either on its e-mail host or on a different web host. Alternatively, Penn could implement a solution whereby a central webmail server could serve various e-mail systems. There is no requirement that the web engine run on the same host as the mail engine.
Early in our discussions on how to select and evaluate products, it became clear that the functionality that many people expect in their IMAP and POP clients was not available in any of the webmail products, and thus these products should not be compared against the native IMAP and POP applications. We concluded that the task force time could be best spent if we considered these products as alternatives to ELM, and as supplements, rather than alternatives, to the full-function native applications. We also concluded that it was likely not feasible to expect the Penn ELM constituency to migrate en masse from ELM to a webmail solution, and thus it became a primary requirement that the products tested work with the ELM mail spool, as do the IMAP and POP clients currently in widespread use.
Webmail products provide a GUI alternative to ELM for users requiring roaming access. For both student populations utilizing multiple machines in public facilities, and for the faculty or staff member who is away from their primary workstation, webmail provides GUI access to a central mail store.
ELM has never been able to handle all attachments in any consistent and reliable way. The webmail products are much better at handling attachments than ELM.
The task force spent significant time developing a list of requirements, divided into two types: those absolutely essential in any product to be considered, and those "would be nice" that might ultimately give one product an edge over another. After discovering that the webmail products as a whole did not have the functionality of the native IMAP and POP clients, the list of absolute essentials was pared down to less than 10, which were used to screen products for evaluation. A test script was developed to further evaluate these absolute requirements, and to also test for the "nice to have" items, and the final results are based on this test script.
As noted above, interoperability with the ELM mail folder structure emerged as a critical requirement, which eliminated a number of products requiring a proprietary mail system (GLWebMail, Exchange Web Client, etc.) Given the recommendations of the most recent e-mail task force, we also eliminated any product that did not offer IMAP as a mail protocol.
We had difficulty obtaining further information on some products, and chose to eliminate those products based on the likelihood that support would be equally as difficult to obtain.
The security issues for these products, including the final three products tested, are just as prevalent as for the current native IMAP and POP clients. Specifically, while passwords can be encrypted through SSL, they are generally passed in clear text. We ultimately decided that this situation is no worse than our current situation, and that this was not grounds in and of itself for eliminating products (or there would be nothing left to recommend).
Many of these products, including the final three, lacked what many of us have come to consider as basic e-mail functionality. While some accommodated attachments, none provided filtering or search capabilities. Folder, contact and group, spell-checking and directory functionality were generally available in some form, but not what many users expect. User interface and application help were generally less than splendid.
The three products tested where the only ones that appeared to meet, or have a reasonable likelihood of meeting, the absolute requirements noted above. Results of that testing, in detail, are available at the following links:
IMP appears to be the solution most widely in use in academic institutions, and is already in use at Penn in the Law School, SEAS, and in the Graduate School of Education. IMP utlizes standard IMAP and web servers currently in use at Penn. We hope to explore IMP 2.3 when it becomes available later this fall.
IMP scored the highest overall and is our recommended product for this evaluation effort.
New Features in IMP 2.3
TWIG was the only other product based on open standards, interoperability with standard IMAP and web servers, and a generic mail spool. As a competitor to IMP it came close, bettering IMP in some areas, falling short in others (no Help, for example). TWIG does provide other PIM features (calendar, tasks, etc.).
WorldPilot had by far the nicest user interface (looked a whole generation newer in terms of interface design), but unlike IMP and TWIG, was most reliable when installed with its own proprietary web server. Further testing indicated both some instability of the server when installed with an Apache web server and lack of features implemented in both IMP and TWIG.
