#11 binascii.Error: Incorrect padding

[Lele Gaifax]

I'm on a Debian sid, with python-imaplib2 version 2.55-1 and offlineimap version 7.0.7+dfsg1-1.

One of my remote IMAP source, I keep getting the following traceback:

  File "/usr/share/offlineimap/offlineimap/accounts.py", line 271, in syncrunner
    self.__sync()
  File "/usr/share/offlineimap/offlineimap/accounts.py", line 334, in __sync
    remoterepos.getfolders()
  File "/usr/share/offlineimap/offlineimap/repository/IMAP.py", line 452, in getfolders
    imapobj = self.imapserver.acquireconnection()
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 528, in acquireconnection
    self.__authn_helper(imapobj)
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 431, in __authn_helper
    if func(imapobj):
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 360, in __authn_plain
    imapobj.authenticate('PLAIN', self.__plainhandler)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 705, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 1692, in _simple_command
    return self._command_complete(self._command(name, *args), kw)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 1418, in _command
    literal = literator(data, rqb)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2283, in process
    ret = self.mech(self.decode(data))
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2316, in decode
    return binascii.a2b_base64(inp)

Inspecting the case with pdb, I found that the provider responds with the string "go ahead" to the AUTHENTICATE command, obviously an invalid base64 content.

For now I inserted a quick&dirty hack into IMAP4._command():

       while True:
            # Wait for continuation response

            ok, data = crqb.get_response('command: %s => %%s' % name)
            if __debug__: self._log(4, 'continuation => %s, %s' % (ok, data))

            # NO/BAD response?

            if not ok:
                break

            # lele's hack
            if data == 'go ahead': data = ''

            # Send literal

that seems to fix the problem.

Is this something imaplib2 should/could handle in a better way, or is the provider completely wrong in its response?

Thank you in advance for any information!

[Piers Lauder]

Hi,

While the response "go ahead" is normal for "continuation" responses, in the case of the AUTHENTICATE command being processed in your traceback, the IMAP RFC states:

"The authentication protocol exchange consists of a series of
  server challenges and client responses that are specific to the
  authentication mechanism.  A server challenge consists of a
  command continuation request response with the "+" token followed
  by a BASE64 encoded string. "

The problem here is that "go ahead" is clearly not a BASE64 encoded string.

I think your provider server has been incorrectly coded. Which may be why you are the first person I've ever known to suffer from this :-)

As a better place for your fix - may I suggest moving that test into the authenticator decode method - just don't try passing "go ahead" to binascii. The test will get triggered far less frequently there.

Piers Lauder

[AELawrence]

I have also encountered this same problem with a major UK isp. Experience shows that there is minimal chance of getting anything done about their broken imap server. Contacting anyone there who even knows what an imap server is extremely difficult.

I am sure others have encountered this problem without understanding what is wrong.

[AELawrence]

On Sun, Mar 05, 2017 at 01:09:52AM +0000, Piers Lauder wrote:

Ok, I agree imaplib should be kind to bad implementations of the RFC in this case, so I'll add an appropriate fix....

Great. You might note my post here:

https://community.bt.com/t5/Email/Imap-server-mail-btinternet-com-violates-the-IMAP-protocol/m-p/1723196/highlight/true#M50372

ael

[Piers Lauder]

Ok, I agree imaplib should be kind to bad implementations of the RFC in this case, so I'll add an appropriate fix....

[Piers Lauder]

Fixed in versions 2.57 / 3.05

[Lele Gaifax]

Thank you!

[Gennaro Oliva]

I had the same problem recently and I had to change the condition to:
if data == b'go ahead' or data == 'go ahead':
Please update your code.