A severe regression was introduced in 5.0.12, which
allows an admin to add an existing account or distribution list (item 1)
as an alias for other accounts or lists (item 2)
which results in the deletion of the first item's LDAP entry.
New binaries will be up later this week as 5.0.13
How to avoid the issue if on 5.0.12: Search for any current accounts matching the desired address before adding an alias.
If you've hit this issue see comment #5 on the bug for recovery steps (restore from LDAP backup, or remove the alias then create a new account with the exact same zimbraId of the one accidentally deleted, as mailbox data should still be intact).
Bug 35100 - Able to add active account to other users alias lists
---
Further technical details:
As it's a missing check in LDAP provisioning code, it will happen regardless of the management type you employ; affects admin console/LDAP/JAVA/SOAP/CLI methods. The correct behavior is for the server to respond with an error that the name is already in use.
Normally when you try to add an alias, if the LDAP entry already exists, it checks if the alias is 'dangling' (pointing to a non-existing target). If it is free, then it cleans up the address and then creates a new alias entry in LDAP. The bug misses checking if the entry is really an alias when deleting a dangling alias - thereby classifying it as free and modifying the LDAP entry for the first account. All email for account A will point at account B, and A is effectively gone from the system.
In other words: Attempting to add an alias that's actually an existing account will convert the existing account entry in LDAP into an alias entry.
Bugzilla
Wiki
Source
5.0.13 Released/5.0.12 Bug 
Linear Mode
