@ebroch
The service has not been available for a long time.
You are in the wrong area ;)
I think they were hacked ;)

https://forum.kopano.io/category/25/synchronising-mobile-devices-via-z-push

If your database is only used on this host, you may also use:

skip-external-locking skip-name-resolve

57 connections is not a whole lot, I would not limit that anyway - the default is 150.
“query_cache_size” and “query_cache_limit” with InnoDB are a difficult topic - it is usually better to set “0”.

You may also use multiple buffer pools for better concurrency with:

innodb_buffer_pool_instances

I usually match my number of cpu cores with the number of buffer pools and io-threads.
The overall buffer pool size is calculated “innodb_buffer_pool_instances” * “innodb_buffer_pool_size”.

Why are you increasing “innodb_lock_wait_timeout” ?

More is not always better…

What is your max_execution_time in php.ini?

Hi @rosch,

you did not specify which backend or version of Z-Push you are using, but the functionality to allow/deny users using Z-Push at all is already possible for years.

Hi @peter-panuski,

I would recommend to get in direct contact with the Kopano support so that a developer can investigate why the certificate cannot be imported.

Hi @handyman,

I would recommend to get in direct contact with the Kopano support so that a developer can inspect the appointment in question.

@telecom2k3 its more a sign MS is heading towards, kopano went to activesync because of frequent changes in outlook mapi

@kwiatekp

You can now acces the wiki from https://kb.kopano.io/spacedirectory/view.action

@boospy
It seams you did not change all references from “repo.z-hub.io” to “download.kopano.io”.

@fbartels But the wiki is at z-hub.io, right? This post links to the wiki using z-hub.io: https://forum.kopano.io/topic/3615/z-push-2-6-2-final-release

And one other thing:
There is a FAQ on this topic in the Exim GitHub Wiki section (https://github.com/Exim/exim/wiki/Q5004) which explains use cases in accordance to RFC 2822.
I think the aforementioned fix by removing the header is the easiest way to protect “BCC” information.

Dovecot should not change headers.
As far as I can see, it is up to the IMAP client to decide, whether it shows the “BCC” information or not.
Outlook in my case hides unrelated BCC information, but I can see the full header if I want to.

Another and better way to go, would be to rewriting sendMessage() to send a copy of the mail to each “BCC” recipient, containing only themself as “BCC” recipient in the “BCC” header and the original mail to all “CC” and “TO” recipients without “BCC” information, which should be a fairly simple task.
There is also another bug - at least I think it is one - with sending a mail to “BCC” recipients only (no “TO”), because this does not work.

cool there is now a search for folders in the sidebar.

Awesome. work perfect. big thumb up.

Bumbing this old thread.
This bug still exist in Kopano.

WebApp: 5.0.0.187+1976.1
Kopano Core: 11.0.1

@fbartels Thank you , it is clear to me now