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