Implemented in guam 91f1f2e5c7b2fb2d5c32ac463f37cac3b1ff078d

The keepalive patch is available sine 0.9.7.

Unfortunately missed this for 0.9.6, so I'll pick it up in the next release.

This has been resolved in packaging as far as I know.

Available since 0.9.5.

Now available in 0.9.6

I will look into integrating the patches.

This ticket is both old, as well as appears to be out-dated, in the sense that further updates to guam have been made available that also, supposedly, work, and was originally reported by an employee for another one of our then-employees to address.

The application can't address having run out of file descriptors.

Up?

This issue appears to be fixed on the client side, so I'm closing it.
On my test system, Kontact 5.7.3 identifies as "Kontact Kolab Resource 5/KOLAB".

Thanks for the detailed report. I'm working on getting this fixed.

First I tried to branch guam like it's common on github (pull requests, you know...). I'm not allowed to do so so I opened a ticket^H^H... task. But it seems it's not possible to add files here either. So here it is:

I also miss this feature as this would enable log based intrusion detection/prevention on IMAP accounts. Cyrus logs are only logging 127.0.0.1 as client IP because of Guam proxying, and Guam is not logging authentication events with IP.

Hello,
i reported the problem by the beginning of 2017 using the mailing list.
Since it hasn't been resolved, i disabled guam by changing the cyrus config.
This was with version 0.9.2-1.
Now, today i gave it a try and installed version 0.9.2-3. (Running on debian jessie).
Thunderbird can get the mails in the inbox, but when it starts to index the folders, thunderbird hangs.
On the server i strace the guam process and see, that there are unjoined threads and they never join.
Perhaps a hint, since erlang is based on threads.
As for now, i disabled guam again.

I have pushed a commit to the feature/autodetect_ipv6 branch which turns on keepalive for the socket; there is a corresponding fix on the eimap (imap server connection code) side as well, though I'm not sure that is needed. Hopefully that will resolve the issue as it will try to keep the socket up as long as the other side is still there according to the OS settings for these timeouts. by default on Linux it is 2 hours, which should be plenty.

Hi.
We have the same problem. Is there a workaround available?

see /usr/lib64/erlang/lib/guam-0.9.0/erl_crash.dump

So same issue, with slightly different results: multiple commands sent together, which is allowed by the IMAP spec indeed, and then the client ends up waiting for responses that do not come as expected. Thanks for the report.

I've encountered another bug with guam. This time It's "eM Client" for Windows. I've activated the client debug log (in eM Client) and after sending a XLIST and SELECT command in TLS/SSL mode (it looks like the client sends 2 commands at once) the connections gets into some kind of stale mode. It's no longer working. Hard to tell without decrypting network traffic.

With {tls, no} guam will not initiate the STARTTLS to the backend server and present the non-starttls response. With { tls, starttls } guam will already initialize a STARTTLS Session to the backend resulting in the security problem descriped above and guam allows unencrypted login, Even the LOGIN is stripped from the CAPABILITY afail

Should be implemented as a rule.

In T2082#31878, @dhoffend wrote:

Test @ 143

# nc localhost 143
* OK [CAPABILITIES IMAP4rev1 LITERAL+ ID ENABLE STARTTLS LOGINDISABLED] kolab Cyrus IMAP 2.5.10-49-g2e214b4-Debian-2.5.10.49-0~kolab1 server ready

Yes. I've already played around with this setup. Here're the results. The only thing that's strange are the capabilities after STARTTLS but before! AUTH

In T2082#31869, @dhoffend wrote:

A possible workaround (especially for Kolab:16) would be to update the default configurations of Cyrus and Guam.

Cyrus should listen on 1143 (non-ssl) and 9993 (ssl) while guam forwards 143 to 1143 and 993 to 9993 (2 different upstream servers and 2 listeners). This way guam isn't exposing and you wouldn't have to deal with it. But in the long term it would be great of guam could take over this work so you wouldn't need cyrus to listen on 2 different ports and running 2 different sets of worker/threads.

A possible workaround (especially for Kolab:16) would be to update the default configurations of Cyrus and Guam.

The fact is that the clients may respond to the availability of authentication capabilities before TLS is started (notably URLAUTH, SASL-IR, while AUTH= parameters are already stripped):

Still considering what to be done with this.

out of file handles.

Known issue.

Connecting with cli imap client "mutt" you can see this behavior because it always presents the full folder list (in the left folder view (patched) version as well when you want to switch the folders.

I could narrow it a bit down towards multiline input (IMO). The single commands are processed and filtered correctly. In the moment you or the client issues multiple IMAP commands at once guam isn't able to intercept and split it correctly.

Confirmed on Fedora 23:
sudo rpm -q nss thunderbird
nss-3.27.0-1.1.fc23.x86_64
nss-3.27.0-1.1.fc23.i686
thunderbird-45.2.0-1.fc23.x86_64

fwiw:
This can be reproduced on a fully-updated ArchLinux or Fedora 24. Additional we have some reports from IOS 10 users.

BTW, RFC2177 is talking about re-connecting in 29 minutes, so I suppose guam should set the timeout to 30 minutes.

I will close this for now - Please feel free to reopen if there are still issues related to this.

Is this still an issue, or did the increase of filehandles configuration resolve the issue?