[Zope-dev] IMAP Server

[Michel Pelletier]

Brad,

Hi, I think I recall you being interested in writing an IMAP server in
Python.  I have begun writing an IMAP server, and I was curious if you'd
like to join me in the development.

I have an IMAP server based on asychat, my own protocol handler, and
ZODB.  Zope itegration is imminently planned.  Below is the readme.

I'll be setting up a site on starship tonight/tommorow to host the
project.  Are interested?

-Michel



Test: What the hell should I call this thing?

  This thing is an IMAP server written in Python.  It consists of a
  simple asychat dispatcher, a generic protocol handler class, some
  mail objects, and an abstract backend storage mechanism.  This thing
  requires the following software:

    asyncore/asynchat  - Standard with Python.  Also comes with
                         ZServer (Zope)

    ZODB - The default namespace storage for this thing requrires
           ZODB.  The backend is totaly plugable however, so I don't
           see any reason why some other mapping storage cannot be
           used (like gdbm, sleepycat berkeley, etc...)

    Currently, ZODB is not shipped seperatly from Zope, so this thing
    requires Zope to run.

    In fact, this thing hijacks quite a bit of Zope.  To get it fired
    up, ungzip and untar the file into your Zope top level directory.

    edit lib/python/start_imap.py, change the path.append to reflect
    your medusa directory.  I know, this is an ugly hack, bear with it 
    for now.

    A Sample interaction (this is for real! not a simulation!):

      [michel@localhost python]$ telnet localhost 143
      Trying 127.0.0.1...
      Connected to localhost.
      Escape character is '^]'.
      * OK IMAP4rev1 v11.241 Welcome
      1 capability
      * CAPABILITY IMAP4 IMAP4rev1 NAMESPACE AUTH=LOGIN XUNDO
      1 OK CAPABILITY completed
      2 login mike pass
      2 OK  LOGIN complete
      2 create aNewBox
      2 OK create completed
      3 select aNewBox
      * 0 EXISTS* 0 RECENT* [UNSEEN 1] Messages 1 is first unseen
      * [UIDVALIDITY 1] UIDs valid
      * FLAGS (\Flag1 Flag2)* [PERMANENTFLAGS %s] Limited
      3 OK [READ-WRITE] SELECT completed
      5 close aNewBox
      5 OK close completed
      6 namespace
      * (("~" "/")) (("Public/" "/")) (("" "/")) 
      6 OK namespace completed
      7 logout
      * BYE BYE logging out
      7 BYE LOGOUT completed
      Connection closed by foreign host.


    Because it is based on really cool peices of software, this thing
    has a number of benefits.

      High performance --

        Ok that's not proven yet, but asyncore in general has been
        proven pretty speedy and the select() model is regarded as a
        high performance solution.

        Further, then entire enchelada, if Zope itegration is not
        used, runs in one process space.  It can even run in the same
        ZServer thread space as a Zope server.

        ZODB database cache keeps commonly used objects in memory.
        Also, the entire IMAP mailbox namespace is used as keys to the 
        ZODB dict, so the namespace is kept in memory at all times.
        This makes listing and searching through mailbox names very
fast.

      Easy possbile Zope itegration --

        The storage backend for this server can be realized by a
        simple layer over a mapping storage like object.  So gbdm,
        berkley, or a bunch of Zope objects can be used to store mail
        objects.  If Zope were used, it would be possible for mail and
        mailbox objects to have web interfaces, and either interface,
        IMAP or HTTP (or XML-RPC, WebDAV and FTP) can manipulate the
        SAME objects.  It's the same old classic dream of
        multi-protocol publishing realized once again in IMAP.

        This has not been thought out much, specificly how the
        "security system" (tm) in this thing can interface with
        Zope's.  In the end, it might require medling the entire
        thingy into Zope's framework, but I want to avoid that if
        possible.

      ZODB provides plugable storage

        For now, this thing depends on ZODB for storage.  This has
        lots of benefits, for one, ZODB supports pluggable storage
        formats.  At the moment there are several, like FileStorage,
        BerkeleyStorage, DemoStorage and ReadOnly.  Digital Creations
        will likely in the future add other storage types, and this
        thing might as well let them do all the work.

      Fine grained multi-tasking

        Every client request and every response gives asyncore