[Kolab-devel] How to properly detect a Kolab 3 server?

[Jeroen van Meeuwen (Kolab Systems)]

On 2013-07-29 15:45, Shawn Walker wrote:
> Hi Jeroen,
> 
> Thanks, but that doesn't look like those can be trusted to be 100% if
> server is a Kolab 3 server, especially if the server was upgraded from
> Kolab 2 server.
> 

Hi Shawn,

I agree this "methodology" I outlined, for as far as the term is at all 
applicable, cannot be trusted a 100%.

I also agree, no user likely knows (nor is expected to know) whatever 
the underlying format version of any payload is (supposed to be).

That said, the "methodology" as outlined is the best I can come up with, 
and it does establish what I believe is a very-well-educated guess -- 
more like a likely accurate estimate, in fact -- as either the server 
administrator has, or has not, upgraded the format version using 
kolab-formatupgrade or kolab-migrate.

Things being as they may, the inclusion of a Kolab format payload 
version in to the ID response on the server is not feasible; The ID 
response is compiled in at build time for the Cyrus IMAP server, and is 
hence immutable by the time we distribute the binary installation 
packages. There's no feature to specify additional strings to include in 
the response either. Using the ID response will far more likely 
automatically misconfigure a client, than the "methodology" I outlined 
before.

> The reason being for our client not asking the user if they are using
> a Kolab 3 server is that a lot of users don't really know what server
> they are using, only the administrator will.

As I said before, I agree.

> So, what we try to do is
> remove any 'guessing' that the user has to know and to cut down our
> support calls and having to figure out for the user what server they
> are using.
> 

I'm fairly certain the "methodology" I described before will reduce the 
load on your support team.

Let us discuss how, all things being equal, we might otherwise resolve 
the problem, as well.

For one, we know that during a configuration stage of a client, the user 
has to specify the username and password.

While the IMAP server address may be configured automatically using the 
domain name space of the email address or login username, using 
(possibly) a DNS lookup and the retrieval of an XML file, we may want to 
include a step for the Kolab format version in such a automatic 
configuration detection process. After all, if configuration is not 
automagic, the user needs to be given the exact server address, and can 
therefor also be given instructions as to the Kolab format versionto 
configure.

I propose an IN TXT DNS record for kolab.$domain holding a 2/3/3.0 value 
in DNS would not at all be inappropriate nor overly so a burden on 
administrators to adapt, noted that the discovery in your case may not 
be a process you could hook in to (it depends on whether it is exposed 
of course, and I simply don't know whether it is).

That said, though, I also have to say I think it isn't reasonable to 
*require* such a DNS record to exist for any given Kolab deployment - 
and would therefore argue in favor of the outlined methodology still, as 
a fallback.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08