The suggested solution (to support CRAM-MD5 or DIGEST-MD5 in kolab-saslauthd) is very likely not the most efficient solution.

In fact, even if a very narrow and specific set of circumstances is already met by currently available, server-side infrastructure, the details matter and severely influence large code structures.

I would be very interested in the details of the research performed, that allowed you to determine CRAM-MD5 support in kolab-saslauthd was the least painful option to pursue -- normally, I'm the one to make such a determination, so I'm interested in your thoughts.

We are fully aware of the fact, that kolab-saslauthd is not a full https://tools.ietf.org/html/rfc4422 implementation but based on this RFC our request is just to get kolab-saslauthd closer to this.
And based on the https://en.wikipedia.org/wiki/CRAM-MD5 second point of weeknesses explaination, based on RFC 2104, it could be possible to add some security too.

I didn't say the last but the easiest.
The options we thought about:

1. reconfigure about 40k fat client configurations either at first use or on one big change action and add a lot capacity to user support if fat client reconf didn't do

2. change auth from kolab-saslauthd to cyrus-saslautd with auxprop and ldapdb pwcheck_method: auxprop auxprop_plugin: ldapdb mech_list: PLAIN LOGIN DIGEST-MD5 CRAM-MD5 ldapdb_uri: ldap://ladpserver.domain.tld ldapdb_id: proxyuser ldapdb_pw: proxy_secret ldapdb_mech: DIGEST-MD5 ldapdb_starttls: try

3. change auth from kolab-saslauthd to cyrus-saslautd with saslauthd and rimap to authenticate against the old imap server
4. write and deploy a tool/script reconfiguring all fat client configs
5. add shared secret auth to kolab-saslauthd with at least CRAM-MD5 mech

-> 1) high user impact very many involved individuals
-> 2) big change in system design here with some big risks in LDAP capabilities (associatedDomain)
-> 3) never tried and needs reconfiguration after removal of the old mail server
-> 4) useless one time time & money invest for an only use once solution with risks very closed to 1)
-> 5) invest time & money to develop kolab-saslauthd to support more functions of RFC 4422 under special considerations of RFC 2104 even the security question is not such a big thing anymore

The time for each of those options seam to be very closed together whereas we can not say how much time and effort option 5 would take.

Do you have some other suggetions on how to switch those up to 40k user accounts on oune big bang?
We need a big bang because of some aspects of the current individual mail, mailinglist and group mailing routes prohibit a block by block migration with some kind of mail dispatch gateway.

We will take under consideration, the need to support an existing desktop client already configured with CRAM-MD5 -- all implications included.

However, we also need to consider the development path to any solution provided, and the path to carrying such solution forward.

We'll take this under consideration and discuss.