4010-440 Team Project
MailMan - An Email Client
Our company, millifirm.com, has decided create a proof-of-concept prototype for a highly adaptable, flexible, and very usable email client. As a client, the program will communicate with mail servers using standard protocols to download mail messages, and to provide users with a variety of options for organizing, filtering, and manipulating these messages.
The objectives are listed in terms of long-term plans and what must be in the prototype to permit analysis and critique of the architecture team's approach. Of course, including extra features in the prototype to directly illustrate its ability to meet the goals of the product is encouraged where practical.
The MailMan system will be designed to support a variety of mail reading protocols such as POP, IMAP, and Microsoft Exchange. For the prototype, only POP (documentation here) must be supported, but it must be clear how adapting to other reading protocols would be supported in the architecture. Note that if a product version of MailMan is created, multiple reading protocols will have to be supported simultaneously. Support includes provisions for configuring account names, passwords, etc., that are part of a reading protocol.
The MailMan system will be designed to support a variety of message posting protocols such as SMTP and Microsoft Exchange. The prototype is not required to support sending of messages, but it must be clear how such support for multiple, simultaneous mail sending protocols would be incorporated in the architecture. The prototype must be configured with a dummy delivery subsystem that simply copies outgoing messages to a temporary directory. As in the case of mail reading, the delivery portion of the architecture must be able to adapt to different forms of authentication, encryption, etc., for outbound messages.
Users must be able to store messages in a hierarchical folder systems. New messages will be placed in the standard Inbox folder; users can delete such messages or move them to other folders in the hierarchy that holds the Inbox folder.
The format of the archive hierarchy must be easily changed. For the prototype, the hierarchy will be a hierarchical set of folders (directories) on the host operating system; user's must be able to specify where the root of this hierarchy is located (no embedded directory names allowed!). However, the architecture must support configuring MailMan to use a different hierarchical systems such as tar or zip archives.
MailMan will support filtering of mail messages on a variety of criteria. In particular, it must be possible for Millifirm or 3rd party vendors to provide modules that can be plugged into an existing MailMan system to provide new filtering capabilities. For the prototype, the only filters that must be supported are those to discard mail from any of a list of domains. In the final product, however, modules may be added dynamically to discard or move mail based on any attributes of the incoming messages, and it must be clear how the architecture will support such dynamic configuration. In particular, users must be able to configure the order in which filters from any source are applied to incoming messages.
MailMan must support sorting of messages on a variety of criteria. In particular, the prototype must support sorting messages in a folder by sender, subject (where forward messages and replies are grouped under the primary subject contents), or arrival date and time. However, it must be clear from the architecture and the prototype how support for other sorting criteria could be incorporated in the product.
As mail clients like MailMan are used by experts and novices, usability for all classes of users must be a primary concern. There are no specific requirements on the prototype for usability support, but it must be clear how the architecture can support activities such as undo and command cancel. In addition, it must also be clear how irrevocable actions (such as deletion of a message) are supported so as to minimize the probability and severity of mistakes.
This project is designed to have teams focus on the architectural aspects of a general mail client. You would be wise to consult existing mail clients both for ideas as to functionality as well as architectural approaches to specific subproblems.
Note that this project may well involve the interplay of several architectural styles. Part of your teams' responsibility is to show that these styles interact in a harmonious manner to create a coherent and comprehensible overall architecture.