Mailboxes: Sharing vs. Relationships

Last year we brought shared mail folders into play to join the rest of the sharing possibilities ZCS offers, but we don’t want to overlook mentioning another feature in 5.0 that has some excellent use cases.

Let’s say you need to collaborate with an assistant (who of course manages everything for you). While sharing is recursive to sub-folders by default, depending on account structure it can mean several invites and checks to make sure everyone is seeing the proper info. Other cavets include the occasional inability for the sharee to mentally organize / conceptually visualize the sharer’s folder structure scheme, or the possible need to keep the permissions and mountpoints updated when content is moved a lot. Nothing stings like missing important information when someone shifts material into folders that aren’t actually shared according to plan; everyone can become instantly out-of-sync.

Admins know that sharing the entirety of an account can be achieved through modifyFolderGrant & createMountpoint requests. This process previously had a few downsides, like avoiding name conflicts when trying to mount the root of the account ‘all at once’ (fixed in ZCS 5.0.6+).

There are a few RFE’s in the works, such as the ability to share an entire mailbox in one click or to expose custom share roles end-user side. We’re also planning to bring clarity to your web of shares through a single-user share management UI followed by the larger share management and discovery and a new Zimlet as well, but there’s one other cool trick that’s here right now: Family Mailboxes

Don’t let the name deceive you – we’ve used the concept of parent/child relationships, yet this principle can easily apply to any primary/secondary setup such as boss/secretary, professor/assistants, or manager/co-worker/peers; where sharing of passwords is inappropriate or you don’t want another browser session open, yet you still need full control. (Wildcard sub-domains aren’t for everyone, and an additional browser can equal a bit more memory used.)

To get started via CLI (if you’re an end-user ask your admin about configuring it):
zmprov ga secondary@domain.com | grep zimbraId
zmprov ma primary@domain.com +zimbraChildAccount {zimbraIdSecondary}

We also want the secondary account visible in the accordion UI of the primary:
zmprov ma primary@domain.com +zimbraPrefChildVisibleAccount {zimbraIdSecondary}

(The primary user can also set this later from their AJAX client preferences tab.)
 
Just like how the Zimbra Desktop’s UI works, you now have access to mail, contacts, calendars, tasks, notebooks, briefcase items, and even preferences of the secondary account:



A few notes:

  • As shown above – when replying from an account that’s not yours, emails include a header designating who it was really sent by & “on behalf of” is displayed. It’s also shown as unread in the sent folder of the account owner so they’re made aware of it.
  • This is a little different than permissions & mountpoints – so you’ll have to use normal shares if you need access in other end-clients; it requires the AJAX interface for functionality, and currently isn’t available in the HTML web-client.
  • Don’t go overboard on visible secondary accounts, our share model covers almost every situation; but as many organizations have a few crucial duos or teams who need to be on the same page every moment – this is there for those who have no time to mess with share permissions and need to manage other users, or perhaps desire complete control in a hosted family account.

To remove, simply replace the plus sign with a minus:
zmprov ma primary@domain.com -zimbraChildAccount {zimbraIdSecondary}


Have other ideas to improve work flow or make Zimbra family friendly? (Like parental mail screening, the ability for end-users to provision in HSP situations, or even admin console settings?) Then let us know below or drop in over at the community forums.

3 Responses to Mailboxes: Sharing vs. Relationships

  1. Venu Gopal May 3, 2012 at 1:03 PM #

    Good day Mike,

    I am now using ZCS 7.1.4 OSE on Ubuntu 10.04 LTS.

    I have the requirement of the following shared-mailbox config:

    Tom is working in CustomerService Dept – his personal mail-id would be tom@mydomain.com

    Jerry is also working in Customer Service Dept with personal mail-id : jerry@mydomain.com

    The common business mail-id both Tom & Jerry would be : custserv@mydomain.com.

    From their personal mail-ids, the mails cannot be sent to external domains (this I could figure out and configure)

    Only mails from the business mail-id should be allowed to be sent to external domains (This also I figured out and configured).

    Now, How do I share the custserv@mydomain.com to both Tom and Jerry so that :

    a. Mails sent by Tom or Jerry should go with sender as custserv@mydomain.com (i.e, send as only, not sent on behalf).
    b. should be stored in the sent folder of custserv@mydomain.com only.
    c. tom and jerry should not be able to delete any of the mails from any folders of custserv@mydomain.com.

    Please guide on achieving the above.

    Thanks in advance

    Regards
    S Venu Gopal

Trackbacks/Pingbacks

  1. system failure: Folder sync failed with Zimbra accounts - Zimbra :: Forums - January 27, 2012

    […] Bill, Thanks for your response. In the Wiki link, i've found exactly what i want : Family Mailboxes. Tested and approved . Thanks again […]

  2. "Add new contacts to Emailed Contacts" does not work when using child accounts - Zimbra :: Forums - May 12, 2012

    […] in that case someone might wish to amend this official Zimbra blog post to reflect that. That's both surprising and disappointing, as being able to use multiple accounts […]

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures