Tag Archives: IMAP

In my last post I discussed what IMAP ACLs are implemented by MDaemon, and a little about how they work. In this post I want to make everyone aware of the ways that ACLs can be managed.

ACLs can be changed a number of different ways, not only by administrators using the MDaemon interface. ACLs can be changed using any of the following methods:

• The MDaemon GUI, under public folders or from within the user editor.
• The WebAdmin GUI, in similar locations.
• WorldClient allows users to share folders and set permissions.
• Outlook Connector allows users to share folders and set permissions.
• Any IMAP client can be used to set permissions.
• You can even change ACLs by using “telnet” to connect to the IMAP server.

This is significant as it allows any user to share their own IMAP folders out to other users. Note that only users who have the “administer” ACL or are a WebAdmin domain admin or global administrator can change ACLs.

To understand how to change rights, I have lifted the following information from RFC2086 – IMAP4 ACL extension

To set ACLs, use the SETACL command:

4.1. SETACL

Arguments: mailbox name
authentication identifier
access right modification

Data: no specific data for this command

Result: OK – setacl completed
NO – setacl failure: can’t set acl
BAD – command unknown or arguments invalid

The SETACL command changes the access control list on the specified mailbox so that the specified identifier is granted permissions as specified in the third argument.

The third argument is a string containing an optional plus (“+”) or minus (“-“) prefix, followed by zero or more rights characters. If the string starts with a plus, the following rights are added to any existing rights for the identifier. If the string starts with a minus, the following rights are removed from any existing rights for the identifier. If the string does not start with a plus or minus, the rights replace any existing rights for the identifier.

To retrieve ACLs on existing folders, use GETACL:

4.3. GETACL

Arguments: mailbox name

Data: untagged responses: ACL

Result: OK – getacl completed
NO – getacl failure: can’t get acl
BAD – command unknown or arguments invalid

The GETACL command returns the access control list for mailbox in an untagged ACL reply.

Example: C: A002 GETACL INBOX
S: * ACL INBOX Fred rwipslda
S: A002 OK Getacl complete

For more information and a few additional commands, please do read RFC2086 – IMAP4 ACL extension

There is some confusion about IMAP ACLs, and how they are used and implemented by MDaemon, Outlook Connector and WorldClient.

First, what are ACLs? ACL stands for “Access Control List”, and ACLs are a way of controlling who can see a folder, and what rights a user has within that folder.

There are 10 defined ACLs supported by MDaemon:

• l – lookup (mailbox is visible to LIST/LSUB commands)
• r – read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, SEARCH, COPY from mailbox)
• s – keep seen/unseen information across sessions (STORE SEEN flag)
• w – write (STORE flags other than SEEN and DELETED)
• i – insert (perform APPEND, COPY into mailbox)
• p – post (send mail to submission address for mailbox, not enforced by IMAP4 itself)
• c – create (CREATE new sub-mailboxes in any implementation-defined hierarchy)
• d – delete (STORE DELETED flag, perform EXPUNGE)
• a – administer (perform SETACL)

Note the differences between “write”, “insert”, “post” and “create” as these tend to confuse people somewhat.

Outlook Connector (and MDaemon Groupware before it) rely on the same set of IMAP ACLs, but implement them somewhat differently. For example, IMAP has no concept of “editing” an item, so instead, when you modify an item in Outlook Connector, Outlook Connector will INSERT a new item and DELETE the old item, so to edit, you require both the INSERT and DELETE rights.

In non-email folders, the “keep seen/unseen”, “w – write”, “p – post” rights are not used and can be ignored.

WorldClient implements ACLs in a nearly identical fashion to MDaemon and Outlook Connector, emulating as many of the permissions as closely as possible.

Note that users own all folders contained within their mailboxes at all times, and the owner of a folder always has all rights and even if these rights aren’t explicitly listed, they are granted. Public folders don’t have an owner.

Lastly, note that ACLs are inherited by subfolders when they are created, but permission changes to a parent don’t apply to children unless the administrator uses the “Set sub” folder to set permissions on subfolders.