[Kolab-devel] my current patchset

hede kolab983 at der-he.de
Sun Dec 3 12:11:34 CET 2017

Am Sat, 02 Dec 2017 23:01:02 +0100 schrieb Aaron Seigo <aseigo at mykolab.com>:

> Hi,
> Responding to the guam patch part:
> there is a patch (attached) for eimap that fixed a client stall issue 
> that seems to have been applied to the Enterprise repository packages, 
> but not to the main repo[1]. this should also be applied to your build 
> and tested as well.


> as for the guam patch, i'd be happy to review it (test, verify, clean 
> up, etc.) if i could be given a way to reproduce.

Probably it targets the same thing than your eimap patch, but within guam. At least they overlap.

I had written some explanation on the users list and opened a ticket at git.kolab.org. 

In short: There are some imap states where no tags are transmitted. Like with uploading mails into some imap folder via imap APPEND command. Usually that's no problem because every mail has headers. So uploading starts with a header like "X-HEADER: VALUE" where guam interprets "X-HEADER:" as tag and "VALUE" as command. Hopefully the value is not a valid command so it won't get filtered and the rest of the upload is fine. But claws mails uses "X-HEADER:VALUE" which results in the whole line to be interpreted as a single tag only. The line gets buffered, waiting to be continued, but it's already complete; so every other line sent by claws-mail only fills the buffer within guam; guam still parses the first line only and never sends the whole buffer to the imap backend (i.e. cyrus).

Second problem: The java imap implementation used by kolab notes for android is faulty. It alwys sends the first character of the tag on a separate line. Like 'A12 LIST "" "*"\r\n' results in sending 'A\r\n12 LIST "" "*"\r\n' -> 'A\r\n' is the first line in buffer. This also stalls guam 9.

Both bugs are new to guam 9; guam 8 was fine. 

If both clients (claws mail and kolab notes for android) are working fine without my guam patch but with your patch added to eimap, my patch seems superfluous.

My patch simply sends all completed lines to the backend. No big magic. That was my first contact with Erlang and I do not understand the whole buffering purposes at all. So ... I'm happy with making guam work for me even if it's not the fully correct solution. ;-)

Btw: I would prefer a more sophisticated solution. Maybe some kind of detection for the APPEND command and counting the received bytes (== message literal). A little like those AUTHENTICATE-"transactional"-update_split_command_state thing inside guam - which I also didn't dig to much into. There's at least no need for parsing tag/command inside uploaded mails data.

> I no longer have push access to those repositories, as on leaving 
> the company Kolab Systems terminated all access to things like the git 
> repositories ... so the person who wrote that code and expressed 
> interest in continuing involvement (me) can not do so.

Ah, I didn't knew. What a pity. That at least explains why there are no recent commits to guam. 

> I will fork the repositories on github and 
> continue maintenance / development of them there.

I'd prefer kolab systems opening their repository for community contributions. But AFAIR the last attempt in coming together at one round table flopped a little (I was busy and couldn't participate; so I shouldn't judge here too much). 

Too many bad news lately. I had contact to Timotheus the last days, maybe he's the one closest to kolab systems currently. But even he is maintaining his own repositories outside of kolabs fabricator. :-(


More information about the devel mailing list