[Python-bugs-list] [ python-Bugs-619732 ] imaplib fails with literals in LIST resp

noreply@sourceforge.net noreply@sourceforge.net
Tue, 15 Oct 2002 11:21:41 -0700


Bugs item #619732, was opened at 2002-10-07 09:53
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Goerzen (jgoerzen)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib fails with literals in LIST resp

Initial Comment:
Hello,

imaplib is behaving weirdly when a LIST response
contains literals -- the {25} sort of syntax.

I have encountered a server in the wild that returns
the folder name part of the response as a literal.

imaplib returns a different sort of result for the two
cases.

Consider this snippet from the imaplib debug log from a
LIST response:

DEBUG[imap]:   30:09.81 untagged_responses[LIST] =>
['() "\\" Admin', ('() "\\" {19}',
'Admin\CamillaHansen')

That is:

result[0] = '() "\\" Admin'
result[1] = ('() "\\" {19}', 'Admin\CamillaHansen')

Yes, result[0] is a string, and result[1] is a *tuple*!
 And moreover, the tuple even contains the {19}.  This
is silly.  Both are presenting the same data.  Both
should be returned the same way -- possibly as a tuple
to start with.  There is no reason that the client
progrma should have to strip out the {19}, nor that it
should have to check whether the data being returned is
a string or a tuple.  imaplib should do all the
necessary processing internally.

-- John


----------------------------------------------------------------------

>Comment By: John Goerzen (jgoerzen)
Date: 2002-10-15 13:21

Message:
Logged In: YES 
user_id=491567

I am attaching a full logfile from OfflineIMAP 3.99.1  that
demonstrates this problem.  It uses imaplib with Debug = 5.

----------------------------------------------------------------------

Comment By: Piers Lauder (pierslauder)
Date: 2002-10-11 06:28

Message:
Logged In: YES 
user_id=196212

Certainly the wrong behaviour!

In order to nail down the source of the problem, would you
kindly
run "imaplib.py -d5 ..." in a way that demontrates the bug
and email me with the entire output? (Send it to
<piers@communitysolutions.com.au>)

That should make clear why the code that deals with the
{nnn} form isn't picking this up.

Thanks.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619732&group_id=5470