Discussion: long-term maintenance plan for imaplib2 dependency

[lb803]

Hi everyone,

While investigating how TLS protocol versions are handled in OfflineIMAP (specifically to see whether TLS 1.3 can be required explicitly), I ended up looking into the state of the imaplib2 dependency.

As far as I can tell, the imaplib2 project has seen relatively little recent maintenance, and Jazzband (its current steward) is itself currently in the process of winding down.

I was wondering whether it would be useful to discuss a longer-term plan for maintaining imaplib2.

Some possible questions:

• Is there already an active maintainer or successor plan for imaplib2?
• Would it make sense for the OfflineIMAP project to take a more active role in maintaining the dependency?
• If upstream maintenance becomes unavailable, would a project-owned fork be a reasonable option?

I'm mainly interested in starting the conversation and understanding the current thinking around this dependency. If additional maintenance effort is needed, I would be interested in helping with that work.

Thanks!

[keithbowes]

The deprecation of upstream imaplib2 is unfortunate. I've actually made a few changes to it for my package in COPR:

1. Replacement of socket.sslerror with a Python 3 equivalent.
2. TLS 1.3 support. This required changing to the Python's new TLS API, as the old one that imaplib2 uses doesn't support TLS 1.3.
3. Ranges of accepted SSL/TLS versions. For example for my Hotmail account, I have ssl_version = ,tls1_2, i.e. any supported version of SSL/TLS up to TLS 1.2. My Gmail account however uses ssl_version = tls1_2, (TLS 1.2 or higher, since it, unlike Hotmail, doesn't have trouble handling TLS 1.3; Hotmail might not either anymore, as this configuration was from years ago). That is, the semantics of ssl_version changes slightly from ssl_version = <version> to ssl_version = <min-version>[,<max-version>].

Unfortunately, though, pull requests aren't handled upstream very well, so I've been unsuccessful in getting these changes upstream. BTW, imaplib2 used to be bundled with offlineimap. Fedora bundles an old version of imaplib2 in its package. I wonder though if it's even worth maintaining imaplib2. Is there really anything imaplib2 can do that modern imaplib still can't? Maybe it would be a worthwhile to investigate porting to standard imaplib instead of relying on an abandoned dependency that might not even be needed anymore. Also, the rfc6555 package has been abandoned; Fedora patches offlineimap to remove support for it entirely but for my package, I keep it in, as long as rfc6555 still works with modern versions of Python.

[thekix]

Probably we should create an interface between imaplib2 and offlineIMAP and then include a new IMAP library. The dependency between imaplib2 and offlineIMAP is very hard

[lb803]

Probably we should create an interface between imaplib2 and offlineIMAP and then include a new IMAP library. The dependency between imaplib2 and offlineIMAP is very hard

I looked into this idea and I'm quite optimistic that an adapter could work.

The initial version would likely not include the concurrency features provided by imaplib2, so it could be somewhat slower than the current implementation. However, I am not clear whether OfflineIMAP3 actually depends on those features for performance in practice and support for concurrent operations could always be added to the adapter later if needed.

Would an adapter with this scope be something you would consider reviewing as a PR? @thekix