search

dinhvh / libetpan

Mail Framework for C Language
www.etpan.org
Other
612 stars 284 forks source link

Ignore some malformed XLIST replies #403

Open thebodzio opened 3 years ago

thebodzio commented 3 years ago

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 commented 2 years ago

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

thebodzio commented 2 years ago

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

Thank you for taking interest!

thebodzio commented 2 years ago

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.