[Kolab-devel] Changing the primary email address via webadmin - and its implications

Hello folks

Today I renamed a user via Kolab Webadmin and found myself with strange results, inaccessible data and broken folder listings. But let's 
start at the beginning:

1. Create a Kolab User "Lucy Black" in Webadmin. kolabd picks up the new record and creates the default mailboxes.

$ kolab lm
user/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/Calendar/Personal [email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/Contacts/Personal [email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]

2. Log in via web client with [email protected] and work with it.

3. Lucy just got married and now goes by "Lucy White". Change her Surname in Webadmin to "White". This assigns a new primary email address 
[email protected]. The secondary email address now shows "[email protected]@example.org" in the webadmin interface. Huh?

kolabd seems to detect the change and attempts to rename the mailbox accordingly. This is from the debug log:

pykolab.auth DEBUG [31683]: LDAP Search Result Data Entry:
pykolab.auth DEBUG [31683]:     DN: 'uid=white,ou=People,dc=example,dc=org'
pykolab.auth DEBUG [31683]:     Entry: {'cn': ['Lucy Black'], ... 'modifytimestamp': ['20150304182846Z'], 'uid': ['white']}
pykolab.auth DEBUG [31683]: Entry Change Notification attributes:
pykolab.auth DEBUG [31683]:     Change Type: 8 ('modDN')
pykolab.auth DEBUG [31683]:     Previous DN: 'uid=black,ou=People,dc=example,dc=org'
pykolab.auth DEBUG [31683]: Searching with filter '(objectclass=kolabinetorgperson)'
pykolab.auth DEBUG [31683]: Entry type: user
pykolab.auth_cache DEBUG [31683]: Updating timestamp for cache entry 'c2178c01-c29b11e4-ae3596ef-f248ab46'
...
pykolab.imap DEBUG [31683]: Looking for folder 'user/[email protected]', we found folders: [u'user/[email protected]']
pykolab.imap DEBUG [31683]: Looking for folder 'user/[email protected]', we found folders: []
pykolab.imap INFO Renaming INBOX from user/[email protected] to user/[email protected]
pykolab.imap ERROR Could not rename INBOX folder user/[email protected] to user/[email protected]
pykolab.auth_cache DEBUG [31683]: Updating result_attribute for cache entry 'c2178c01-c29b11e4-ae3596ef-f248ab46'
pykolab.plugins DEBUG [31683]: Executing hook set_user_folder_quota for plugin dynamicquota
...

Note the "ERROR Could not rename INBOX" message in here.

So there definitely went something wrong. This now leaves us with this:

$ kolab lm
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/Calendar/Personal [email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/Contacts/Personal [email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/lucy.black/[email protected]
user/[email protected]

The top-level mailbox apparently was renamed while all the other folders remain unchanged.

4. Log in to the web client with [email protected]. The mail view welcomes us with a "STATUS: Mailbox does not exist" error message. 
All of Lucy's data is not accessible anymore :-(

Roundcube attempts to create the default folders if they don't exist but fails with some weird IMAP errors:

C: A0005 LIST "" "*"
S: * LIST (\Noinferiors \HasNoChildren) "/" INBOX
S: A0005 OK Completed (0.000 secs 2 calls)
C: A0006 GETMETADATA "*" (/private/vendor/kolab/folder-type /shared/vendor/kolab/folder-type)
S: A0006 OK Completed
C: A0007 SETMETADATA INBOX (/shared/vendor/kolab/folder-type "mail" /private/vendor/kolab/folder-type "mail.inbox")
S: A0007 NO Permission denied
C: A0008 SETMETADATA INBOX (/private/vendor/kolab/folder-type "mail.inbox")
S: A0008 NO Permission denied
C: A0009 LIST "" Drafts
S: A0009 OK Completed (0.000 secs)
C: A0010 CREATE Drafts
S: A0010 NO Mailbox already exists
C: A0011 SETMETADATA Drafts (/shared/vendor/kolab/folder-type "mail" /private/vendor/kolab/folder-type "mail.drafts")
S: A0011 NO Mailbox does not exist

The server doesn't list any folders other than INBOX. But an attempt to create Drafts is rejected with "Mailbox already exists" but setting 
metadata to it leads to the error "Mailbox does not exist". Seriously?

END OF THE STORY

Before filing tickets against various components of Kolab I'd first like learn about the intended behavior in case the user name (and with 
it the primary email address) is changed. Should this really rename the mailbox in IMAP? Apparently it should. In pykolab, there's 
imap.user_mailbox_rename() which is called by kolabd. Fair enough, although it reports an error. But is this operation also supposed to 
rename all other mailboxes recursively? I didn't dig into the cyruslib codebase which executes this change.

And shouldn't old email addresses be kept as secondary mails? In LDAP, all the old addresses are gone:

dn: uid=white,ou=People,dc=example,dc=org
alias: [email protected]
alias: [email protected]
givenName: Lucy
mailQuota: 1048576
preferredLanguage: en_US
sn: White
cn: Lucy White
displayName: White, Lucy
mail: [email protected]
objectClass: inetorgperson
objectClass: kolabinetorgperson
objectClass: mailrecipient
objectClass: organizationalperson
objectClass: person
objectClass: top
mailHost: localhost
uid: white

And webadmin messes the listing of the alias addresses but that's probably just because of a wrong field type is being configured for the 
'alias' attribute. Changing it from "text" to "list" at least fixes the display.

I should note that all this was recorded on a fresh CentOS 6.6 machine with a vanilla Kolab installed from the Kolab:Development packages.

So there's some work ahead of us, I guess.

Thanks for comments about the intended behavior and some hints about what possibly went wrong here and how to further investigate this.

Best,
Thomas