I applied the fix into Kolab Winterfell installation, and I still see "infinite" processing loop with the same traceback. I restarted wallace and kolabd.

I think I know why we don't use kolab.calendaring to parse iTip data. It's because it does not support VTODO. Grrrr... Lets start from the beginning...

From what I see iTip attachments are parsed using iCalendar. From what I see we could fix this issue by using kolab.calendaring instead. This is quite a big change, but I'm working on this, I've got a few unit tests failing. If there was any reason to not use kolab.calendaring please speak now.

My "it should" should be verified with Jeroen ;)

=?iso-8859-15?Q?Stellenausschreibung-=C4nderung:_16-2509-075, IT@M, A10/E9_TV=F6D?=

This is not a valid header value according to RFC2047. Encoded-word can't contain spaces. What client created this?

ok, thank's, I've missed that

Shared folders are handled differently. We've been there. See find_folder_resource() in line 192.

For normal mailboxes and users I'd be happy with the implementation as I read it.

We'll test it in Kolab Enterprise 14 repos if available.

Created a patch. This is untested and it's not my decision if it is proper aproach.

Thanks for your effort. As soon as the changes are available in Winterfell, I'll be happy to test it.

As Jeroen already wrote, I think that is absolutely correct, it "should use" this

[cyrus-sasl]
result_attribute = mail

but the filter "-d 9" uses is

(&(&(objectclass=kolabinetorgperson)(objectclass=mailrecipient)(mail=*))(|(mail=pitb.mse@domain.de)(alias=pitb.mse@domain.de)))

so it includes "alias" into the search and I don't know why.

rather than setting the timeout unconditionally, it should set the timeout only for if immediate:

As discussed with Jeroen REJECT does not make much sense for resources. So, I don't see anything in the code that would need to be fixed now. Consider updating documentation to be more precise.

Returning to the original question. No, it is not possible to prevent this with configuration. So, you have to investigate why a mailbox exists for alias attribute in the first place.

Ehh. So, different value for immediate? What values?

Line 444 should be claused similarly to line 431 (by line 430)

sync-mailhost-attr should use the (one) result attribute (cyrus-sasl, result attribute), not the mail attributes.

Again, the resources module is a different module from the invitation policy. I read this ticket as concerning the invitation policy. I'm not sure how the resources module got in to the mix.

As I understand setting kolabinvitationpolisy: ALL_REJECT for resources does not work as for users, i.e. does not respond with Declined status.

The resources module is a different one from the invitation policy module. This ticket concerns the invitation policy module.

In rPd71e26c1a we added 10 second timeout (OPT_TIMEOUT option). I'm curious if we shouldn't use OPT_NETWORK_TIMEOUT and/or greater OPT_TIMEOUT value. Jeroen, what was your intention?

In addition it is not clear what ALL_MANUAL policy means for resources. There is nobody behind the resource, so nobody can manually react to the reservation request. Even more, resource is calendar, so it has no mail type folder to deliver request.

Yes, ACT_MANUAL is an alias for ALL_MANUAL in invitationpolicy module, but as I've said resources module supports only three policies. We should probably add support for ALL_* aliases, but adding support for all policies supported by invitationpolicy module would not be just a simple fix. That's why I'd like Architecture & Design to take a look at this.

Update: user invitation policy handling works, at least I can get invitation declined. It is declined either setting ALL_REJECT or ACT_REJECT.

As for the resources, in the code I see this module support only three policies: ACT_MANUAL, ACT_ACCEPT and ACT_ACCEPT_AND_NOTIFY

Works for me on KE14 (pykolab 0.7.28). What policy do you have in kolab.conf?

With pykolab 0.7.28 we discover the same issue.

Just debugged the same stuff with pykolab-0.8.3-3.1.el7.kolab_16.noarch, same behaviour.

Relevant OTRS issues:
1100085

Reproduced inhouse

Ok, when it's not used but should, then what's to do here?
The goal is to only try to sync_mailhost_attrs on LDAP items that realy belong to kolab relevant items.
So either one can do it as we did patch our current version or in a simpler way as you mentioned.

I suspect https://git.kolab.org/rP200ba8fe4dab5884ab0b3818c6678ad9745bdd7e

This is not occurred for me since the original report. If it still happens, can you reopen the ticket?

Resolved in:

Please state the version of pykolab, cyrus imap and guam

This does not happen in Winterfell, just in Kolab 16.

me? i ain't going to tell you anything. but resources seem to be (kind of) working for me after applying the above patch. - groups of resources lack functionality which is present i 3.4 - first available resource of a group is booked in 3.4 if a group is 'invited'.

Run this command with -d 9 to see more literal output all the way down to imaplib.

This did not actually result in a resolution for me. I am still unable to create and use resources.
As i don´t have a clean installation at the moment maybe somebody else with a fresh installation should check if this is could be a resolution.

Please don't tell me this actually resulted in a resolution but nobody shared?

This is not a topic for PyKolab nor Kolab not Postfix to fix. Distributions still shipping support for SSLv3 and before should take a serious, very fscking serious look in the mirror.