Created attachment 1768 [details] Network Log Often I get such error message in Network Log. My mail server is http://qip.ru. Due this error it is difficult to use Claws. Connection is often broken. I also will write to qip.ru support. I understand that it can be a server problem.
If I'm reading this right, the last line received from server is bogus - it seems to be a repeat of the similar line two lines above, but without the mandatory pseudo-tag "*". (RFC 3501 section 2.2) Also, it is sent after the "OK" response to our "STORE" request, which is wrong. (see RFC 3501, section 6.4.6) In IMAP protocol terms, that line is basically an unsolicited (and invalid) server reply to a client request with tag "FETCH", which was never made. No wonder Claws Mail doesn't like it. The server seems to be broken.
Created attachment 1807 [details] Short claws log with error
Created attachment 1808 [details] expect log with error
Created attachment 1809 [details] expect script to reproduce no error
Created attachment 1810 [details] expect log withot error
I tried to do the same with telnet. So no any errors. I used expect to test qip.ru. Logs in attachments. Password replaced with *******.
The bogus "* 12 FETCH ()" server response (after your "UID STORE" command with tag 10) is still there in the session driven by your expect script. It shouldn't be there at all, see my comment #1.
Do you mean this wrong? C: 10 UID STORE 127196 +FLAGS.SILENT (\Deleted) S: * 12 FETCH () S: 10 OK STORE completed Section 6.4.6 has such example Example: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH (FLAGS (\Deleted \Seen)) S: * 3 FETCH (FLAGS (\Deleted)) S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) S: A003 OK STORE completed I don't see here a big difference.
I must exactly understand what to write to QIP support and will capable to argue why this must be changed. Seems they very lazy or stupid.
(In reply to comment #9) > I must exactly understand what to write to QIP support and will capable to > argue why this must be changed. Seems they very lazy or stupid. Yes, most of the server output in your logs is just like the cited example from the RFC. However, the server always seem to include one extra line, which should not be there: Last few lines from your first log: [12:13:33] IMAP> 6 UID STORE 122415 +FLAGS.SILENT (\Seen) [12:13:34] IMAP< * 427 FETCH () [12:13:34] IMAP< 6 OK STORE completed [12:13:34] IMAP< 427 FETCH () <----- wrong Last few lines from your second log: [16:59:31] IMAP> 10 UID STORE 127147 +FLAGS.SILENT (\Deleted) [16:59:31] IMAP< * 12 FETCH () [16:59:31] IMAP< 12 FETCH () <----- wrong