Email Is For Everyone: Progress Report #2
SEng 499 Project #15
Team: Jeff Crowe, Torben Werner, Crystal Hansen
Faculty Supervisor: Dr. Jens Weber
Table of Contents
In an increasingly digital age it can be difficult for the elderly and disabled to keep in touch
with family and friends. The lack of email communication skills can leave these people isolated. One
of the primary factors which limit the adoption of email by the less technology savvy users is the complexity
of modern email applications. These programs are all designed to accommodate the needs of every possible
usage, and therefore add many features which unnecessarily complicate the basic usage.
The Email Is For Everyone (EIFE) application will present an email interface which is designed only
with the most basic usage in mind. It will be designed with the OLPC as the target system to allow users
to operate on a simple preconfigured low budget system. It will allow users to compose messages by selecting
a predefined canned message, thus avoiding need of a keyboard, or by typing a custom message to be sent.
EIFE users are safeguarded by a Guardian Angel, a trusted friend or family member, who will approve
any new contacts before their messages are allowed through. This avoids many of the risks of email use
while keeping the rewards intact.
Most e-mail clients are feature heavy, complicated, and require computer literacy to set up and use.
Viruses, phishing, and other e-mail related scams are prevalent and may not be easily recognized by
someone with little or no computer skills. Sending and receiving email can be risky and confusing, especially
when receiving emailed attachments. In addition, accessibility becomes a challenge for people who have
difficulty typing on a keyboard (especially one as small as that on the OLPC).
An advantage which this project has over other email communication systems is that it can break away
from the standard email paradigms. The users are less likely to be familiar with standard email applications,
so something new and more intuitive to a base level user can be modeled.
We propose an application for the OLPC which will allow for users to understand how to perform basic
email tasks without requiring extensive training. Since this program will be targeted at the most basic
user, many of the extensive features which are required in full email suites can be excluded. There
is no need to support multiple email accounts, folders, different styles of sorting, or other features.
The user interface for the application will feature a contact list and a message view pane. The contact
list will show all of the contact which have been added. The list will be alphabetically sorted to allow
for easily finding contacts, but contacts from which unread messages have been received will be displayed
specially at the top of the list to attract the user's attention. When a contact is selected from the
list, the full history of messages sent to and received from that contact will be displayed in the message
view pane. A field in which new messages can be composed will be shown in this pane as well. The user
has the ability to enter new messages to send by selecting a canned message or by typing in a customized
Message composition would be accomplished by selecting a predefined canned response from a list (which
would allow one to avoid using the keyboard) or a custom message could be in. On an outgoing message
the user would be able to capture and attach an image from the laptop's built in webcam in order to
create custom messages with minimal effort.
The messaging will operate on a white list filtering concept. EIFE users will only see messages from
contacts which appear in their contact list. The user will have the ability to add new contacts to their
list if they so choose, but the primary method by which contacts are added will be via a 'Guardian Angel'.
The concept of a Guardian Angel is a third party which will be given permissions to manage the contacts
for the EIFE user. This third party would most likely be a more computer savvy friend or family member.
The Guardian Angel would be given full control to add or remove contacts from the email whitelist. When
a message is received from a new contact, the Guardian Angel is notified and can either allow or block
the contact. This system prevents any spam or unsolicited emails from being received by the user and
protects them from email scams.
Special handling will be added for messages which contain photo attachments. When such a message
is receive the user will be presented with an option for whether to import the attached images to their
photo album. Rather than displaying the full image in the email, a size reduced version of the image
will be shown. An optional feature for the application, if time allowed, would be a photo album screen
saver which would show all of the photos received and stored from contacts.
The project design follows a client-server architecture. Within the client-server architecture, there
are three primary components:
- Client application to run on OLPC hardware
- Email server to provide account, email, and configuration support
- Guardian Angel web interface to allow for email and contact management.
Overall Project Architecture
The goals for the project are broken down into the requirements for each of the primary components
presented in the Project Architecture: client, email server, and Guardian Angel.
- Email Messages
- EIFE will allow users to send to and receive email messages from users on their contact
- Users will never receive email from senders not on the contact list. If email is received
from a user not on the contact list, that user must be added to the contact list by the Guardian
Angel before it can be viewed by the user.
- User Interface
- The EIFE interface will provide an extremely intuitive interface which will allow for less
computer savvy users to use the system.
- The EIFE interface will allow for sending and receiving emails without requiring the use
of a mouse or keyboard.
- Keyboard is an option for sending custom messages, but canned messages can be sent without
use of a keyboard
- Primary navigation should be possible using the on screen joypad and game buttons, which
would allow for the laptop to remain in tablet mode at all times.
- If it is not possible to create an intuitive interface with these controls, the assumption
of availability of a touch-screen may be made.
- User Account
- The EIFE will provide a setup wizard to create (or modify) an account, including the emailed
request for management to a Guardian Angel. This configuration may be performed by a third party
on behalf of the new EIFE user.
- Account information will be stored locally and used for each subsequent application start-up.
- Authenticating a client
- An EIFE client will need to be able to authenticate themselves to the EIFE server. The EIFE
client will communicate to the EIFE server via TCP/IP and XMLRPC in order to provide the EIFE
user’s credentials, such as a username and password combination. The EIFE server will then attempt
to authenticate the client.
- If the user credentials are valid, an authentication token will be returned to the client.
- Synchronizing with a client
- An EIFE client will need to be able to connect to the EIFE server over a network in order
to synchronize its user’s settings. This will include canned messages, contacts, and groups.
- Synchronization attempts will need to be authenticated in order to ensure only a valid EIFE
user can synchronize their accounts.
- If a ne w contact, group or canned message has been added by the EIFE user’s Guardian Angel,
it will need to be sent to the EIFE client during a synchronization request.
- If an existing contact, group or canned message has been deleted by the EIFE user’s Guardian
Angel, a notification of the item’s removal will need to be sent to the EIFE client during a
- Sending messages from a client:
- The server will need to accept messages sent via the Simple Mail Transfer Protocol (SMTP)
from the client application and forward those messages to the intended recipients.
- If any errors occur, such as an invalid contact address, the server will forward the invalid
message along with a description of the problem to the EIFE user’s Guardian Angel.
- Receiving messages for a client:
- The server will need to accept messages, sent via SMTP, which are intended for any of its
- The server will need to validate any sending addresses to ensure they appear on the recipient
EIFE user’s approved contacts list.
- The server will need to pass received messages to a SPAM detection program to calculate
a SPAM rating.
- If the received message exceeds the EIFE user’s SPAM rating threshold, the message will
- If the sending address does not appear in the EIFE user’s approved contacts list, the server
will place the message in the EIFE user’s pending messages folder and the EIFE user’s Guardian
Angel will be notified of a pending contact approval.
- If the address which the message is being sent from appears in the EIFE user’s blocked list
the message will be discarded and not passed on to the EIFE user.
- Sending messages to a client:
- An EIFE client will periodically request to download any new messages received by the server
via the POP3 protocol.
- Each message download request will need to be authenticated using a username and password
combination. Only a request presenting a valid username and password will be allowed to download
messages or otherwise communicate to the server over POP3.
Guardian Angel Web Interface
- Management of EIFE users
- EIFE user management requests will be received from the server. A unique management request
key will be created, stored, and sent to an email recipient as a GA management request.
- The EIFE management request will contain a URL including the unique request key. When this
URL is activated the user will be directed to a web page giving them a choice of either associating
the request with an existing GA account or creating a new account to associate it with.
- If a new EIFE management request is sent out for the same EIFE user, the previous request
key will be invalidated and attempting to use it to add the user for management will result
in an error.
- If an EIFE client sends out a request for a new GA they will be immediately disassociated
with the old GA.
- A GA account has no purpose without any EIFE accounts to manage, so login will be disabled
if all EIFE accounts associated with the GA account are removed. The account will still
be valid to allow for EIFE accounts to be added at a later date.
- Messaging with the EIFE users
- Each GA will have the ability to send email messages back and forth with any of their managed
EIFE users. A full message history for communications to and from each user will be available.
- Incoming contact approval
- When new messages are received from a contact which does not appear in the EIFE user’s contact
list, the GA will be notified of a pending contact approval.
- The GA will be given the opportunity to read the incoming message and decide whether or
not the contact is valid. If the contact is valid they can be added to the user’s contact list
and the pending message(s) will be delivered to the user.
- If the contact is not valid, the GA has the option to block further messages from the user
and delete the pending messages.
- Manual contact list management
- The GA will have the ability to manually add new contacts to the EIFE user’s contact list.
This may be done in response to a contact list addition request message sent from an EIFE user.
- Removing existing contacts or blocking new or existing contacts will be possible through
the same interface.
- Template message management
- The list of template messages with the fields requiring user input (or no input fields for
purely canned messages) will be editable by the GA. This includes the ability to add, remove,
and edit any canned messages. These changes will be automatically pulled to the EIFE client
on its next configuration update query.
Design and Technology Decisions
While the OLPC uses Linux as its underlying operating system, and therefore any general-purpose programming
language available for Linux is a possible choice for development, the OLPC's sugar environment was
written in python 2.5 and the python libraries that encapsulate it are already supplied. This makes
it the recommended and most commonly-used programming language, and the natural choice for the client-side
portion of our application.
JSP and Java were chosen for the Guardian Angel web interface. The project team already has strong
experience with both of these languages which helps decrease development effort. Any selection of web
interface language would end up generating html content for the client browser in the end, so the question
comes down to the coding and server side effort. JSP and Java web applications are easy to maintain
and deploy in a container like Apache Tomcat. The popularity of these languages makes them a natural
choice, as libraries and forums can help to solve any issues encountered. Java was also chosen for the
Server component of EIFE to provide simple interaction with the Guardian Angel web interface by having
both run inside the same Java Virtual Machine (JVM). A search of open source email server applications
turned up a well designed and documented Java application "Java Email Server" which will function well
as a library for our application and decrease the code which needs to be written.
The data storage requirements for the client and server components were vastly different in terms
of scale, available tools, and processing capabilities.
There are many open-source relational and non-relational database systems which are mature and readily
available. The choice of a database system for the EIFE client would ideally be one that is both small
and integrates well with a standard Python API. Options such as using the MySQL RDBMS were not considered
practical since such as system would add considerable overhead and bloat the client side OLPC application.
Other options included much smaller systems, such as the Derby RDBMS, which are much more practical
to embed and distribute in an application. However, the Derby system did not have the support of a Python
API and would require the use of Java and a JVM installed on the OLPG. This would also add considerable
bloat and overhead to the client-side application and therefore would not be practical. Finally, it
was decided to use the SQLite RDBMS. SQLite is extremely small and is frequently embedded in applications
as a back-end database system. Furthermore, SQLite comes with Python API support and is already included
in the current OLPC SDK.
The server requirements for a database system did not have the programming language or size constraints
that the client had. However, the server could be expected to handle much larger amounts of data. MySQL
is a well-supported, open-source database RDBMS and is commonly used today as the back-end for many
of the large sites on the Web.
An important decision during the project was to choose an e-mail system which would meet the needs
of the OLPG project. With the timeframe of the project being relatively short, it was preferred that
as much of the e-mail system as possible would be adapted from an existing e-mail system. This would
save time by not requiring the project members to have to implement basic e-mail functionality from
the ground up.
E-mail is mature technology, with many open source systems readily available to choose from. For
the EIFE project, it was preferable to minimize the number of different technologies and programming
languages used. Most of the EIFE client application will be developed in Python, while the Guardian
Angel system was already planned to be developed in Java. Ideally, the e-mail system chosen would therefore
be implemented in either Python or Java. This narrowed down the choices a lot. For a Python system,
the only acceptable choice would be to use the SMTPLib library. However, this library only implemented
very basic e-mail functionality, such as sending and receiving messages. Further functionality such
as message validation, storage, and filtering would need to be implemented from scratch. After spending
some time implementing a prototype SMTP e-mail server in Python, it was discovered that the amount of
work needed would be considerable. However, an open-source, GPL licensed alternative called the Java
Email Server (JES) was found which appeared to offer much more needed functionality. As its name suggests,
JES was written in Java and would integrate nicely with the other server components which are also being
written in Java. JES came with both a POP3 and SMTP service already implemented, as well as a framework
for storing and handling messages received by the server. It was decided that JES would save considerable
development effort and therefore should be used as the e-mail system for the EIFE server.
Client Use Cases
Use Case #1: UC-Request (Add Contact Request)
Client Use Case: Add Contact Request
Use Case #2: UC-Receive (Receive a Message)
Client Use Case: Receives a Message
Use Case #3: UC-Send (Send a Message)
Client Use Case: Send a message
Use Case #4: UC-Settings (Set Up or Modify Use Settings)
Client Use Case: Configuration
Server Use Cases
Use Case #1: UC-AddGroup (Server Requested to Add a Group)
Server Use Case: Add to Group
Use Case #2: UC-ServerRecieve (Server Receives a Message for an EIFE Client)
Server Use Case: Receive a Message
Use Case #3: UC-MessageRequest (Client Requests New Messages From Server)
Server Use Case: Request New Messages
Use Case #4: UC-ServerSend (Client Sends E-mail to Server)
Server Use Case: Send a Message
Use Case #5: UC-AddContact (Server Requested to Add a Contact)
Server Use Case: Add a Contact
Guardian Angel Use Cases
Use Case #1: UC-Associate (Guardian Angel Registration)
GA Use Case: Registration
Use Case #2: UC-Auth (GA Authentication)
GA Use Case: Authentication
Use Case #3: UC-Contact (Approval of New Incoming Contact)
GA Use Case: New Contact
Use Case #4: UC-Template (GA Add a New Template Message)
GA Use Case: New Template Message
Client User Interface
The user interface for the application will consist of one mail screen divided into a contact list
and a message view pane. The contact list will show all of the contacts that the user is able to communicate
with. The list will be alphabetically sorted by last name to allow for easily finding contacts. Contacts
from which unread messages have been received will be displayed again at the top of the list to attract
the user's attention.
The main user interface with a selected template message.
When a contact is selected from the list, the full history of messages sent to and received from
that contact will be displayed in the message view pane. A field in which new messages can be composed
will be shown in this pane as well. The user has the ability to enter new messages to send by selecting
a template message or by typing in a customized response. The user can then capture and add images taken
from the onboard webcam.
The main user interface with a custom message.
The image capture interface with a custom message.
Special handling will be added for messages which contain photo attachments. When such a message
is receive the user will be presented with an option for whether to import the attached images to their
photo album (figure i). Rather than displaying the full image in the email, a size reduced version of
the image will be shown. An optional feature for the application, if time allowed, would be a photo
album screen saver which would show all of the photos received and stored from contacts.
The main user interface displaying a received message with attached pictures.
The first time the program is run the set-up wizard will be automatically activated and displayed.
This user will walkthrough steps necessary to set-up the user account. The set up steps are as follows:
1) Prompt the user for their name, 2) Ask the user to choose a EIFE user id and password. 3) Ask the
user to enter the email address of the person they are designating as their Guardian Angel, and 4) Confirm
Guardian Angel Web Interface
The Guardian Angel Web interface is designed to be used by a user with more computer savvy than those
using the EIFE system, so its complexity can be higher. It will allow for a single Guardian Angel user
to manage communications for several EIFE clients. The following presents a walkthrough of the user
interface prototype for the web interface.
- The requirements for the login page are simple. The user must enter a login and password and press sign in to login. If login fails the user is presented with an error, otherwise they are directed to the user home page. Note that a registration button is not required, as registration is only possible through an EIFE user management request.
Guardian Angel Prototype: Login Page
- Upon successful login the user is presented with their home page. This presents them with a summary of the account activity and status of their managed users. A list of the managed users is available which consists of links to the management page for each EIFE user. These links are updated to indicate the number of items requiring user attention.
Guardian Angel Prototype: Main Page
- When an individual user is selected for management, a specialized management page will open. This page shows more detailed account activity for the user which may not be shown in the summary on the home page. A list of the account management activities is shown which show the different ways in which the client can be managed.
Guardian Angel Prototype: User Management Page
- The User Messages page can be used for sending and receiving messages from a managed user. These messages will appear in the EIFE users ‘Guardian Angel’ communication section. Message history with date and sender information is shown and new text messages can be sent using the provided text field. Note that once the User Messages page has been opened. The messages are assumed to have been read and the unread messages count will be cleared. The new messages will still be specially highlighted to draw attention.
Guardian Angel Prototype: User Messages Page
- The Pending Contacts page is used to manage incoming messages from addresses which do not appear on the EIFE user’s contact list. Messages are grouped by sender and displayed on a single page. The contact sending the message can be added to the contact list, in which case a new contact page will be shown, after which the messages will be sent to the client and no longer appear in the pending contacts page. The contact can also be blocked, meaning that future messages from that address will be automatically deleted. Messages can be deleted which clears out the current messages but does not require blocking the contact. A spam detection tool will be used to rate messages on the likelihood of spam. Messages with very high ratings could be automatically deleted, and those which are allowed to pass would be marked with the spam rating to aid the Guardian Angel in filtering messages. Note that unlike the User Messages section, the Pending Contact items requiring attention count does not change until the user takes action to add, delete, or block the new contact.
Guardian Angel Prototype: User Contacts Page
Deliverables and Timeline
- Progress Report #1 - January 23
- Use Cases Complete - February 1
- Design and Research Complete - February 4
- Progress Report #2 - February 27
- Database Design Complete - March 2
- Development Complete - March 18
- Test Plan Complete - March 21
- Testing Complete - March 25
- Project Website Compelete - March 26
- ELW Presentation - March 27
- Final Project Report - April 3
- Web Presentation - April 3
- Progress Report #1 - Crystal, Jeff, Torben
- Design and Research Complete - Crystal, Jeff, Torben
- Client Use Cases - Crystal
- Server Use Cases - Torben
- Guardian Angel Use Cases - Jeff
- Progress Report #2 - Crystal, Jeff, Torben
- Database Design - Torben
- Development Complete - Crystal, Jeff, Torben
- Test Plan -Crystal, Jeff, Torben
- Testing - Crystal, Jeff, Torben
- Project Website - Crystal
- ELW Presentation - Crystal, Jeff, Torben
- Final Project Report - Crystal, Jeff, Torben
- Web Presentation - Jeff
The current team progress made includes the following:
- Several project meetings have been held.
- The project's scope and team organization has been defined.
- The team organization and project description form has been submitted.
- The team has acquired an OLPC and investigated the user interface,
features, and capabilities of the OLPC.
- Research and set up of the development environment and emulator has been
- The overall design has been completed and development is now in progress.
- The first and second progress reports have been written.