Rutgers Modifications to UBC Webmail

Owned by Jason Jason
Last updated: Nov 07, 2006Version comment
4 min read

This page is an attempt to document Rutgers modifications to the UBC_Webmail source tree for the purpose of incorporating them into the main development branch.

From email:

George Lindholm wrote:
> I'm starting some work on the UBC Webmail channel as part of our 2.0.3 to 2.5.x
> upgrade project.

George – I've responded inline to get notes on the list, there's a blog version of this online at:http://jay.shao.org/archives/2006/11/05/ru-webmail which has some pictures which is probably much simpler to get a feel for what I'm talking about.

Rutgers has a significantly enhanced a local fork of UBC_Webmail whose enhancements we've always been interested in working back into head for a while (never have enough time or people though). Our philosophy has been to try to deliver a fast, intuitive mail client which is optimized for casual email usage.

Our changes overlap significantly with your list. Unfortunately, we have significant local commitments which prevent us from volunteering engineering time to integrate these changes with head (there is enough refactoring, new code, configuration file changes, and repackaging it would almost definitely be a 4.0 effort) but I can commit to zipping up our changes, and offer some knowledge transfer and integration assistance via some conference calling or mailing list work. We can also help identify local modifications which may not be appropriate for a general audience (our multi-campus support code, for instance has some hard coded checks which are always on the "rethink" list...

Our changes (off the top of my head since I'm at home):

  • IMAP configuration tuning (allow setting of pretty much all javamail options on a per-server basis)
  • IMAP protocol connection handling work - minimize chatter, # of communications, optimize performance - we saw signifcant gains in our environment
  • Authenticated SMTP, IMAP SSL & SMTP SSL support
  • Preferences refactoring to use a key-value pair table in the DB to allow arbitrary preference values (instead of UBCWEBMAIL_PREFS, SERVER_CONFIG, etc. - just webmail, not yet addressbook) fronted with a portlet-api subset interface (implemented PortletPreferences API for most single-valued methods)
  • Performance in general - we've spent ~ a year tuning IMAP performance. Empirical and user reports say we're now the fastest webmail at campus (there are separate IMP & Squirrelmail instances)

And some bits which overlap your list below.

> Compose timeout problems

We implemented an XMLHttpRequest based "activity pinger" which keeps a user's session open as long as they're typing in the compose window. This allows the session timeout (ours is 15 min) to be from the time the user last provided input to the compose window, not when they started their message.

> Better spam filtering

Our approach was to integrate with outside the portal server filter configuration pages - any action that required iterating through messages on the client-side cause unacceptable performance issues for any of our users with more than a few hundred messages in their INBOX (which is of course most of them...)

A next step is probably auto-flagging of messages based on particular headers – e.g. after they've been processed by the central messaging systems. We've considered some social engineering to add a "Mark Spam" button that just deleted messages since users seem to have come to accept that feature.

> Improved Address book integration

We're have a prototype of AJAX auto completion for To: Cc: etc. fields which we hope to have in production for Jan. Our address book also allows storing postal address information.

> Detached compose message window

We disabled this functionality (in general in the portal) as initial user testing found it very confusing.

> Improved message deletion

We modified mail to support both a "mark delete & purge" and "move to trash" style workflow. We default to "move to trash" since our user studies indicated many don't understand the delete and purge model. When we "move to trash" we also default to purging deleted messages at the end of the session - consistent with many fat clients.

> Open in focused mode

We modified our mail channel to have a "summary" view (inbox, compose, etc. buttons and the 5 most recent email messages (last 5 in mailbox for performance reasons, generally ~= last 5) and then to focus the channel when users visit the inbox, compose mail, etc. We also have some hacks in place to support an approach similar to Yale's where we just display the summary view in the portal and link out to an external webmail (IMP & Squirrelmail) depending on which RU campus & mail server you connect to.

> Improved navigation

Split navigation into primary & secondary levels to allow consistent navigation within the channel. Provided a different navigation for compose mode to simplify message composition.

> Improved layout (Look & Feel)

Our folder views allow sorting on arbitrary columns (e.g. reordering based on date, sender, etc.) Our rows display striped for alternating rows, with icon badges indivating things like attachments. Our folder tree view was reworked to resemble a windows explorer view.

> Edit inbox messages

?

> Message indicator flags

We show flags for replied, forwarded, attachment, and bold the header for new messages. I don't think we currently support the IMAP /flagged status.

> Rich text/HTML formatting/compose

We're fighting this since we don't have the support resources to dedicate to responding to phishing concerns. We're trying to keep portal mail service text only, and pushing users who really want Rich Text to use a fat client. We may have to give eventually though. We're considering

  • url "linkifying" (finding urls and making them links)
  • image attachment display (e.g. display attachments that are images inline)