While investigating why some emails never gets out of wallace spool I found that some emails make wallace crash with the following trace back:
2018-02-21 10:05:39,912 pykolab.wallace ERROR Unknown error occurred; readonly('Other Users/dddd/Calendar is not writable',) 2018-02-21 10:05:39,914 pykolab.wallace ERROR Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/wallace/modules.py", line 118, in execute return modules[name]['function'](*args, **kw) File "/usr/lib/python2.7/site-packages/wallace/module_invitationpolicy.py", line 367, in execute done = processor_func(itip_event, policy, recipient_email, sender_email, receiving_user) File "/usr/lib/python2.7/site-packages/wallace/module_invitationpolicy.py", line 1377, in propagate_changes_to_attendees_accounts (attendee_object, master_object) = find_existing_object(object.uid, object.type, recurrence_id, attendee_user, True) # does IMAP authenticate File "/usr/lib/python2.7/site-packages/wallace/module_invitationpolicy.py", line 847, in find_existing_object imap.imap.m.select(imap.folder_utf7(folder)) File "/usr/lib64/python2.7/imaplib.py", line 671, in select raise self.readonly('%s is not writable' % mailbox) readonly: Other Users/dddd/Calendar is not writable
Turns out that the calendar in question is shared for some users with lr type of acls. This makes IMAP SELECT command to return [READ-ONLY] and imaplib.py raises the exception. After I changed acls to lrs the messages were digested by wallace and left the queue.
I think this read-only exception should be caught by pykolab and should not make wallace die. So every imap.imap.m.select(imap.folder_utf7(folder)) should be in try ... except ...in pykolab.