IMAP 'UID FETCH' response parsing error about libetpan HOT 7 OPEN

Hey @dsanghan, the fix consists of a number of changes in "src/low-level/imap/mailimap_parser.c".

I'd rather just push my branch but here it is anyways: mailimap_parser.zip

from libetpan.

@dinhvh if you could add me as a contributor I can make a PR with a workaround

from libetpan.

FYI: I have also created an issue on Apple’s developer site since it’s an iCloud issue and eventually, Apple should fix it on their side:

iCloud IMAP server bug

from libetpan.

Ok, some progress. I'm now looking at mailimap_msg_att_parse_progress where it tries to parse the message after the message sequence number and FETCH identifier (* 7027 FETCH) have been successfully parsed.

The call stack is now:

mailimap_msg_att_parse_progress
mailimap_message_data_parse_progress
mailimap_response_data_parse_progress
mailimap_cont_req_or_resp_data_parse_progress
mailimap_struct_multiple_parse_progress
mailimap_response_parse_progress
mailimap_response_parse_with_context
mailimap_parse_response
mailimap_uid_fetch_qresync_vanished
mailimap_uid_fetch_changedsince
mailimap_uid_fetch

It passes mailimap_oparenth_parse successfully, then calls mailimap_struct_spaced_list_parse_progress and that too returns with no error.

However, it now expects a closing parenthesis ) when the stream is still at ENVELOPE (, and this is where it fails. So it seems ENVELOPE is unsupported at this point.

I'll dive deeper into mailimap_struct_list_parse_progress next.

from libetpan.

And more progress: it seems to choke on an ENVELOPE's messageid containing quotes:

"<"392889836.11.1529401004417.JavaMail.Redacted"@Redacted>"

mailimap_env_message_id_parse uses mailimap_nstring_parse which encounters the first " after the string opens and concludes that that must be the end of the string and therefore the messageid.

Consequently, mailimap_cparenth_parse fails because the next character in the stream is not a ) concluding the ENVELOPE but the continuation of the messageid, namely <

from libetpan.

Looking at the RFC, the formal syntax does not seem to allow DQUOTE's in the envelope messageid (except when properly escaped, which in this case, they are not):

env-message-id  = nstring
nstring         = string / nil
nil             = "NIL"
string          = quoted / literal
literal         = "{" number "}" CRLF *CHAR8 ; Number represents the number of CHAR8s
quoted          = DQUOTE *QUOTED-CHAR DQUOTE
QUOTED-CHAR     = <any TEXT-CHAR except quoted-specials> / "\" quoted-specials
TEXT-CHAR       = <any CHAR except CR and LF>
quoted-specials = DQUOTE / "\"

But alas, here we are.

from libetpan.

@BasTossings could you please share the fix?

from libetpan.