Tinymail
The big question is
OLPC can't depend on server infrastructure
According to the website it supports IMAP, Exchange and NNTP. It can be used to send messages over SMTP.
Given that the OLPC is used in an environment where there are no servers running IMAP, NNTP or SMTP, what use is it?
If it included a built-in IMAP and SMTP server that would hold messages for relay when a suitable server comes in range, then it might be more useful. Read the Instant messaging challenges page to see what the issues and use-cases are.
Answer
Tinymail isn't about just the connectivity with the server
Tinymail's main purpose is using the offline cache efficiëntly. The connectivity with "a server" is only implemented to fill that local store with something meaningful. I think the original asker confuses this a little bit: it's not really just about that connectivity. Support for a new service isn't really the big job at all (in fact, that is the easy part).
The hard part is parsing the MIME parts from those messages (and the format of this depends on the E-Mail client that has sent the message -> like Ms. Outlook and its quircks), efficiently loading a lot header information into a list (and a view for it), storing whatever the service gives you in that efficient-loadable format, stuff like that.
It seems the main problem addressed in this question is the most easy piece of code in the entire framework: fetching the damn messages into a local store. That's easy (especially if you can decide about that service). A lot existing tools can do that (fetchmail) in case you don't trust tinymail to do it for you.
Tinymail supports local formats too
The tinymail framework also supports local message stores like mbox, mh, spool and Maildir. Maildir is what Courier's imapd typically also uses. Tinymail also has its own local format.
The software that fetches or receives the messages can store them in such a mbox, spool, mh or Maildir on the device. Tinymail can access that (without needing a build-in IMAP service or extra process). You could also run a small IMAP service locally, but I fail to see the reason for that: tinymail can also use these local message stores, Maildir, mh, spool and mbox efficiently by itself.
The tool that receives these messages can be anything. As long as it writes the messages in the mbox, spool, mh or Maildir storage format (these are specified and standards). Whether that tool is going to be a small SMTP server or a plugin for the instant messaging infrastructure, doesn't matter.
A fetchmail-like tool
A small software that pulls messages from a nearby (suitable) server, i.e. one that is in range, and stores it on the local disk (for example using the Maildir or mbox format), sounds like a trivial task. You can, for example, reuse the existing fetchmail tool. If the Maildir, mh, spool nor mbox formats aren't suitable, it would be easy to create support for yet-another-such local-storage-format in tinymail.
Another possibility would be letting the instant messaging infrastructure pass the messages. Using some xsl you can transform typical Jabber messages to mbox or a Maildir. It would also be possible to support a new such format (i.e. one that stores Jabber messages on disk).
A service
Tinymail can be used to develop a service that exports messages and functionality to access a local store. Another possibility (that looks like this, but certainly isn't the same) would be to run a small IMAP server locally and have tinymail libraries handle access with that local store individually.
The idea behind tinymail as a service is that the local cache is stored only once on the device (in stead of per E-mail client application). Turning off caching (because the IMAP runs locally anyway) is possible in tinymail, and fixes this issue.
You can of course implement IMAP and MIME functionality in all client applications manually and run a local IMAP server. I wish you good luck with that :-) (it took me a year to do tinymail, and the Evolution Camel team at least another year to do the MIME parsing and IMAP connectivity correctly)
Tinymail itself isn't a service but a library. It however doesn't block you, at all, to develop a service with it. One possibility would be the remote proxy pattern and letting (some of the) the proxy instances at the client implement the same interfaces which tinymail exports. This way developing a client that or uses the service or the tinymail library directly would be done in the exact same way. Even ABI compatible (just linking with the library directly, in stead of linking with a library that implements the types by passing D-BUS messages with a service).
Developing such a service in Python using D-BUS is going to be something that will take one experienced Python+D-BUS developer a day or two. Tinymail's Python bindings cover the API 100%.
I presented a few solutions, but be creative
Be creative. What I gave here as possible solutions definitely aren't the only available ones. Creativity is what drives the OLPC project, right?
Information about tinymail
Documentation about building
Building a tinymail suitable for OLPC
svn co https://svn.tinymail.org/svn/tinymail cd tinymail/trunk ./autogen.sh --prefix=/opt/tinymail-olpc --with-platform=olpc --enable-python-bindings make && make install
note: You can also use jhbuild. It's in the build files of sugar
Creating an account
This is for the TnyAccountStore implementation of the libtinymail-olpc platform implementation (Jul 31 2006). You can find it here
mkdir -p $HOME/.tinymail/accounts/
IMAP
vi $HOME/.tinymail/accounts/01
[tinymail] type=store proto=imap hostname=IMAPSERVER user=USERNAME name=OLPC IMAP test
Maildir
vi $HOME/.tinymail/accounts/02
[tinymail] type=store proto=maildir url_string=maildir:///home/user/.mail/Maildir name=OLPC Maildir test
Using the Python bindings
This example will use this Python demo application.
cd tests/python-demo/ export PYTHONPATH=/opt/tinymail-olpc/lib/python2.4/site-packages/tinymail-1.0 python tinymail-python-test.py