Projects/xomail

This page is geared towards Summer of Code 2008 work on an email client.

Introduction

Currently there is a Gmail activity but no real email client that can be used in Sugar. The possibility of accessing/composing emails offline does not exist. An email client with mesh integration like direct sending to mesh buddies would be great, but the basic groundwork of a usable email activity is needed.

Collaboration tools are a very important part of the OLPC software bundle and an activity which brings email to the XO desktop and ties in with the environment would be a very useful addition.

Background

• Some notes from a former OLPC intern examining different email clients and recommendations. [1]
• Tinymail has an email client that could do with better Sugar integration

Deliverables

• A lightweight, functional email client with a child-friendly GUI
• A daemon should be developed for sending of unsent messages and receiving of new email, since can't assume the child will open the email activity when internet access is available.

Some other requisites

• POP/SMTP/IMAP including with SSL and TLS. POP should be more of a priority than IMAP, because the whole point is disconnected operation.
• Unicode email support
• Center email organization around tags not folders, and make it easy to manage email.
• Easy configuration on first run and later.
• Search, filtering, threading, and an address book.

Ideas

Please note that this is (for now) my ideas for accomplishing what is needed. I am looking for feedback. ~ User:Shikhar

MIME parsing, message construction and email sending/receiving

With Python,

• the RFC-compliant email module for can be used for MIME parsing of incoming email, and message construction.
• the RFC-compliant libaries smtp, poplib, imaplib can be utilized for email sending/receiving. The daemon and the activity will share this code.

If the core functionality is to be implemented in C/C++, libcamel or Tinymail can be relied upon.

Storage

• Develop an abstraction layer for storage-related requests.
• sqlite can be used for storage in a database. Using a database for email storage is not a new idea, here is an account of someone's succesful experiment for his purposes: http://www.sqlite.org/cvstrac/wiki?p=ExperimentalMailUserAgent
• The database design would have to be very well thought out. There can be several tables in the database to keep performance good while minimizing redundance.

Service descriptors

• To make it easy and extensible to configure on first run for services such as Gmail, a file format for a service descriptor can be formalized.
• The service descriptor would contain details about servers, protocols, junk-headers provided by the service, etc. Thus the only information required upon selection of a service should be username and password.
• It should be possible to specify certain details in the service descriptor such as whether the service sets SpamAssassin headers, which IMAP folders are not to be downloaded. For example the Gmail service descriptor could specify that email in the 'All Mail', 'Spam' and 'Trash' folder is not to be downloaded, and that other folder names are to be interpreted as tags, since Gmail provides IMAP.

Message Threading

• jwz's threading algorithm [2] can be used. It was proposed in the imapext-thread Internet Draft.
• There is some python code for the same.[3]
• Allow the user to manually thread by drag-and-drop where the algorithm gets it wrong.

Spam filtering

Support SpamAssassin headers. In this stage of development I think it would be best to outsource the spam filtering. If say a school server was to provide email it could use SpamAssassin. Using POP/IMAP with Gmail, spam is already filtered out by Gmail.

Smart tags

Smart tags as first class tags, except they can't be applied to messages since they are dynamically evaluated for the query they represent, and in that sense are like a saved search.

Search implementation =

For full text search, an option is to index all new email with the sqlite fts module (Could be expensive in terms of flash space?)

A common grammar for searches, filtering criteria and smart tags

Something interesting would be to formalize a common grammar for searches, filters and smart tags. Probably not beyond kids to pick up a simple domain specific language ;) Having GUI's for 'advanced search', configuring filters, etc is clunky. Examples: I can search for "received:today", and also as easily create a smart tag called "today's email" using that string, or create a filter that applies tag "papa" to all emails I receive with "from:dad at smthn.org". The expressiveness could get a lot richer.

Contacts

A simple address book should be implemented for address auto-completion. Can later be made more of a real address book, or could communicate with a (future?) contacts activity.

UI

TODO: Mockup