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

[Thomas Brüderli]

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/lucy.black at example.org
user/lucy.black/Archive at example.org
user/lucy.black/Calendar at example.org
user/lucy.black/Calendar/Personal Calendar at example.org
user/lucy.black/Configuration at example.org
user/lucy.black/Contacts at example.org
user/lucy.black/Contacts/Personal Contacts at example.org
user/lucy.black/Drafts at example.org
user/lucy.black/Files at example.org
user/lucy.black/Journal at example.org
user/lucy.black/Notes at example.org
user/lucy.black/Sent at example.org
user/lucy.black/Spam at example.org
user/lucy.black/Tasks at example.org
user/lucy.black/Trash at example.org

2. Log in via web client with lucy.black at example.org 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 
lucy.white at example.org. The secondary email address now shows "white at example.orgl.white@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/lucy.black at example.org', we found folders: [u'user/lucy.black at example.org']
pykolab.imap DEBUG [31683]: Looking for folder 'user/lucy.white at example.org', we found folders: []
pykolab.imap INFO Renaming INBOX from user/lucy.black at example.org to user/lucy.white at example.org
pykolab.imap ERROR Could not rename INBOX folder user/lucy.black at example.org to user/lucy.white at example.org
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/Archive at example.org
user/lucy.black/Calendar at example.org
user/lucy.black/Calendar/Personal Calendar at example.org
user/lucy.black/Configuration at example.org
user/lucy.black/Contacts at example.org
user/lucy.black/Contacts/Personal Contacts at example.org
user/lucy.black/Drafts at example.org
user/lucy.black/Files at example.org
user/lucy.black/Freebusy at example.org
user/lucy.black/Journal at example.org
user/lucy.black/Notes at example.org
user/lucy.black/Sent at example.org
user/lucy.black/Spam at example.org
user/lucy.black/Tasks at example.org
user/lucy.black/Trash at example.org
user/lucy.white at example.org

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

4. Log in to the web client with lucy.white at example.org. 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: white at example.org
alias: l.white at example.org
givenName: Lucy
mailQuota: 1048576
preferredLanguage: en_US
sn: White
cn: Lucy White
displayName: White, Lucy
mail: lucy.white at example.org
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