Ignore some malformed XLIST replies

[thebodzio]

Recently I stumbled upon some server (reportedly Dovecot) giving quite bizarre response to XLIST command. Here's an excerpt from this response captured in terminal (openssl s_client):

2 XLIST "" "*"
* XLIST (\HasChildren \) "." "Archive"
* XLIST (\HasNoChildren \) "." "Archive.2020"
* XLIST (\HasNoChildren \) "." "Archive.2021"
* XLIST (\HasNoChildren \) "." "Courses"
* XLIST (\HasNoChildren \Draft) "." "DRAFTS"
* XLIST (\HasNoChildren \Inbox) "." "INBOX"
…
2 OK Completed

Evidently flags are malformed in this case, but I don't believe this is an unrecoverable problem. Granted, this is not standard compliant (as long as XLIST can be so), but it could be handled gracefully, much like malformed HTML by a web browser. Unfortunately mailimap_response_parse called by mailimap_xlist fails horribly with parser error. Wouldn't it be more prudent to consume the “empty” flag in front of closing parenthesis and simply ignore it, than to throw a final error? Perhaps a different kind of error could be reported in such situation, like “malformed response”, that would both warn the user and make recovery possible (we would still get usable folder list)?

[dinhvh]

Could you also report the issue on Dovecot end? I'll investigate what we can do on libetpan's end.

[thebodzio]

Actually, it's a good idea 👍. I will do so.

Thank you for taking interest!

[thebodzio]

I mentioned the problem on the Dovecot mailing list and got the following answer:

I don't know what home.pl uses, but Dovecot's XLIST command is simply an alias for the LIST command. There are no differences at all in the output. Dovecot even outputs untagged LIST replies rather than XLIST replies.

So, I think we can rule that one out.