bcoe / imaplib2

Fork of Piers Lauder's imaplib2 library for Python.

Threaded Python IMAP4 client

Deprecated

Repo moved to https://github.com/imaplib2/imaplib2

About

Based on RFC 3501 and original imaplib module.

This is a version of imaplib that uses threads to allow full use of the IMAP4 concurrency features, and to de-couple a user of imaplib from i/o lags, except where explicitly allowed.

About this Fork

This is a fork of Piers Lauder's imaplib2 library hosted here: http://sourceforge.net/projects/imaplib2/

I created this fork because I wanted to submit the library to PyPI. An attempt will be made to keep it up-to-date with the original.

imaplib2's Issues

Fix import paths

Right now if I want to use imaplib2 instead of doing this:

from imaplib2 import IMAP4_SSL
M = IMAP4_SSL('imap.gmail.com')

I have to do this:

from imaplib2 import imaplib2
M = imaplib2.IMAP4_SSL('imap.gmail.com')

I believe this should be fixed because imaplib2 is supposed to be a drop-in replacement for imaplib

Python 3 version stopped working, getting a Socket Error

A few days back imaplib2 simply stopped working: immediately after the class is instantiated, I get a socket error and the connection is closed, which makes login impossible. I am not aware of any changes in Python or the socket module.

Tested on Ubuntu MATE 17.10 i386 with python 3.6, 3.5 and 3.4 using the latest (3.05) version, using several IMAP mail providers.

Here is a small test and the result:

import imaplib2

oImap = imaplib2.IMAP4_SSL('imap.gmail.com', 993, debug=4)

  35:34.18 MainThread imaplib2 version 3.05
  35:34.18 MainThread imaplib2 debug level 4, buffer level 3
  35:34.34 MainThread connected to imap.gmail.com on port 993
  35:34.34 imap.gmail.com writer starting
  35:34.35 imap.gmail.com reader starting using poll
  35:34.35 MainThread _request_push(continuation, welcome, {}) = b'CPNE0'
  35:34.35 imap.gmail.com reader poll => [(13, 1)]
  35:34.35 MainThread welcome:b'CPNE0'.ready.wait
  35:34.35 imap.gmail.com reader rcvd 69
  35:34.35 MainThread _close_threads
  35:34.35 imap.gmail.com reader < b'* OK Gimap ready for requests from xxx\r\n'
  35:34.35 imap.gmail.com writer finished
  35:34.35 MainThread call shutdown
  35:34.35 imap.gmail.com reader poll => [(13, 17)]
  35:34.35 imap.gmail.com reader last 20 log messages:
  35:34.34 imap.gmail.com writer starting
  35:34.35 imap.gmail.com reader starting using poll
  35:34.35 MainThread _close_threads
  35:34.35 imap.gmail.com writer finished
  35:34.35 MainThread call shutdown
  35:34.35 imap.gmail.com reader socket error: <class 'ValueError'> - Read on closed or unwrapped SSL socket.
  35:34.35 imap.gmail.com reader finished
  35:34.45 imap.gmail.com handler starting
  35:34.45 imap.gmail.com handler terminating: 'Terminated'
  35:34.45 imap.gmail.com handler welcome:b'CPNE0'.ready.set
  35:34.45 imap.gmail.com handler state_change_free.set
  35:34.45 imap.gmail.com handler finished

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "xxx/imaplib2.py", line 2093, in __init__
    IMAP4.__init__(self, host, port, debug, debug_file, identifier, timeout, debug_buf_lvl)
  File "xxx/imaplib2.py", line 375, in __init__
    self.welcome = self._request_push(name='welcome', tag='continuation').get_response('IMAP4 protocol error: %s')[1]
TypeError: 'NoneType' object is not subscriptable

please pull in version 2.55 from sourceforge

new version available 2.55

AttributeError caused by queue.get_nowait() not raising queue.Empty

There is a documented queue "feature" that caused me some intermittent problems.

Under certain situations, "there may be an infinitesimal delay before the queue’s empty() method returns False and get_nowait() can return without raising queue.Empty" (see the second note here). This "feature" occaisionally causes an AttributeError to be raised on line 1728 because get_nowait() returns None (which clearly doesn't have an abort() method).

One workaround is to just catch the AttributeError and break, but this leaves the loop with self.ouq.empty() == True. I suspect that the correct solution is to catch the AttributeError and pass until ouq.empty() starts returning False, that is:

    # Line 1725 here
    while not self.ouq.empty():
        try:
            self.ouq.get_nowait().abort(typ, val)
        except queue.Empty:
            break
        except AttributeError:
            # See notes at https://docs.python.org/3.4/library/multiprocessing.html#pipes-and-queues
            pass  # Soon enough, self.ouq.empty() should become True
    self.ouq.put(None)

Of course, this route risks a hang if the "infinitesimal delay" is not, in fact, infinitesimal. If that's the case, a break may be more appropriate. Thoughts?

Precise the licence

Hi
What is the licence of this library? Could you please add a LICENCE file?
Thanks in advance

Please upload tests to PyPI

Title says it all...

Enable travis on imaplib2

I've got a PR which includes some minor tests, it would be nice to automate these with travis so I can demonstrate them here.

Python 3 support

Thoughts on adding a python 3.x compatible package to PyPi?

imaplib2 UnicodeDecodeError 'utf-8' codec can't decode byte 0x81 in position 21: invalid start byte

imaplib2.py line 1860,

line_part += data[start:].decode()

...

line_part, start, line = \
                            '', stop, line_part + data[start:stop].decode()

to

line_part += data[start:].decode(errors='replace')

...

line_part, start, line = \
                            '', stop, line_part + data[start:stop].decode(errors='replace')

if mail is b'Content-Type: text/plain; charset=gb18030; format=flowed\r\n'

how to ?

Hand over Maintainership for PyPi (to me)

Hi, I need imaplib2 for another project and sadly, this version is out of date. Since you expressed you don't want to maintain this package any longer, I'd like to become the (interim?) maintainer for it on pypi and github.

To be frank, I don't have experience with PyPi at this time, but imaplib2 is a slow moving target I feel I can handle.

Please let me know if you want me to take over and if so how we should continue.

Thanks,
tobias

Please update to version >= 2.47 from sourceforge

Hi! Could you please update this mirror to the newest version from sourceforge? It contains some Python 3 related fixes and your repository seems to be somewhat more discoverable due to being on PyPI.

Thanks for your work!

Make a new release into PyPi

Can you bump the version and make a new release into PyPi?

This is to make the Python 3 compatibility (https://github.com/bcoe/imaplib2/pull/4/files) code in an official version!