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

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.

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):

Promoted to Bifrost#T18595.

I believe I have provided what I thing is a coherent and comprehensive description of the considerations made in this ticket, and elsewhere, to the new tickets.

It seems reasonable to expect that if an ActiveSync client creates a folder, this folder must therefore also be synchronized with all other ActiveSync devices by default, and any manual intervention via the web client is only required in order to opt out of a particular device synchronizing such folder.

I apologize for merging this task in to a later task, but that's where another number of subscribers already were via T224 and other such ongoing conversations.

It seems clear that folder merging (all folder's contents will appear to the client application as if they originate from a single folder) is far, far from the ideal solution. In part, T224 has been initiated with that in mind specifically, since more and more newer clients appeared to support multi-folder in their respective client implementations. We've therefore switched from needing to whitelist every such newer device, to instead blacklisting whatever older device we might choose to continue to support.

This ticket has evolved in to T224, and T2055 and T2058 since. Your current entitlements also alleviate git.kolab.org from the support issues you may find yourself suffering from.

I agree that we're bloating this ticket with considerations that go past the white- vs. blacklist changeover. I'll create a sub-task and break the inheritance.

I've just attempted to reproduce the symptoms and it does not seem like I can. I'm going to request you wait for PyKolab version 0.8.7 in Kolab 16 and then try again.

Promoted to BifrostT9064

Try to add use_tls = true to the [ldap] section to fix the web admin.

This is likely a duplicate of T1988

Resolved per the aforementioned commits.