@zash1958 said in Mails from Univention-Customer-Feedback stated as "unknown_content_type.bin:

Maybe, but all other Clients like Thunderbird, KMail and Evolution have absolutely no problem with it ???

TBird, KMail, Outlook-IMAP and Outlook-ActiveSync are mail clients operating on RFC822/2822/5322 data. WebApp (WA) and Outlook-zarafa6client (OL/Z6) are operating on MAPI data however.

Most Internet email traffic is RFCx22-style, so there is a conversion step when feeding mail into a MAPI system such as KC, or MS Exchange. Because MAPI’s uncanny design does not allow for unknown character sets of bodytext, you have two options:

pretend that “unknown-8bit” means “cp1252”. Or “iso-8859-1”. Or “koi8-r”. Since it is impossible to tell, someone will get gibberish at some point, and it will not be recoverable. store raw bytes and leave the interpretation to a 3rd-party software. This involves saving raw data as a (MAPI) attachment, or a RFCx22 data stream (or both).

TBird gets passed the RFCx22 data stream, which it then has to parse - and somehow make sense of “unknown-8bit”. It usually just pretends it is ASCII or something, and the user can switch charsets manually until the result makes sense to him.

WA and OLZ6 are MAPI clients and receive the MAPI attachment. Since it is an attachment to them, they don’t do any further parsing by default. IIRC, opening the attachment in Outlook gives you a new sub-window. That should also default to ASCII or something, and the user can again switch charsets manually until the result makes sense to him.

@fbartels,
some maybe interesting update on this. Today I manually restartet the kopano-server and after kopano-server restart all the lost received dates got back. So maybe it is an issue in kopano-server regarding autocalc fields.

Andreas

In Fedora-28-x86_64
libkcoidc0-0.3.0-17.1.x86_64.rpm
libs3-4-4.1.git257-2.2.x86_64.rpm
libtidy5-5.1.9-3.94.x86_64
have lower version numbers than currently installed version
See https://forum.kopano.io/topic/1522/db-backend-kopano-cli-mapi-error-80040111-mapi_e_logon_failed/10 for the problem starting kopano-server

Hi @General_Probe ,

no I did not yet have time to look further into this. Were you able to reproduce this on a fresh installation?

I’d recommend to open a support case if you need a different prioritization (customers always go first).

thanks that’s it… working like a charm now

@tjoen thank you!

@segro said in should one run kopano-fsck for all users regular?:

I’ll write you an email

I’d prefer a support case

Thx a lot. I updated and now it is working !

Hi,

I got it working ;=). Learned a lot and I found out my mistake. Yes it was included.

I also imported contacts. It worked well but I have some strange information in one field and also a “Umlaute” problem.

This is how it looks now in the Webapp.

Question 1: Why it has problem with ü and probably with ä ?`

Question 2: Zusätzliche Informationen is containing some fonts information and strange other numbers and letters…

0_1531768738610_kopano_pst_ue_zusätzliche_informationen.png

The locale name did it! Thank you!

Are you running the latest nightly?

I’d rather recommend to set the oof message on a shared store and let the user open the shared store in webapp/deskapp. The benefit of this approach is that only users with high enough permissions can disable oof messages on shared stores.

Thank you.

Problem solved:
init.d was starting an outdated dagent in /usr/local/sbin as daemon.
This explains, why delivery via postfix-unix-service worked ( in this case, the correct dagent version in /usr/sbin was called).

Sorry to everyone spending time on this.
++umgfoin.

I have added a small chapter about spamd to the manual, it can be found at https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#configuring-kopano-spamd-for-automatic-spam-ham-learning

The note box at the end should solve your issue.

I have added some documentation to https://documentation.kopano.io/kopanocore_administrator_manual/special_kc_configurations.html#configuring-kopano-spamd-for-automatic-spam-ham-learning

@computerlyrik said in Setting up kopano-spamd:

But i cannot see any log output - where does it go?
There is no file in /var/log/kopano with spamd in its name

by now all services output their logging to stdout to better benefit from journald. if you want to still log to a file (which can be beneficial for debugging) this can be configured in the config of spamd.

@computerlyrik said in Setting up kopano-spamd:

and the config file gets read

our services try to work without configuration values where ever possible and make use of builtin defaults instead. if you want to override a certain setting you can create a config file and put it into /etc/kopano. see https://documentation.kopano.io/kopanocore_administrator_manual/configure_kc_components.html#configure-the-kopano-server for more details and the location of the example config.

Hi, no sorry based on what you posted it sounds like it should work. I would recommend to get in contact with our support so that someone can have a direct look at your system.

Hi @kevo ,

unfortunately in a mapi store it is not supposed to be possible to rename the default folders by the user, hence you cannot do it in WebApp.

We do bundle a script to localise folder names. This script could probably be misused to set arbitrary folder names.

One remark though. The groupware features of kopano are more a complete package, if you reduce your contact to Kopano by only using it as a caldav source for osx clients, you will probably find solutions that are easier to manage and maintain.

If you want to use Kopano regardless of that, them you may also want to look into our new caldav and carddav implementation based on sabredav. It still somehow pre beta, but we require additional feedback on the current functionality to decide where to focus attention for the future.

Setup instructions are in the readme in https://stash.kopano.io/projects/KC/repos/kdav/browse