I am using XFCE 4.8, xubuntu 12.04
* There seems to be a problem with the way mailwatch tries to get the folder list when connected to IMAP accounts.
* I experience it with two of my mail accounts added to the mailwatch plugin.
Both accounts work well with Thunderbird.
On server 1, the folder list remains empty and 'connection timed out' is logged.
On server 2, the folder list is loaded except it is incomplete: the subfolder I created on the account is not in the list that is returned.
People of server 1 traced the connections made by mailwatch.
LIST "INBOX." "%"
When folder 'Archives' has children, it should send:
LIST "INBOX.Archives." "%"
but it doesn't appear to be doing so.
So the observation made by support at server 1 is "The behaviour of our server looks fine to me reading the protocol information... but it's just disconnecting without even sending a logout command acccording to the transcripts I'm seeing - and it's not trying to look at the sub folders at all."
* A more general note:
Apparently the mailwatch-plugin code tries to make up its own implementation of IMAP instead of relying on a library.
I am the admin who looked at this. I read through the IMAP support code - very "little bobby tables" with random strings being interpolated between quotes. In particular a password with a " in it will break horribly.
I'm happy to help out a bit with this. I'm going to pull a git copy and build it for my own computer so I can debug locally.
Created attachment 4629
Increase buffer size
The title of this bug is incorrect - it has nothing to do with subfolders after all. I had to compile up my own copy and sprinkle a few more debug statements to prove what you're doing wrong, but here it is:
ret = select(FD_SETSIZE, &rfd, NULL, NULL, &tv);
if(ret > 0 && FD_ISSET(net_conn->fd, &rfd))
It ALWAYS tests if the fd still has more to read. But it doesn't, because a full TLS packet got read off the wire - so we never get to the later:
gret = gnutls_record_recv(net_conn->gt_session, buf, buf_len);
Unfortunately, the buffer is 1024 bytes long - so if the listing is longer than 1024 but shorter than a single packet, this will break. Mine is about 1280.
There's a bunch of real fixes you could make here - or you could just cheat with the attached awful workaround, which is also available at:
Confirmed to fix the issue for me.
We believe that this bug is fixed.