homepage

I'm running into a problem with imaplib where it is unable to download a
message. The example code at
http://www.python.org/doc/current/lib/imap4-example.html easily
demonstrates the problem. 
#!/usr/bin/python
import getpass, imaplib
M = imaplib.IMAP4("my.imap.host.tld")
M.login(getpass.getuser(), getpass.getpass())
M.debug = 5
M.select("msg-test")
typ, data = M.search(None, 'ALL')
for num in data[0].split():
 typ, data = M.fetch(num, '(RFC822)')
 print 'Message %s\n%s\n' % (num, data[0][1])
M.close()
M.logout()
The majority of the messages transfer correctly, but some do not. I've
put 3 messages in the 'msg-test' folder, and one of them causes the
error below. 
Traceback (most recent call last):
 File "test.py", line 9, in <module>
 typ, data = M.fetch(num, '(RFC822)')
 File "/usr/lib/python2.5/imaplib.py", line 437, in fetch
 typ, dat = self._simple_command(name, message_set, message_parts)
 File "/usr/lib/python2.5/imaplib.py", line 1055, in _simple_command
 return self._command_complete(name, self._command(name, *args))
 File "/usr/lib/python2.5/imaplib.py", line 887, in _command_complete
 raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: FETCH => unexpected response: ')'
imaplib.py has a comment in _get_tagged_response:
 # Some have reported "unexpected response" exceptions.
 # Note that ignoring them here causes loops.
 # Instead, send me details of the unexpected response and
 # I'll update the code in `_get_response()'.
I can not provide access to the imap host, but I can help debug wherever
possible. 
The most recent log messages are in the file attachment.

Can you provide the message or messages which cause the problem when
they are put in the IMAP server? Can you also provide information on
what IMAP server software and version is being used?

I can recreate this at the moment with the attached mail. I downloaded
the mail using alpine's "Export". I don't know what other way I would
have to get it.
I have replaced many company names with XYZ and such, simply to
anonymize the message somewhat.

This is the stderr from the test case above. Only modification is the
mailbox is 'my-test'.

> Can you provide the message or messages which cause the problem 
> when they are put in the IMAP server?
See attached above
> Can you also provide information on what IMAP server software 
> and version is being used?
Its a lotus notes server. Just those 2 words are quite likely to make
you think "server bug". The only reason I have to not think that is
that the only other imap client i've tested (alpine and pine) works
fine. So if indeed it is a server bug, its one that alpine has worked
around.

I'm also getting the same error retrieving a message through IMAP from a
Lotus Notes server.
Traceback (most recent call last):
 File "mail.py", line 152, in <module>
 if 'setup' == argument: setup()
 File "mail.py", line 61, in archive
 for message in imapBox.read(includes=includes,
excludes=[mail_store_imap.folder_trash]):
 File "/var/www/pylons/scout/scout/lib/mail_store_imap.py", line 89, in
read
 returnCode, data = self.server.fetch(messageIndex, '(RFC822)')
 File "/usr/lib/python2.5/imaplib.py", line 437, in fetch
 typ, dat = self._simple_command(name, message_set, message_parts)
 File "/usr/lib/python2.5/imaplib.py", line 1055, in _simple_command
 return self._command_complete(name, self._command(name, *args))
 File "/usr/lib/python2.5/imaplib.py", line 887, in _command_complete
 raise self.abort('command: %s => %s' % (name, val))
imaplib.abort: command: FETCH => unexpected response: ')'

Using a different format, it seems the message involves cryptographic
keys signed by Lotus Notes?
>>> server.fetch(407, '(BODY.PEEK[HEADER] FLAGS)')
To: person1@place.com
Subject: subject
Message-ID: <xxx@place.com>
Date: 2008年10月28日 17:53:22 -0400
From: person@place.com
Content-Type: multipart/mixed; boundary="=_mixed 007839E2852574F0_="
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
X-MIMETrack: S/MIME Sign by Notes Client on Person(Release
7.0.2|September 26, 2006) at 10/28/2008 05:53:11 PM,Serialize by Notes
Client on Person(Release 7.0.2|September 26, 2006) at 10/28/2008
05:53:11 PM,Serialize complete at 10/28/2008 05:53:11 PM,S/MIME Sign
failed at 10/28/2008 05:53:11 PM: The cryptographic key was not
found,S/MIME Sign by Notes Client on Person(Release 7.0.2|September 26,
2006) at 10/28/2008 05:53:19 PM,Serialize by Notes Client on
Person(Release 7.0.2|September 26, 2006) at 10/28/2008 05:53:19
PM,Serialize complete at 10/28/2008 05:53:20 PM,S/MIME Sign failed at
10/28/2008 05:53:20 PM: The cryptographic key was not found

Has this been determine as a server bug or a bug with imaplib? I am not able to reproduce this bug with Gmail. Do I need to use it with Lotus Server to recreate it?

I'm guessing you do. On the other hand, I fixed a get_response bug a few months ago...it doesn't sound related from the description, but if someone can arrange to test against a Lotus server and can't reproduce the bug, testing again with an older version of imaplib might then reproduce it, and prove that it was fixed.

Is imaplib choking on the IBM-specific X-MIMETrack header? Is Lotus Notes properly formatting the multi-line headers? Can RFC822 headers contain the PIPE | symbol?

I spent the last 2 hours trying to setup a Lotus Server, which is ending up to be a lot more work then I thought in order to test this bug.
Is there anyway I can get a test Lotus account on a Lotus Server to test this bug?

Hi Lita,
I no longer have access to a Domino server.
I'm not sure whether there are enough users trying to access Domino with imaplib for this to warrant investigation.
RHH

Hi Roy,
Oh I see. Should we close this out as "Won't Fix" due to the fact that we
aren't sure how many users are using this with Domino servers?
Lita
On Fri, Jul 18, 2014 at 8:52 AM, Roy Hyunjin Han <report@bugs.python.org>
wrote:
>
> Roy Hyunjin Han added the comment:
>
> Hi Lita,
>
> I no longer have access to a Domino server.
>
> I'm not sure whether there are enough users trying to access Domino with
> imaplib for this to warrant investigation.
>
> RHH
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1598>
> _______________________________________
>

Yes, I think closing this issue is reasonable. If the error reappears, we can just reopen it.