Kerio Connect Desktop Client [message #132529] |
Thu, 27 October 2016 15:23  |
hopkins
Messages: 11 Registered: June 2007 Location: Perth, Australia
|
|
|
|
So far my experience with the desktop client (Windows 10 64-bit) has been fairly good, but I have had a few problems with it.
The way we operate at work, we are often not at the computer, we are nearby but not at the keyboard watching the screen. So, we rely on having an audible alert when new emails arrive. From what I can see, the desktop client only gives an audible alert for tasks and events, but not for emails. Surely this must be a bug? Right now, I get the desktop notification when a new email arrives, but no sound.
Also related to the above problem, we often have to monitor two email accounts at once. Obviously in Kero Connect you can only login one account at a time, so through the use of delegation and sharing, we have managed to be able to watch tawo accounts at once. However, when a new email arrives for the delegated account, there is no desktop notification at all. I only get a notification for new emails on the primary account. So, once again if I'm not actually sitting at the computer, I never know when an email arrives in the shared inbox.
And lastly, new email notifications only work for the inbox. We have some accounts which have filtering rules in place to automatically sort incoming emails into specific folders. This works fine except, once again, you don't get any new mail notification if it gets moved to another folder by the filtering rules. Is there a way we can have Kerio Connect give a notification for new emails that bypass the inbox and go straight into a different folder? I was able to do this in Thunderbird with a special plugin, but this would be a nice feature to have in Kerio Connect - the ability to check for new messages in any folder, not just the inbox.
We have been using Thunderbird in all our offices, but I would really like to switch everyone over to the Kerio Desktop Client. Unfortunately it still lacks features in the alert/notification area.
Any ideas?
|
|
|
Re: Kerio Connect Desktop Client [message #132546 is a reply to message #132529] |
Fri, 28 October 2016 03:49   |
hopkins
Messages: 11 Registered: June 2007 Location: Perth, Australia
|
|
|
|
TLDR for the above:
1. Add an audible sound alert for new emails.
2. Add desktop notification/sound alert for new emails in a delegated/shared inbox.
3. Add desktop notification/sound alert option in the filtering rules so when an incoming email is moved to a different folder, we can still get an alert.
|
|
|
|
Re: Kerio Connect Desktop Client [message #132560 is a reply to message #132529] |
Sat, 29 October 2016 00:51   |
Kerio Blue
Messages: 62 Registered: April 2013
|
|
|
|
I would like to ask for deployment options. It would be especially great if Kerio Connect could be deployed silently.
So far I was only able to deploy the client in a user context, also I could not suppress the installer GUI.
Otherwise I love it.
|
|
|
Re: Kerio Connect Desktop Client [message #132572 is a reply to message #132560] |
Sun, 30 October 2016 23:08   |
vomsupport
Messages: 80 Registered: October 2008
|
|
|
|
So far the Desktop apps are starting to look pretty good..
My only question is when is the price shoe going to drop
Will they be sold as a separate program or just included in a raised base price !
I know from previous experience that nobody put this much work into a program for nothing..
|
|
|
|
Re: Kerio Connect Desktop Client [message #132795 is a reply to message #132573] |
Thu, 10 November 2016 17:17   |
scottwilkins
Messages: 103 Registered: May 2006 Location: Tulsa, OK
|
|
|
|
I'd like to add monitor scaling to this list. With the popularity of very high resolution monitors, Kerio Connect Client seems to only use native resolution for fonts and screen layout. For some monitors it ends up being very hard to read for some folks. Either following the settings for scaling better, or allowing end user to set scaling independently for the app would be very nice. I guess making it a UWP app or Apple Store app might help in this, also make it easier to get it into end-user hands.
|
|
|
Re: Kerio Connect Desktop Client [message #132868 is a reply to message #132529] |
Wed, 16 November 2016 15:11   |
Jason1234
Messages: 23 Registered: April 2010
|
|
|
|
An option to not save the password would be good as well. We have several shared computers and users do not always log out and back in but they do close their email. Although the bug that causes the .exe not to close would have to be fixed for that to work.
An option to always open compose in a new window. I stress that this be optional in settings.
Spell Check!
|
|
|
Re: Kerio Connect Desktop Client [message #132966 is a reply to message #132868] |
Tue, 22 November 2016 05:03   |
domrose.it
Messages: 2 Registered: November 2016
|
|
|
|
We'd like to see better autoconfigure options. It seems Kerio Connect Client looks up the MX record of a server and uses that for the client connection. However, in several situations the MX record does not correspond to the Kerio instance users must connect to.
A workaround is to click advanced and manually enter the hostname, however, if you use something like an ironport or you use a cname with a wildcard SSL record, the hostname to connect to might be different. MX records are meant to indicate where mail exchangers are supposed to deliver their e-mail initially, so not necessarily the same place as where you'd want your client to connect.
This MX lookup behaviour causes SSL warnings when using the default e-mail address / password 'autoconfig' setup.
There are several better mechanisms available, first and foremost the use of SRV records when available (like _submission._tcp, _imap._tcp) etc, the Mozilla Thunderbird autoconfig XML TXT records, or the Microsoft autodiscover methods.
The MX record lookup or the well-known address lookups should only be used as a last resort.
I'd prefer SRV first, then autoconfig, then autodiscover, then MX, then manual configuration..
Also, one can only add ONE user account to the client. Many of our users wish to use both personal and generic accounts and have the sent e-mail from generic accounts go into the corresponding sent folder, so delegation is not really an option. Missed opportunity.
|
|
|
|
Re: Kerio Connect Desktop Client [message #132968 is a reply to message #132967] |
Tue, 22 November 2016 07:57   |
domrose.it
Messages: 2 Registered: November 2016
|
|
|
|
Carsten Maas (Kerio) wrote on Tue, 22 November 2016 07:31When you set up a proper auto discover SRV entry in your DNS system, you only need to enter username (email) and password in the Kerio Connect Desktop Client.
Nope ;-(
We have set up _autodiscover._tcp.domain.tld 0 0 443 records pointing to kerio-hostname-with-certificate.domain.tld. but when entering user<_at_>domain.tld and the corresponding password, Kerio Connect Client instead tries to connect to the hostname under MX record mx-hostname.differentdomain.tld. (with PTR record not under out control and therefore the internet hostname for Kerio when SENDING messages) - the IP address is also under the control of a hosting provider and thus could change...
It tries to connect to the wrong server.
We did configure multiple autodiscover methods. If SRV is used last and for example the cname method is used first, then I can imagine how this could become a problem since the cname autodiscover points to a cname which has the certificate which in turns points elsewhere. Could one simply remove the cname records for this to work? Would that not cause problems with certain Outlook or third party clients?
It would be great if SRV could be used as the FIRST method..
|
|
|
|
|
|
Re: Kerio Connect Desktop Client [message #133112 is a reply to message #133111] |
Wed, 30 November 2016 20:34   |
AShaw
Messages: 3 Registered: November 2016
|
|
|
|
That is correct. The domains I've been attempting to use on the Desktop Client are not the primary domain on the Kerio Connect server.
Now looking at the logs, I see the failed logins. As you probably already know, it's attempting to login in the user on the primary domain, regardless of what the Desktop Client passes in for a username.
|
|
|