See #42

There is actually no easy way to set the timeout for the first socket connection.
We could just use the resp_timeout attribute of the IMAP4 class. Otherwise we could add another parameter to __init__.

There's nobody in the public members of the imaplib2 org at https://github.com/orgs/imaplib2/people .

I'm wondering who is active at maintaining the source code. One person? A team ? There are currently 2 PR not addressed.

There's no actual license file in this repository. However, according to the original project page on Sourceforge, the license seems to be CNRI Python License. I'm not a lawyer or something, but this license does not look proper to me. For example, the terms seem to cover the Python interpreter, not the Python package itself? And the copyright owner of the package seems to be the Corporation for National Research Initiatives?

So I'm proposing changing the license to any modern OSI-approved non-copyleft license, like MIT, BSD 3, etc. To change the license, it requires the code contributors of this repository to give consents.

As @jezdez stated in #13, the process of gathering consents should be open. Hence, let's use this issue to track the consents from the contributors:

• Alexander Kavanaugh (@kavdev)
• Benjamin E. Coe (@bcoe)
• David Keijser (@keis)
• Ilias Tsitsimpis (@iliastsi)
• John Molyneux (@johnmolyneux)
• Julien Cristau (@jcristau)
• [ ] Mark Hahnenberg (@mhahnenberg)
• Piers Lauder (consent through email)
• Rob Adams (@rfadams)
• Rodolfo García Peñas (@thekix)
• Thomas Grainger (@graingert)

If no one has a strong objection, let's change to the BSD 3-Clause MIT license. Please leave a message in this issue to give your consent to change to BSD 3-Clause MIT. Thank you!

I'm not familiar with other non-copyleft licenses, so if anyone has other suggestions, we can also discuss the alternatives in this issue. I'm fine with either MIT or BSD 3-Clause. If anyone has a strong favor over MIT or BSD 3-Clause, please indicate it.

Tested on various flavours of Ubuntu 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 "/usr/lib/python3/dist-packages/imaplib2.py", line 2093, in __init__
    IMAP4.__init__(self, host, port, debug, debug_file, identifier, timeout, debug_buf_lvl)
  File "/usr/lib/python3/dist-packages/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

Hey all, I noticed this is using Coveralls, could you please use Codecov instead to reduce the number of services?

Originally posted by @jezdez in #23 (comment)

Could this be related to too many IDLE calls in a session? My script waits for an email, reads/parses, and then goes back IDLE. This is the second time this error has happened. It happens somewhere around 12-15 hours since first connecting.

Traceback (most recent call last):
  File "paper_trader.py", line 303, in <module>
    try: run()
  File "paper_trader.py", line 300, in run
    gm_set_idle()
  File "paper_trader.py", line 141, in gm_set_idle
    gm.idle()
  File "/home/ubuntu/.local/lib/python3.7/site-packages/imaplib2/imaplib2.py", line 839, in idle
    return self._simple_command(name, **kw)
  File "/home/ubuntu/.local/lib/python3.7/site-packages/imaplib2/imaplib2.py", line 1643, in _simple_command
    return self._command_complete(self._command(name, *args), kw)
  File "/home/ubuntu/.local/lib/python3.7/site-packages/imaplib2/imaplib2.py", line 1396, in _command_complete
    typ, dat = rqb.get_response('command: %s => %%s' % rqb.name)
  File "/home/ubuntu/.local/lib/python3.7/site-packages/imaplib2/imaplib2.py", line 189, in get_response
    raise typ(exc_fmt % str(val))
imaplib2.imaplib2.IMAP4.abort: command: IDLE => socket error: <class 'OSError'> - Too many read 0
> /home/ubuntu/.local/lib/python3.7/site-packages/imaplib2/imaplib2.py(189)get_response()
-> raise typ(exc_fmt % str(val))

This issue tracks the implementation of the Jazzband guidelines for the project imaplib2

It was initiated by @graingert who was automatically assigned in addition to the Jazzband roadies.

See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

Feel free to ping a Jazzband roadie if you have any question.

TODOs

• Fix all links in the docs (and README file etc) from old to new repo
• Add the Jazzband badge to the README file
• Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
• Port tests to GitHub Actions (if not already there)
• Check if test coverage services work (e.g. Coveralls, Codecov, etc)
• Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/imaplib2/collaboration/)
• Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/imaplib2/users/)
• Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/imaplib2/integrations/)
• Fix project URL in GitHub project description
• Review project if other services are used and port them to Jazzband
• Decide who is project lead for the project (if at all)
• Set up CI for Jazzband project releases if needed and open ticket if yes
• open an issue at https://jazzband.co/roadies/issue for auto-release
• Change to an OSI-approved non-copyleft license (tracker: issue #18 )

Project details

Using the latest openssl (version 1.1.1), which supports TLS 1.3, imaplib2 fails to connect to (at least) GMail:

>>> import imaplib2                                                                       
>>> imaplib2.IMAP4_SSL(host="imap.gmail.com", ca_certs="/etc/ssl/certs/ca-certificates.crt")                                                                                         
Traceback (most recent call last):                                                        
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2182, in __init__             
    IMAP4.__init__(self, host, port, debug, debug_file, identifier, timeout, debug_buf_lvl)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 360, in __init__
    self.open(host, port)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2195, in open
    self.ssl_wrap_socket()
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 547, in ssl_wrap_socket
    self.sock = ssl.wrap_socket(self.sock, self.keyfile, self.certfile, ca_certs=self.ca_certs, cert_reqs=cert_reqs, ssl_version=ssl_version)
  File "/usr/lib/python2.7/ssl.py", line 949, in wrap_socket                              
    ciphers=ciphers)                                                                      
  File "/usr/lib/python2.7/ssl.py", line 617, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 846, in do_handshake
    self._sslobj.do_handshake()                                                           
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:726)     

This is because imaplib2 does not support SNI, and Google returns an invalid certificate in that case. Copying from here:

Some sites want to encourage the use of SNI and configure a default certificate that fails WebPKI authentication when the client supports TLS 1.3.

Forcing TLS 1.2 works as expected:

>>> import imaplib2
>>> imaplib2.IMAP4_SSL(host="imap.gmail.com", ca_certs="/etc/ssl/certs/ca-certificates.crt", ssl_version="tls1_2")                                                                   
<imaplib2.IMAP4_SSL object at 0x7f1865dec290>                                   

I already submitted this bug to the Debian bugtracker (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899102).

Apparently, connection to an IMAP host fails on at least armhf platforms (such as Raspberry Pi):

>>> import imaplib2
>>> c=imaplib2.IMAP4('imap.strato.de')
  26:45.17 imap.strato.de reader last 20 log messages:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 400, in __init__
    self.welcome = self._request_push(name='welcome', tag='continuation').get_response('IMAP4 protocol error: %s')[1]
TypeError: 'NoneType' object is not subscriptable

The same sequence of commands works like a charm on amd64. I tested both, 2.55 and 2.57.

Thank you for your help!

One thing I was wondering is the https://github.com/jazzband/imaplib2/blob/21ae2ed26d0ca66c683483d1bfdc7c3fb567a048/imaplib2/imaplib2.html file inside the imap2lib package.

Could this be converted to a Sphinx project? Maybe Pandoc allows auto-coverting it to rST or Markdown?

I would really like to have user facing docs on https://imaplib2.readthedocs.io/ so it's clear what the purpose of imaplib2 is. What do you think?

Originally posted by @jezdez in #13 (comment)

When trying to use imaplib2.py3 for python 3 on windows I get the following error.

14:55.51 MainThread imaplib2 version 3.05
  14:55.51 MainThread imaplib2 debug level 5, buffer level 3
  14:55.60 MainThread connected to imap.gmail.com on port 993
  14:55.60 imap.gmail.com writer starting
  14:55.60 imap.gmail.com reader starting using select
  14:55.60 MainThread _request_push(continuation, welcome, {}) = b'JEEP0'
  14:55.60 MainThread welcome:b'JEEP0'.ready.wait
  14:55.63 imap.gmail.com reader select => [1640], [], []
  14:55.63 imap.gmail.com reader rcvd 67
  14:55.63 imap.gmail.com reader < '* OK Gimap ready for requests from 89.212.201.191 u4mb45497943wmg\r\n'
  14:55.70 imap.gmail.com handler starting
Exception in thread imap.gmail.com handler:
Traceback (most recent call last):
  File "C:\Users\Jakob\AppData\Local\Programs\Python\Python39\lib\threading.py", line 950, in _bootstrap_inner
    self.run()
  File "C:\Users\Jakob\AppData\Local\Programs\Python\Python39\lib\threading.py", line 888, in run
    self._target(*self._args, **self._kwargs)
  File "F:\documents\coding_projects\2019\forwarding\v2\forwardingV2\imaplib3.py", line 1735, in _handler
    typ, val = line
ValueError: too many values to unpack (expected 2)

After a day of troubleshooting I think the source of the problem is _reader function.
It is (if I understand correctly) defined 2 ways - if hasattr(select_module, "poll") for linux or the other one for windows.
So I tried the same code on WSL and it worked fine.

This leads me to believe that there is some error in the version of _reader for windows (the one not using poll).

http=>https

I'm re-experiencing a problem that I reported years ago: I'm on a Debian sid system and I use offlineimap to keep a local copy of my incoming email. As reported in the references issue, fetching from one of my providers gives the following traceback:

2021-02-01 14:29:00 WARNING: ERROR: While attempting to sync account 'pec'
  Incorrect padding
2021-02-01 14:29:00 WARNING: 
Traceback:
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in syncrunner
    self.__sync()
  File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in __sync
    remoterepos.getfolders()
  File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line 648, in getfolders
    imapobj = self.imapserver.acquireconnection()
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 592, in acquireconnection
    self.__authn_helper(imapobj)
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 449, in __authn_helper
    if func(imapobj):
  File "/usr/share/offlineimap3/offlineimap/imapserver.py", line 375, in __authn_plain
    imapobj.authenticate('PLAIN', self.__plainhandler)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 691, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 1684, in _simple_command
    return self._command_complete(self._command(name, *args), kw)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 1404, in _command
    literal = literator(data, rqb)
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 2247, in process
    ret = self.mech(self.decode(data))
  File "/usr/lib/python3/dist-packages/imaplib2.py", line 2279, in decode
    return binascii.a2b_base64(inp)

Inspecting the case, I found that the bad value triggering the error is go ahead, that is, the very same case cured in the commit 3e87a66.

Dear @jazzband,

In first, I wish you a Happy New Year!

Can you add supports of:

• SCRAM-SHA-1
• SCRAM-SHA-1-PLUS
• SCRAM-SHA-256
• SCRAM-SHA-256-PLUS
• SCRAM-SHA-512
• SCRAM-SHA-512-PLUS
• SCRAM-SHA3-512
• SCRAM-SHA3-512-PLUS

You can add too:

• SCRAM-SHA-224
• SCRAM-SHA-224-PLUS
• SCRAM-SHA-384
• SCRAM-SHA-384-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

• SCRAM-SHA-1(-PLUS):
  -- https://tools.ietf.org/html/rfc5802
  -- https://tools.ietf.org/html/rfc6120

• SCRAM-SHA-256(-PLUS):
  -- https://tools.ietf.org/html/rfc7677 since 2015-11-02
  -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA

• SCRAM-SHA-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha-512

• SCRAM-SHA3-512(-PLUS):
  -- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

• RFC5056: On the Use of Channel Bindings to Secure Channels: https://tools.ietf.org/html/rfc5056
• RFC5929: Channel Bindings for TLS: https://tools.ietf.org/html/rfc5929
• Channel-Binding Types: https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml
• RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266

IMAP:

• RFC9051: Internet Message Access Protocol (IMAP) - Version 4rev2: https://tools.ietf.org/html/rfc9051

LDAP:

• RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

• RFC7804: Salted Challenge Response HTTP Authentication Mechanism: https://tools.ietf.org/html/rfc7804

2FA:

• Extensions to Salted Challenge Response (SCRAM) for 2 factor authentication: https://tools.ietf.org/html/draft-melnikov-scram-2fa

IANA:

• Simple Authentication and Security Layer (SASL) Mechanisms: https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

Linked to:

• scram-sasl/info#1

Since the library is Python 3-only we can skip that part.

The socket package has no sslerror module (see the doc here)
The ssl package has something close. Maybe there were a confusion between the two packages ?

So if an invalid ssl_version is given, the program crashes before raising the error.

To follow the convention of most of the Jazzband projects, future release versions will be managed by setuptools_scm.

Hi,

I was thinking about the idea of moving imaplib2 to the Python 3 standard libs. That idea was done by Maxim Khitrov here [1] but had some problems here [2]. I would like to propose it again.

I all of us agree it, we can start to update the impalib2 code to make the imaplib and imaplib2 interface compatible (for backward compatibility). We need check the imaplib patches that can apply in imaplib2,.... Perhaps we can send some patches to the imaplib standard lib.

What do you think?

Happy new year!
Best regards,
kix

[1] https://python-ideas.python.narkive.com/dgZhBV1Y/new-imaplib-implementation-for-python-3-2-standard-library
[2] https://python-ideas.python.narkive.com/dgZhBV1Y/new-imaplib-implementation-for-python-3-2-standard-library#post18

There is a bug in imaplib2 using IMAP4 tunnel. If we set the debug mode, then we get a crash here:

    if __debug__:
      if debug:
        self._mesg('connected to %s on port %s' % (self.host, self.port))

The reason is because self.port is set to None in a tunneled connection, then it raises an error. We need remove the debug mode for this connection type to avoid the crash.

The right code in imaplib2 should be:

    if __debug__:
      if debug & self.port != None:
        self._mesg('connected to %s on port %s' % (self.host, self.port))