Computing permissions
Each time the server needs to determine if a specific action on a specific resource is allowed or denied for a specific administrative user the following reasoning is used:- - if the permission is set to deny on at least one of the parent folders in the chain, for the user or a group that the user belongs to, the permission will be denied
- if the permission is not denied on any of parent folders in the chain but allowed on at least one, for the user and/or a group that the user belongs to, the permission will be allowed
- if the permission is neutral (not set) on all parent folders in the chain, for the user and/or a group that the user belongs to, the permission will be denied
Permissions description
Read items - Folder is visible and its contained items can be read.View items - Folder appears in hierarchy ("lookup").
Read folder content - Items in this folder may be read.
Share the read / unread status - Changes to the read / unread flag are seen by other users (does not apply for contacts, calendar, tasks, journal and notes folders).
Set / clear flags - Modify flags other than read / unread and deleted / not deleted (does not apply for contacts, calendar, tasks, journal and notes folders).
Add items - Add new items to folder (create new, move to, copy to). Both 'add items' and 'delete items' permissions are required for modifiying items.
Add sub-folders - Add new sub-folders below this folder (create new, move to, copy to).
Delete folder - Delete this folder, including all its contained items.
Delete items - Delete items in this folder. Both 'add items' and 'delete items' permissions are required for modifying items.
Mark items as deleted / not deleted - Modify the deleted / not deleted flag.
Expunge folder - Purge items marked with the deleted flag.
Manage permissions - Modify permissions on this folder.
Types of permissions
When new entities are created they can have two types of permissions:1. Implicit permissions do not appear in the permissions list for resources, cannot be modified (they are resolved directly by the MACL engine) and cannot be overridden with an explicit 'DENY' from any level (above or below). These are:
- the 'postmaster' user has 'all rights' on all public folders
- the 'postmaster' user has 'Lookup' and 'Manage permissions' on all folders of all the accounts in its domain
- the 'postmaster' user has 'all rights' on his mailbox (and all sub-folders)
- each user has 'all rights' on his/her mailbox (and all sub-folders)
- newly created folder in the PF namespace or in a mailbox other than the creator's, the creator has 'all rights', with 'apply to sub-folders'
- if the newly created public folder is created from the WebAdmin interface, no explicit permissions are set for it
- when a new domain is created, the PF root contains the permission: 'all users in domain, allow, Lookup, apply to sub-folders'










