sorry for this, looks like we missed these somehow when testing with python3. I made a PR for kopano-localize-folders. about the other script, would the new kopano-cli also work for your purposes…? (“kopano-cli -u userX” also shows permissions).

@umgfoin said in Version 8.7.80.402.1c7f107ba-0+44.1 breaks php7-mapi:

Bitbucket’s diff-view doesn’t detect the differences (!?).

Probably it just does what git would do. You need git log -c to visualize merge commits.

@Caldwell please open up a support case to request a remote session

@Ihon
Python-kopano

The main intention was just to give feedback for other users who try to use iCal. Especially when setting up behind an Apache proxy.

I realized now, that ical is not the new implementation and the paths at https://forum.kopano.io/topic/1341/request-for-feedback-new-caldav-and-carddav-implementation-for-kopano are for the other version. I will perhaps test that version also.

A main problem for my first tries to get it working correctly was, that the ical implementation accepts ever context path and is answering on every context path partially correct, but only using the context path /caldav the answer is compleatly correct. This is missleading when trying to setup everything.

About subfolders: I created a folder “Test” inside the Tasks folder and tried both URLs /caldav/<username>/Test (like written in the manual) and /caldav/<username>/Tasks/Test and neither worked. But this is also nothing I need, I just mention it to document it.

So no need for any action on your side - just a report in case someone else is trying to setup a similar usecase.

Thanks. We now have an internal pr for this.

For future reference: https://stash.kopano.io/projects/KC/repos/kopanocore/pull-requests/2434/overview

So, i could fix this issue.

i added the following

olcDbIndex: mail eq,pres

to /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1\}hdb.ldif

and built a new checksum

apt-get install rhash tail -n +3 /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1\}hdb.ldif | rhash -C - | awk '/stdin/ {print tolower($2)}'

i have to take this new created checksum and to replace the old in line two in the file /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{1\}hdb.ldif behind # CRC32.

i hope this helps somebody.

Best Regards

Daniel

No, you should configure spamd to use the group that amavis/spamassassin runs as on your system: https://stash.kopano.io/projects/KC/repos/kopanocore/browse/installer/linux/spamd.cfg#50

Indeed, the RFC also states that it should be printed as an utc value. https://tools.ietf.org/html/rfc5545#section-3.8.2.1

Will create a ticket for it tomorrow. If you want to provide a pr for this this would be welcome.

Meanwhile you could also have a look at https://forum.kopano.io/topic/1341/request-for-feedback-new-caldav-and-carddav-implementation-for-kopano which will eventually replace the current implementation.

For a business donations are hard to handle. But for just 75€ you can get a subscription, which also gives you access to supported releases for a full year.

https://kopano.com/pricing/

Hai, ok so this is handeled by the setting : ProtectSystem=full and PermissionsStartOnly=true

You dont see these often, i’ll have a deeper look at this.
Thank you for the clarification.

@psy0rz thanks for your response. I would use it if it would be for spamassassin. I migrated from dspam to spamassassin because dspam is quite old… Is your plugin still functioning? Could you tell me what i have to change to use it for spamassassin? Is it dumping the mails in the junk mail folder directly if it indentifies the mail as spam? And how can i tell it that this is not spam?

Best Regards

Daniel

Have a look at the Debian kopano-sources i saw that they dynamicly detect the php version for the build now.
Debian git commit : [4e86b06] d/rules: detect PHP_VERSION dynamically
so i suggest try the Debian sid source and look at Debian/rules

Should be fixed with an upgrade: https://forum.kopano.io/topic/1297/core-8-6-80-621-german-umlauts-broken-in-the-subject-line-of-sent-mails