Another stab at IMAP IDLE

Ethan Glasser-Camp glasse at
Tue Nov 30 14:03:39 GMT 2010

Hi list,

IMAP IDLE was implemented in OfflineIMAP once a long time ago, but it 
relied on imaplib2 instead of imaplib, and this was apparently a source 
of stability issues for some users, so IDLE was dropped, as was 
imaplib2. For more on this exciting story, see episode 12:

When last we left our heroes[0], alternatives in order to support IMAP 
IDLE were:

1. add IDLE support to imaplib.

2. fix the bugs in imaplib2.

3. port OfflineIMAP over to something else entirely, for example 
Twisted's IMAP library.


Twisted's IMAP library doesn't support IDLE yet either, so that's 
probably the hardest of the three options. And considering that Piers 
Lauder is the author of both imaplib and imaplib2, I think the best 
implementation of imaplib + IDLE is likely to be imaplib2. So that 
leaves us with choice 2 as the best way forward for IMAP support in 
Python. This means fixing bugs in multithreaded code, which I'm not 
crazy about, but I really want IDLE support!

Based on this rationale I decided to de-revert the commits that removed 
IMAP IDLE from offlineimap, and merge in a new version of imaplib2. I 
have run it a few times successfully, but it's still a work in progress. 
If you're interested, it's the readd-idle branch of my github fork of 


P.S. As it happens, I believe based on cursory examination of the source 
that at least some of the bugs people experienced with imaplib2 have 
been fixed. For example, Debian bug 536329 includes a patch that appears 
to be applied to imaplib2, and Debian bug 536156, about zero-length 
messages, may be addressed by "0 read detection" which was added to 
imaplib2 in June 2010. Which leaves "Sync hangs without any kind of 
error message". There's a message that "Improved timeout handling" was 
added to imaplib2 in October 2010, and I'm definitely seeing connections 
time out, but I don't think it's solved entirely.

More information about the OfflineIMAP-project mailing list