------------------------------------------------- Webmail Project Overview Draft 0.4; 7/5/02 http://yendi.cc.cmu.edu/work/webmail/overview.txt ------------------------------------------------- Overview -------- We would like to deploy a webmail solution as soon as possible. We believe it is reasonable to have a system up and running by the end of August 2002, assuming that we can quickly pick a webmail client to begin the deployment work. This is a no-earlier date for the pilot. Additional time may be required for documentation, getting support staff up to speed, etc. From a technical standpoint, there is about two months worth of base work. This work includes integration of the web authentication system with the email authentication system in a secure and scalable way. Depending on the webmail client, there may be also work required to properly scale the system and to deal with the number of folders we export via IMAP. We have no plans to change any UI elements in the code. This is not a project to produce the best webmail client. This is a project to quickly deploy an existing webmail client to campus. The goal is to ensure that if critical updates come out from the vendor, we do not have to spend an inordinate amount of time integrating these changes with our deployed client. Client Selection ---------------- The client selected is Squirrellmail. - On org.acs.awg.project.webmail 05/07/02, Ruben posts the requirements document. - On org.acs.awg.project.webmail 05/09/02, Ruben posts the raw feedback from the users. No formal document was produced on the selection process. It seemed that the reason Squirrellmail was chosen was that: a) Almost everyone had something good to say about it, b) No one seemed to like Silkymail, c) the uPortal email channel was almost impossible to find and it appears that development has stopped on it. Implementation -------------- * Updated to latest version Squirrellmail was updated to the latest version. It appears that the developers are putting out a new release every three months or so. We are keeping up to date incrementally by updating from their revision control system (CVS). When we enter the external beta, we expect to stop updating the code from them unless there is a significant update. * Plugins installed The following plugins were installed: - quota_usage : allow the user to see their quota utilization - ldapquery : allow the user to use LDAP to look for other users - message details: allow the user to view the raw message * Plugins modified - ldapquery: The plugin was very broken. The fixes were submitted back to the developer. * Fixed Subscriptions The existing subscription code was too inefficient to be used. Even with only one user on the system, the code would time out before processing could finish. The code seemed to be O(n^n). The change made was to have the user type in the name of the folder they wished to subscribe to/from instead of having them pick it from a list of all available folders. * IMAP caching A typical problem with webmail servers is that they pound the IMAP server with multiple short connections as HTTP is stateless. IMAP is not stateless and so is generally happier with fewer longer lived connections. To work around this problem. when a user logs into the webmail system, we create a local proxy on the webmail server that handles IMAP requests for that webmail user. In this manner, multiple HTTP requests only result in a single IMAP connection. * WebISO proxy Since the web server and the IMAP server are on different machines, there needs to be a way for the web server to authenticate the user to the IMAP server. A typical mechanism for doing this is to just give the web server your password. It then takes this password and gives it to the IMAP server. The solution is simple but if an attacker compromises the web server, the attacker now has the user's password. Until the user changes his password, all services are now at risk. Another mechanism for doing this is to have a privileged account on the web server. The web server authenticates the user and then connects to the IMAP server as the privileged account. After logging into the IMAP server, the privileged account then becomes the user. While this keeps the attacker from gaining access to other services, the attacker now has access to everyone's mail. The WebISO proxy work solves both of these problems. In this scheme, using WebISO, the web server is given an authenticator blob (in this case, the user's mail server Kerberos service ticket). In this case, if an attacker compromises the web server, then all they have is a service ticket for any logged in users. So while the attacker can get at those mailboxes, the time span in which he can do it is limited to the lifetime of the ticket and the attacker can not access any other services nor can they get at anyone who is not using webmail. An additional benefit is that Kerberos authentication is also less resource intensive on the mail servers than password based authentication. Timeline -------- Brian's timeline is at: http://www.cmu.edu/acs/internal/user-services/project-plans/bennett/WebmailProjectPlan.html Appendix A: Choosing a Client ----------------------------- In order to deploy quickly, we hope we can quickly come to a consensus on what webmail client to start work on. We have already installed two webmail clients for evaluation: SquirrelMail - https://asg2.web.cmu.edu/sq SilkyMail - https://asg2.web.cmu.edu/sm ** NOTE: As of 7/5/02, these links may no longer work ** We believe that either choice could be quickly ramped up. Keep in mind that neither client is in its final state and there clearly is functionality missing. For example, in the case of Silkymail, there may not be a IMSP dialog since that may folded in the authentication work. In either case, authentication would almost certainly be going through pubcookie so the login sessions in general won't be the same. Things may be slow, links may not work, etc. etc. In addition to trying out the client, it is recommended to look at the vendor web pages: SquirrelMail - http://www.squirrelmail.org Silkymail - http://www.silkymail.com We have not seriously looked at any other clients. If there is a desire to look at others, we can as there is absolutely no claim being made that SquirrelMail and Silkymail are the two best clients out there. There are a number of choices and these two were arbitrarily picked out of the pack. Other open-source IMAP web clients include: IMP: http://www.horde.org/imp/ V-Webmail: http://www.phpguru.org/frederick.html Postman: http://www.uv.es/postman/postman.html We have not heard anything about the last two clients. Fairly recently IMP was unintelligent in handling authentication, passing credentials with every HTTP exchange rather than retaining state in the web application. Keep in mind that looking at more clients means more time before deployment and there is pressure to deploy something reasonable as soon as possible. It is also likely that we will need to revisit webmail when we do portals so what we choose now is not likely to be set in stone. The uPortal email channel is a discussion point. On one hand, choosing this path may significantly add to the time of deployment. Most of the other Webmail clients are PHP based and so they are pretty much the same under the hood. The uPortal webmail channel is a Java client that requires the entire uPortal infrastructure. This client also has much less of a track record than almost any other webmail client out there. On the other hand, we know that the uPortal webmail channel works with uPortal, which thing will require some indeterminate amount of work for any other webmail client. Appendix B: Timelime Worksheet ------------------------------ ** This section is now deprecated. See the Timeline section for a link ** to the actual project timeline. 1. For every additional web mail client, add one week of time to get it installed at a review quality. Add another week for uPortal and expect that uPortal will require significantly more work than any other web mail client. 2. Insert time taken to choose a webmail client. Systems can provide feedback regarding performance, scalability, etc; User Services will provide feedback on usability, supportability, etc. From the webmail client evaluation team: Deliverable (1): A ranked list of clients; what was considered superior, what was considered weak (this is in case it was an installation issue rather than a UI issue. ** No later than 2 weeks after the Deliverable (1), the Cyrus team will provide Deliverable (2): a documentation that either a) Endorses the first choice item from Deliverable (1) b) Detailed Recommendation for a difference choice in Deliverable (2) If (a) occurs, then within an additional week, the Cyrus team will provide Deliverable (3): a more detailed schedule with milestone dates for completion of the project. If (b) is not acceptable to the webmail client evaluation team, then the Cyrus team requests Deliverable (4): a description of why the first choice MUST be selected and the alternative recommendation was rejected. No later than 2 weeks after receipt of Deliverable (4), we will produce Deliverable (3): a more detailed schedule with milestone dates for completion of the project. ** No later than 2 weeks after Deliverable (3), the webmail client evaluation team provides Deliverable(5): a completed project plan to the Directors and Joel. This document should also briefly describe our process, what client we picked, explain why we rejected other clients. --------- ChangeLog --------- 0.1 - 04/23/02 - Initial version 0.2 - 04/24/02 - Remove plan A; add a bunch more text. 0.3 - 04/24/02 - Various modifications by Doug. 0.4 - 07/05/02 - Minor edits - Added Client selection - Added Implementation changes - Added link to Brian's Project Timeline - Deprecate Timeline worksheet - Deprecate Choosing a client