Implementing Shared Mailboxes in Dovecot with IMAP ACLs

Requirements

Shared mailboxes are needed when multiple authenticated users must read or write to the same folder hierarchy. Key requirements include:

• Per‑folder granularity – each folder can have a distinct set of users.
• Standard IMAP clients (Thunderbird, Outlook, mobile) must see the shared folders without custom plugins.
• All access control is enforced by Dovecot; no external filesystem permissions should be relied upon.

Minimal Design

The smallest configuration that satisfies the requirements is a single shared namespace combined with the acl plugin. The namespace prefix uses the %%u variable so that each user’s shared folders appear under Shared/<user>/ for all other users.

# /etc/dovecot/dovecot.conf (excerpt)
plugin {
  acl = maildir
}

namespace shared {
  separator = /
  prefix = Shared/%%u/
  inbox = no
}

# optional: make the namespace truly shared
mailbox shared {
  shared = yes
  # decide if seen flags are per‑user or shared
  shared_flags = yes
}

When a user logs in, Dovecot will expose the Shared/<user>/ hierarchy in the LIST response. ACL rights are stored in dovecot-acl files located alongside each mailbox.

Trust and Data Boundaries

All enforcement happens inside Dovecot’s IMAP/LMTP layer. The filesystem should be owned by a dedicated vmail user and never be exposed via shell or other services. Mixing ACLs with Unix permissions can cause confusing denials; keep a single ownership model and let Dovecot handle access.

Operational Checks

After configuration, verify that:

1. The shared namespace appears in the LIST output for a non‑owner user.

   doveadm -u bob imap-list
   

2. ACL rights are correctly applied. Grant read/write to bob on alice’s inbox:

   doveadm acl set -u alice -r user:bob Shared/%%u/Inbox
   

   Then check:

   doveadm acl get -u bob Shared/alice/Inbox
   

3. ACL files are created and updated. The file /var/mail/vmail/alice/Shared/alice/Inbox/dovecot-acl should contain a line like:

   user:bob:rw
   

4. No permission errors appear in /var/log/dovecot.log after a denial attempt.

Failure Modes

Failure	Cause	Impact
ACL file missing after migration	Maildir moved without preserving dovecot-acl	Users lose access rights, defaulting to deny
Namespace prefix mis‑configured	Wrong separator or missing %%u	Shared folders not visible in LIST
Seen flag confusion	shared_flags set incorrectly	Per‑user seen flags overridden by shared flags
Filesystem permission mismatch	Maildir owned by root or shared group	ACL enforcement bypassed, users can access files directly

When to Change the Design

The minimal design scales well for small teams. However, consider the following triggers for a more advanced architecture:

• Many‑to‑many sharing – hundreds of users share many folders. Use a dict or SQL backend for ACL storage instead of per‑file dovecot-acl files.
• Multi‑server deployments – ensure ACL files are replicated or stored in a shared storage layer; otherwise users on different servers will see inconsistent rights.
• Group‑based permissions – if you need to grant rights to a dynamic group, enable mail_acl_groups = dict and configure the dict backend.
• Performance concerns – heavy ACL lookups can be cached by Dovecot; enable cache_size if you observe latency.

When switching, update the plugin { acl = dict } section and provide a dict acl configuration pointing to a key-value store.

Concrete Example

Assume two users, alice and bob. Alice wants Bob to read and delete messages in her Projects folder.

1. Configure the shared namespace (see dovecot.conf above).
2. Create the folder via IMAP or command line:

   doveadm mailbox create -u alice Shared/%%u/Projects
   

3. Grant rights:

   doveadm acl set -u alice -r user:bob Shared/%%u/Projects
   

4. Verify:

   doveadm acl get -u bob Shared/alice/Projects
   

   The output should list rw rights.
5. Check that Bob can LIST the folder:

   doveadm -u bob imap-list
   

   Bob should see Shared/alice/Projects in the result.

These steps demonstrate that the minimal design satisfies the requirements and that operational checks confirm correct behavior.

Limitations and Verification

Always test on a staging environment before deploying to production. Verify ACL persistence after a restart and confirm that logs show no denied operations. If you encounter unexpected denials, check both the dovecot-acl file and the filesystem ownership.

Summary

Using a single shared namespace with the ACL plugin gives a lightweight, per‑folder sharing mechanism in Dovecot 2.x. Keep the filesystem under a dedicated user, enforce all rights inside Dovecot, and regularly audit ACL files and logs. When scaling or adding group permissions, move to a dict or SQL backend to maintain performance and consistency.