Ok, thanks!

Ah okay, thanks for clarifying that.
Nightlies have been updated as well now, so that topic is fixed for me.

@fbartels THAAAAANKS for all the details. Both systems are running again and I’ve learned a lot.

@fbartels said in Univention password change not forwarded to kopano-server:

It is supported since its release. In fact Kopano was one of the first external apps in the ucs 4.4 appcenter (as usual).
There is no need for a dedicated UCS 4.4 repository, since 4.3 and 4.4 share the same Debian base.

Thats sounds very good for me. I was afraid I updated too early to 4.4.

My solution:

calling univention-app register kopano-core --do-it install kopano4ucs via apt (not univention-install) calling univention-upgrade

The sticking point for me was, that the registration only bring back the apt repository (after commit or restart) and then I could install kopano4ucs via apt. After installation of kopano4ucs ‘univention-app info’ shows kopano-core again. Halleluja.

@thctlo ,@jengelh : Thank you for the clues. AppArmor was the problem. This occurred after a Debian 10 update and had nothing to do with Kopano. I was just following the wrong track.

@item said in sometimes a kopano profile (of a user) ist deleted:

There’s a chance to backup/restore a single profile?

kopano-backup can be used to backup and restore individual stores down to items in these stores (and also meta data such as webapp settings). If you don’t have a backup from before, then there is nothing you can restore from, though.

although this topic is very old I want to add the information, that

kopano-admin --sync

did work fine for me. I am using Samba4 as ActiveDirectory and right after I executed this command the name change was reflected correctly in “kopano-admin --details foo”.

maybe helpful for others seeking help for this issue
[SOLVED]

(For incoming mail:)

KC is freely combinable with an MTA of your choice (postfix being one of them) at a location of your choice. The one requirement is that you can actually edit the MTA configuration to make it point it to the LMTP service of dagent.

When using a third party MTA service, you will need one more MTA hop of your own that you can control, and that external MTA service needs to support relaying. With regard to spam filtering capabilities, this should be no problem: your own MTA can be made to exclusively allow transmissions from and to the third party MTA, and block everything else.

(For outgoing mail:)
k-spooler can use any SMTP server (including said third party MTA), this is just a matter of configuration file.

i suggest you update first to 8.7.-latest
8.7.0 - 8.7.1 - 8.7.2 8.7.4 were pretty buggy.

Update on this one.

Today I installed : 8.7.85.25.66501f583-0+164.1
And i can confirm this version works great.

Thanks for the great work.

Ok, today i installed : 8.7.85.25.66501f583-0+164.1

And Yes, this version works great.
All problems i had solved… Thanks for the great work.

Thanks! a note is the INSTALL should be sufficient then. ;-)

ok, de deliver problems are happening due to missing “kopano-group” entries in AD.
changing the ldap queries to “group” fixed it.

Thanks, helped for most mailboxes but one public folder. In this folder no mail arrives despite to:

==> kopano/dagent.log <== Fri Nov 8 13:24:30 2019: [error ] WARNING: setrlimit(RLIMIT_NOFILE, 8192) failed: Operation not permitted. You will only be able to connect up to 4096 sockets. Either start the process as root, or increase user limits for open file descriptors. ==> mail.log <== Nov 8 13:24:30 kopano postfix/pipe[15798]: 442111140E90: to=<xxxx@example.com>, relay=kopano, delay=0.23, delays=0.05/0.01/0/0.17, dsn=2.0.0, status=sent (delivered via kopano service) Nov 8 13:24:30 kopano postfix/qmgr[1470]: 442111140E90: removed

Mail to all other public folders gets delivered.

Thanks @genesis74,
I have also found that setting, but was not sure if that’s the correct place to fix it.
Thanks

I cannot trigger this. Did you, at any stage, combine g++ 8.2 with 8.3 objects? (There is a known issue related to that.)

It seems to be a character set problem. The problematic email is encoded in ‘gbk’. I have found an ugly workaround for emails in this encoding:

I export the email into EML via kopano and read that EML in as an email.message (I am on python). If the encoding of the kopano object is ‘gbk’ I get the utf8 encoded html representation from kopano (i.e. mail.html_utf8), encode it as bas64 and set it as the payload carrying the html content (text/html). After that, I set the character set of this payload to ‘utf8’.

Hence, for now, I have found a solution to my problem.

PR_TITLE is fed by the title attribute, PR_DISPLAY_NAME by cn; the latter can be changed, see the kopano-ldap.cfg(5) manpage for ldap_fullname_attribute. Apart from those knobs, it all largely depends what is in your LDAP tree.