I hacked something in utils.py to try and live with the workaround again.... it looks okay, but we will see where else we might have issues...

I finally managed to upgrade my debian and went to deb11 with kolab16

The message header is parsed!

As the fix sets encoding="utf8", does this mean all messages are utf-8 encoded here?

Packaging fix: https://obs.kolabsys.com/request/show/3324

Proposed fix in D4959.

This file opening problem again caused wallace to crash on my server, resulting in the failure to deliver emails to the end recipient.
Searching though the wallace directory I found the following instances

Same file opening problem exists in /usr/lib/python3.9/site-packages/wallace/module_invitationpolicy.py - line 270 :-

Patch merged.

Seems to be fixed by D3692 and rPbd3a9e74745461089d7afc4e51a39c21958907bf.

Fixed by D3851.

Patch submitted as D4625.

Old. Not enough info.

@mollekopf, imap.user_mailbox_create() returns False on error.

I think it is better to pass the invitation to Inbox for manual processing.

This specific issue may be fixed with:

--- a/pykolab/setup/setup_roundcube.py
+++ b/pykolab/setup/setup_roundcube.py
@@ -26,10 +26,11 @@ import hashlib
 import os
 import random
 import re
+import six
 import subprocess
 import sys
 import time
-import six
+import urllib.parse

It looks to me it's rather CentOS7 issue. And it's old.

I think this got fixed in the python3 migration. Please reopen if you run into this issue again on a python3 system (>= Debian 11)

imap.user_mailbox_create() always returns a string, so this should be fine. Is there a command-line way to reproduce this issue?

D3692 and D3710 should fix this
I ran into same error, when testing for Python 3

The exception comes from inside cache_update(). See attached the traceback, from the log file that Johannes sent me.

Do you happen to have a log containing a backtrace for the case where the sender column is too short? After skimming the code, I would assume SQLAlchemy throws an exception which then gets caught in bin/kolab_smtp_access_policy.py:1717. That's obviously too late.

According to the log, the script tries to create a user named '@'. That's, well, weird. Unfortunately, I'm not sufficiently familiar with the pykolab codebase to make a qualified guess where this username may have originated from.

I didn't know that wallace created generate calender placeholder. Do they have an update for this? Hoping that they fix it as soon as possible.

Any thoughts about how to fix this issue?

Closing Ticket. Change has been merged

Patch seems to work. I haven't seen this issue after applying the patch. Thanks a lot!

Additionally I get the following traceback:

2019-12-23 14:05:25,670 pykolab.auth ERROR [21425] An error occured using _paged_search: NameError("global name 'LDAP_CONTROL_PAGED_RESULTS' is not defined",)
2019-12-23 14:05:25,670 pykolab.auth ERROR [21425] Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 3168, in _search
    secondary_domains
  File "<string>", line 10, in <module>
  File "/usr/lib/python2.7/dist-packages/pykolab/auth/ldap/__init__.py", line 2940, in _paged_search
    if c.controlType == LDAP_CONTROL_PAGED_RESULTS
NameError: global name 'LDAP_CONTROL_PAGED_RESULTS' is not defined

This happend on a Debian 10 system with most recent pykolab package

• pykolab 0.8.17-0~kolab2
• python-ldap 3.1.0-2

ups, reopen

A workaround could be to move the hosted_root_dn from the [kolab_web] to [kolab] section and make a check for it. If hosted_mode is configured then look for ou=domain,$hosted_root_dn instead of the dc version. Another workaround would be to load all hosted domains into memory to avoid ldap query for every sync run. But we then need to trigger kolabd somehow to reload the domain list when domains have been changed or added

Okay ... first issue (in my case) is that mgmt_root_dn is in the same domain name space ... One issue, but that's not the root cause

Yepp. the chmod mask was held against the umask and therefore resulted in the wrong chmod mask. After changing this to a correct umask octcal number it's okay.

This is especially useful for fully automated setup runs like

setup-kolab \
[...]
--mysqlserver=existing \
--mysqlrootpw=unix_socket
[...]

The individual directories in /run/ are secured, so there's little need to secure the files within them.

Uploaded D847

Uploaded D853

See Debian Bug Entry: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921016

@machniak Thanks a lot! I'll try the patch. This .ics arrived from Microsoft Exchange Server 2010 (based on the PRODID field in .ics).

Fixed.

Further investigation shows that actually Kolab format has CutypeRoom and CutypeUnknown defined. So, we can add these to the map, but still we should probably silently ignore unsupported values.

According to RFC5545 ROOM, UNKNOWN, X-* are valid values. Those aren't supported by Kolab, but we definitely should not throw exceptions on these. I wouldn't touch the map variable. Probably better to handle these in set_cutype().

spam ^^

I suppose it should. If it doesn't, we'll take a ticket.

Is it ok if the FQDN resolves only to an IPv6 address (working and reachable)?

This also produces a broken configuration file:

Strange. There's a new line after import re, so the error does not make sense. And no one complained about this, so looks like an issue with your system only. It's old, anyway.

If I understand this correctly toki.space is a domain space, FQDN should include hostname.