Syntax error in untagged FETCH response. Unexpected token: '\n' (Domino IMAP4 Server)

[zmarkusdev]

Hello.

I am getting another Fetch error with a specific mail:
Syntax error in untagged FETCH response. Unexpected token: '\n'

I think the error comes from an invalid IMAP Response from Domino IMAP4 Server again:

The error happens on line 3805 in ImapFolderFetch.cs, Mailkit expects a closing parameter, but a CR LF is given in the response.

Is this information enough?

The erronous e-mail is very big and contains much personal data, so sharing would not be possible over this channel, but I can send it to you in private if you need the logs!

Thanks!

[jstedfast]

If your theory is correct, then it probably means that your Domino server is specifying an incorrect data length for the message data which will be impossible for MailKit to work around.

Can you paste the entire FETCH response minus the message data?

e.g., it should look something like:

* 1 FETCH (BODY.PEEK[] {10000+}
--snip message data here--
 UID 2934)
N00000007 OK FETCH complete

Then, the next question, is if you paste the message data into a text file and remove the leading "S: " from the beginning of each line, what is the length that you get? Does it match the value between the curly braces at the end of the first line of the FETCH response?

[zmarkusdev]

Given in the curly braces are: 145080
Actually returned by the imap server are: 145092

I have debugged this e-mail and the parsing breaks at the \n of the line "...related...".
The difference of 12 digits are exactly the "\r\n UID 2934)" count, at which the parsing breaks, looks like a server bug to me.

* 2417 FETCH (BODY[] {145080}

-- snipped content--

--=_related 003CF6B5C12584B3_=--
UID 2934)
A00000007 OK FETCH completed

[jstedfast]

The "\r\n UID 2934)" part of the response should not be included in the length specified in the curly brace, only the raw message data should be included in that length. In other words, only the "\r\n" of those last 12 bytes needs to be included in the length value within those curly braces.

My guess is that the message on the server did not end with a "\r\n" and really was only 145080 bytes long. When the client requests that message from the server, the server measured the message length (145080) but has logic that when it streams the raw message data to the client in the response, it forces the message data to end with "\r\n". This increases the message length by 2 bytes making the actual length sent to the client as being 145082, thereby confusing MailKit which does not expect to find a \r\n until the very end of the untagged response (e.g. after the "UID 2934)").

I think I might be able to work around this by throwing away the invalid Eoln token that you are getting.

[jstedfast]

If you could install MailKit from https://www.myget.org/feed/mimekit/package/nuget/MailKit to test this fix, that would be awesome.

I think the next build will be 2.4.1.6 (2.4.1.5 is what is there now, but that is from Wednesday).

[jstedfast]

Or you could build from sources... either way is fine.

[zmarkusdev]

I tested it with the current source and it works, thanks for the fix!