wiki:webmail-goals

Version 5 (modified by Daniel Kahn Gillmor, 8 years ago) (diff)

--

Webmail Goals

At the recent support team meeting we discussed our desired features and goals for webmail applications.

if a goal or desired feature isn't clear, it should be broken out into a separate subsection with an internal link for discussion.

Feature Comparison

This is an attempt to document them and compare them across different webapps. if a column for a webapp is empty, that means no one has verified it one way or the other. When ranking, please use "Bad", "OK", or "Good", and provide links to back up your assessment if you think it might be contentious.

feature/goal squirrelmail horde roundcube
trivial login
easy search
faceted search
HTTP→HTTPS/HSTS support
cookies/js security audit
trivial to add to addressbook from incoming mail OK
address book accessibility across webmail apps
displaying messages in threads
generating messages with proper threading headers
easy reply-to-list for mailing list messages
calendar integration
message tagging
IMAP integration
correct default "From" address
outbound identity management
inbound filters/sieve
anti-spam integration
good user documentation
good developer/plugin documentation
aesthetically-pleasing
if aesthetically-pleasing, themable?
internationalization
proper charset/MIME handling

Goals

Trivial Login

Members shouldn't need to remember or input anything more than their e-mail address or their mf/pl user account name to log into the site. Either of these, used with the correct password, should work to grant them access to their e-mail.

IMAP Integration

Most webmail talks to an imap server on the backend. We need that since MF/PL uses IMAP to present our mail.

If a webmail system applies tags to messages, it would also be nice to supply those message tags back to the IMAP server for integration somehow with other clients.

Default From Address

an MF/PL login should just use a simple name. But the webmail application needs to pick a legitimate "from" address for that member. (e.g. if they have their own domain name, they should use foo@…, instead of foo@…).

Outbound Identity Management

Members ought to be able to select from an array of outbound identities when composing a message. At a minimum, a member ought to be able to predefine a set of outbound identities they commonly use. Ideally, the set of outbound identities should be synchronized with the aliases that MF/PL knows will flow into their mailbox.