The regexp in Response_code checks for the existence of [] characters. The problem is that the strings may contain [] characters. I attach debug log which shows the data received from server and what the python extracted from it.

You can see that the PERNANENTFLAGS is truncated and everything from the ] character is lost:

(\Answered \Flagged \Draft \Deleted \Seen OIB-Seen-OIB/Social Networking $Phishing $Forwarded OIB-Seen-OIB/Home OIB-Seen-OIB/Shopping OIB-Seen-INBOX OIB-Seen-OIB/Business OIB-Seen-OIB/Entertainment $NotJunk $NotPhishing $Junk OIB-Seen-[Gmail

Oops, forgot the file.

I was reading the RFC spec, and it looks like it doesn't specificy '[' and ']' are not allowed in the PERNANENTFLAGS names. 

I can try to add a fix for this. But if anyone else knows if you are not allowed to have '[' or ']' in flag names, please let me know.

I have a patch for this. With my patch, the debug output is fixed.

Here is a log of the output.

Thanks for the patch, Lita! Lita: I have some patch feedback for you at the end of this message.

--

Lita and I talked about this a bit via email; here's some additional context from that conversation:

There were a couple of questions to answer before working on a patch:

1. Are brackets allowed in flag names according to the RFC?
2. If brackets aren't allowed, do other popular IMAP services permit them anyway? If so, we should consider allowing them even though this deviates from the RFC.

To answer (1), my read of http://tools.ietf.org/html/rfc3501 is as follows:

a. Look at http://tools.ietf.org/html/rfc3501, search for PERMANENTFLAGS definition. Note use of "flag-perm" variable.

b. Search for "flag-perm". Find it on page 85, in section 9, Formal Syntax. This is describing the formal syntax in Backus-Naur Form (BNF).

c. flag-perm = flag / "\*"

d. flag = "\Answered" / "\Flagged" / "\Deleted" /
    "\Seen" / "\Draft" / flag-keyword / flag-extension
    ; Does not include "\Recent"

e. flag-keyword = atom

f. atom = 1*ATOM-CHAR

g. ATOM-CHAR = <any CHAR except atom-specials>

h. atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
    quoted-specials / resp-specials

i. resp-specials = "]"

My reading of this series of definitions is that "]" is not allowed in flag names.

To answer (2), Lita ran some tests against GMail's IMAP service and found that it does let you create flags containing "]".

--

Patch feedback:

1. Can you attach the script you used to probe GMail's IMAP service for what flag names were permitted?

2. Since this patch causes us to violate the RFC (but with good reason!), can you add a comment above the regex noting the violation and stating what characters we allow for flags and why?

3. This change need tests.

Yes! I agree, this change will need tests. I will start working on creating those now.

Here is test I did to create a flag with brackets.

import imaplib

mail = imaplib.IMAP4_SSL('imap.gmail.com')
mail.login('username@gmail.com', 'password') # Enter your login here
mail.select('test') # Mailbox selection. I have a test inbox with 6
                    # messages in it.
code, [msg_ids] = mail.search(None, 'ALL')
first_id = msg_ids.split()[0]
mail.store(first_id, "+FLAGS", "[test]")
typ, response = mail.fetch(first_id, '(FLAGS)')
print("Flags: %s" % response)
mail.close()
mail.logout()

Here is the code in order to see the bug.

imaplib.Debug = 5
mail = imaplib.IMAP4_SSL('imap.gmail.com')
mail.login(username, password) # Enter your login here
mail.select('test')

Just to make sure I understand: the issue is that gmail may produce flags with [] in them, and imaplib currently fails to process such flags when it receives them from gmail?  

In principle I think we would not want to allow imaplib to be used to create such flags unless the user specifies some sort of "I want to violate the RFC" flag (which they might want to do, for example, to run tests against gmail :)  But currently it looks like it can?  (I haven't looked at this in enough detail to be sure.)  If that's true we probably have to continue to allow it for backward compatibility reasons, but we should document the RFC violation and possible consequences (an IMAP server rejecting such flags).

Yeah, basically. The flags with [] characters are added to gmail (in my
case) by OtherInbox's Organizer app. I contacted them but haven't heard
back yet.

On Wed, Jul 16, 2014 at 4:07 PM, R. David Murray <report@bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Just to make sure I understand: the issue is that gmail may produce flags
> with [] in them, and imaplib currently fails to process such flags when it
> receives them from gmail?
>
> In principle I think we would not want to allow imaplib to be used to
> create such flags unless the user specifies some sort of "I want to violate
> the RFC" flag (which they might want to do, for example, to run tests
> against gmail :)  But currently it looks like it can?  (I haven't looked at
> this in enough detail to be sure.)  If that's true we probably have to
> continue to allow it for backward compatibility reasons, but we should
> document the RFC violation and possible consequences (an IMAP server
> rejecting such flags).
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue21815>
> _______________________________________
>

>
> R. David Murray added the comment:
>
> Just to make sure I understand: the issue is that gmail may produce flags
> with [] in them, and imaplib currently fails to process such flags when it
> receives them from gmail?
>
> This is correct. Gmail allows you to create flags with [], and the
Response_code regex doesn't process them properly.

> In principle I think we would not want to allow imaplib to be used to
> create such flags unless the user specifies some sort of "I want to violate
> the RFC" flag (which they might want to do, for example, to run tests
> against gmail :)  But currently it looks like it can?  (I haven't looked at
> this in enough detail to be sure.)  If that's true we probably have to
> continue to allow it for backward compatibility reasons, but we should
> document the RFC violation and possible consequences (an IMAP server
> rejecting such flags).
>
> Yes, currently we can. I've posted the code in order to do this. This is
basically the result.

>>> first_id = msg_ids.split()[0]
>>> mail.store(first_id, "+FLAGS", "[test]")
('OK', [b'1 (FLAGS (\\Seen Answered [test] NotJunk $NotJunk [Brackets]
[testing2]))'])

However, I would think it would be the server's job to uphold this rule,
not the library. The server should return with a BAD response, but right
now, Gmail allows you to do this.

Should we throw a warning in the "store" method? Otherwise, I can update
the documenation in the "store" method stating that having '[]' is allowed
but violates the RFC protocol.

> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue21815>
> _______________________________________
>

Postel's Law says: be conservative in what you do, be liberal in what you accept from others.  So the client should not violate the RFC when sending data to the server.  The server, on the other hand, by that law could accept "dirty" data if it can do something reasonable with it...except that in general the IMAP RFC in particular says "don't do that".  IMAP servers are supposed to be IMAP RFC sticklers, even when accepting input.  So gmail is broken for some definition of broken, and so is imaplib.

Since the code has been this way for a long time, and gmail does in fact accept it, I think a doc warning about []s violating the RFC should be sufficient; a warning would probably just be annoying to little real benefit.

Okay, sounds good. I will also create a patch in the documentation that explains this, as well as comment on the regex patch.

Here is a patch for test_imaplib.py, adding the test for brackets. It should fail with the current version of imaplib, but should pass with the imap_regex.patch.

Updated the documentation in imaplib.rst to describe the RFC violation.

Updated my regex patch to include a comment about how we are violating the RFC and allowing all characters rather thane excluding the ] character.

pinging for another review. I have included tests for the patch as well as documentation!

Thanks for the patches Lita, however it's better if you can upload a single patch with all the required changes.  This will make it easier to apply/review it.

Sure, let me combine it into one change.

Here is the patch merged together. I apologize for not getting it to you sooner.

Lita thanks for your patch!. Are you able to address berkerpeksag comments from review? Otherwise if you don't mind I'll take it over and I'll do that.

Hi Maciej,

I am not seeing berkerpeksag review...? What was his comment? I apologize, but I haven't used the bug tracker in awhile.

Hi Lita, my review comments are at http://bugs.python.org/review/21815/ (sorry, I forgot to add a comment here after I made the review)

Lita always look for them next to your uploaded file, there's a review link that points to Rietveld Code Review Tool. There you'll find all those information, just for future use :)

Hey Lita, final call ;) Can you address berkerpeksag comments from review? Otherwise, I'm planning to take ownership of this issue and resubmit your patch with addressed comments.

I apologize, I completely forgot. I will do it this week. Thanks for the
reminder!

Perfect, thanks!

Had some trouble setting up my dev environment for Python. Definitely going
to work on it today and tomorrow.

On Tue, Dec 8, 2015 at 12:33 PM, Maciej Szulik <report@bugs.python.org>
wrote:

>
> Maciej Szulik added the comment:
>
> Perfect, thanks!
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue21815>
> _______________________________________
>

Lita if you still have problems or want to ask questions reach out to me on IRC, I'm soltysh on freenode.

Applied the changes that berkerpeksag made. Please review, and let me know if further changes need to be made.

Lita can you please apply the changes from latest review (from SilentGhost). Especially the one regarding newline, which currently fails to apply this patch on default. If all those will be cleaned I'll recommend this patch for David for inclusion.

Sounds good.

On Tuesday, December 22, 2015, Maciej Szulik <report@bugs.python.org> wrote:

>
> Maciej Szulik added the comment:
>
> Lita can you please apply the changes from latest review (from
> SilentGhost). Especially the one regarding newline, which currently fails
> to apply this patch on default. If all those will be cleaned I'll recommend
> this patch for David for inclusion.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org <javascript:;>>
> <http://bugs.python.org/issue21815>
> _______________________________________
>

Here is a patch after SlientGhost's review. I have added back the newline and included the comments for the imaplib documentation.

I've checked the patch: it looks good, applies cleanly to latest default and passes all the tests. I'm ok with merging this as is.

When you think a patch is ready for commit, you can move it to commit review, which will put it in my queue (not that I've been getting to that very fast lately, but I'm going to try to be better about it...)

I was looking for that but I missed the Stage field, thanks David will remember for the future :)

New changeset 54b36229021a by R David Murray in branch 'default':
#21815: violate IMAP RFC to be compatible with, e.g., gmail
https://hg.python.org/cpython/rev/54b36229021a

I rewrote the comments, and I changed the name of the test helper class from GmailHandler to BracketFlagHandler, since this is not gmail specific.  (There was a review comment about that that was missed, I guess).

I've applied this only to 3.6 because there is a backward compatibility concern, as I mention in the revised comments: if a server includes a ']' in the text portion, the new regex will parse it incorrectly.  (Which is why the rfc restriction exists in the first place.)  I'm hoping that this is very unlikely, but because it would be a nasty bug if it happens, I only feel comfortable applying it to 3.6.

Thanks Lita, and everyone who reviewed.

New changeset 53271aa4d84c by R David Murray in branch 'default':
#21815: Make the doc change match what I actually did.
https://hg.python.org/cpython/rev/53271aa4d84c