Could you please attach a full log from the IMAP session? You can find it in IMAP -> Debugging -> Show IMAP Protocol Log, and copy the content of the tab which matches that failing connection.

Created attachment 97301 [details]
connection log

Here is the log.

In imap settings (second tab) try to add "IDLE" (w/o the quotes) to the "extension blacklist" - it seems you idle and 24 seconds later the server informs about an update (while the untagged FETCH looks weird, trojita seems to hadle that and it's not forbidden by rfc 2177) and then just closes the socket?

Thank you. The error log shows that the IceWarp IMAP server violates RFC3501 whenever a new message arrives by first sending the FETCH (which refers to a non-existing message by that time), with a correct EXISTS following immediately after that.

Could you please report this problem to the IceWarp's technical support? IMAP mandates that new arrivals be reported via EXISTS first.

I've looked into how other IMAP clients handle this server bug. It seems that JavaMail added a compatibility kludge for the same situation (but due to a 11-year-old Courier-IMAP) last year, see [1]. I agree with Bill's reasoning in there -- the server violated the protocol specification, so it's a hard thing to decide what to do because nobody guarantees that there will ever be that subsequent EXISTS. The check is an important safety feature. But for the sake of interoperability, patches which replace this by some warning are welcome.

> while the untagged FETCH looks weird, trojita seems to hadle that and it's not forbidden by rfc 2177

Untagged FETCH is not a problem; the problem is the missing EXISTS. I have no idea if that only happens during IDLE, but note that disabling IDLE is quite a hack. Trojita is an IMAP client, and it expects that the IMAP server works as advertised.

[1] https://kenai.com/bugzilla/show_bug.cgi?id=6762

QnD: imply EXISTS for out of bounds FETCH
Proper fix would be to queue the FETCH and retry after subsequent EXISTS, abort on EXPUNGE, would it?

Does RFC3501 actually *mandate* a specific order?
(Relates to IDLE problem - while the wrong order is a bit clumsy, you'll hardly get an unsolicited FETCH in another context, ie. the sequence should be determined by the client and servers aren't permitted to alter count while handling a FETCH request. Since IDLE is specified elsewehre, why should the RFC worry about the response order? If it's only implied, adding an async response handler queue might be worth consideration, but if it clearly states "wrong", that's hardly an option)

Just ignoring (likewise implying EXISTS) the response seems wonky as it might legally indicate that client and server got out of sync - continuing on such condition might cause data loss?!

> QnD: imply EXISTS for out of bounds FETCH

That's also a possibility, but there's no added value in this -- the UID 
discovery in particular still needs to run. Yeah, we would save one UID 
FETCH (FLAGS), but I won't be optimizing for buggy servers.

> Proper fix would be to queue the FETCH and retry after 
> subsequent EXISTS, abort on EXPUNGE, would it?

Nope. Order matters a lot in IMAP because it's an asynchronous, 
cache-filing protocol. We just cannot do this reliably.

> Does RFC3501 actually *mandate* a specific order?

While it never says "you cannot swap EXISTS and FETCH", it defines what 
EXISTS does and also what FETCH does. The FETCH response is never defined 
to allow announcements of new messages, and it is forbidden from referring 
to message sequence numbers which are out of range, therefore the correct 
way to announce new arivals is via EXISTS.

In a similar manner, message removals are performed by EXPUNGE, not by a 
tagged NO to a FETCH, for example.

If you're asking about a general "order matters" declaration, I don't know 
if it's declared somewhere explicitly, but consider the following sequence:

* 1 EXPUNGE
* 2 EXPUNGE

This means that the first one got removed, and then the second one 
*starting hte count at the new beginning* got nuked, too. This is very 
different from this:

* 2 EXPUNGE
* 1 EXPUNGE

...which means that the first two messages got removed, which is equivalent 
to this:

* 1 EXPUNGE
* 1 EXPUNGE

> (Relates to IDLE problem - while the wrong order is a bit 
> clumsy, you'll hardly
> get an unsolicited FETCH in another context,

Servers are allowed to send these sorts of data at any point in time 
(subject to some rules about MSN ambiguity).

> ie. the sequence should be
> determined by the client and servers aren't permitted to alter count while
> handling a FETCH request.

They are -- it's legal to inform about both arrivals and removals during 
UID FETCH; we never issue a non-UID variant of FETCH and we do not refer to 
MSNs in these UID FETCH we send.

> Since IDLE is specified elsewehre, 
> why should the RFC
> worry about the response order? If it's only implied, adding an 
> async response
> handler queue might be worth consideration, but if it clearly 
> states "wrong",
> that's hardly an option)

The notion of the order being important is implied in IDLE, but it's an 
important rule in IMAP. There's no reason for IDLE to be special -- it's 
"just" a hack in the protocol grammar, it works by defining a command which 
is "always in progress", and it actually builds upon the fact that any 
command can result in any piece of data being delivered.

This IDLE happened despite the fact that IMAP has always made it legal to 
send unsolicited data at any time. As it turned out, plenty of clients 
regularly broke by that, so they added an explicit IDLE command which made 
it possible for clients to communicate "hey, I can handle it, seriously".

> Just ignoring (likewise implying EXISTS) the response seems 
> wonky as it might
> legally indicate that client and server got out of sync - continuing on such
> condition might cause data loss?!

Yes, that's why the check is in place :(.

The thing is -- the checks serves as a guard to report that either Trojita 
or the server is broken. In this context, the breakage is 100% limited to 
the server side. We know that it is actually harmless in this situation, 
but if we patch it away, we lose an important safety belt.

This is a danger of adding these compatibility kludges -- you never know 
when it prevents data loss during sync with a server which is broken in a 
slightly different way.

Thanks for the problem analysis. I'll report it to IceWarp. I guess this bug can be marked as resolved since it is not a bug in Trojitá.

Thank you for forwarding this.