Author: Aaron Stone
Date: August 12, 2006
A mailbox, or mail folder, may have permissions assigned to it in the database. The permissions are:
A folder may also have any number of additional Access Control List (ACL) records specifying the rights of users other than the mailbox's owner:
These permissions follow RFC 4314, “IMAP4 Access Control List (ACL) Extension,” which specifies how the ACLs work.
A folder may undergo a number of actions. The actions can be divided into two categories: delivery and access.
At delivery time, a message is received into the DBMail system through either dbmail-lmtpd (LMTP delivery) or dbmail-smtp (pipe delivery). On its way towards the INBOX, a message may be directed towards a specific folder by a command line option to dbmail-smtp, by a Sieve script, or by a subaddress specification (i.e. user+mailbox@domain). If the folder has been specified by a trusted source, that is, the command line or Sieve script, then the folder will be auto-created on the fly. Untrusted sources specifying nonexitent folders will see the message delivered to INBOX.
Now, something we might not yet handle correctly is delivery of a message to a no_select folder. This must fail and cause the message to be delivered to INBOX. : Find out if this works or not!
Something we used to not handle correctly was creating the parent folders of a deeply-nested folder created on the fly. As of 2.1.7, a recursive permissions check is performed, the mailbox hierarchy is created, and it is marked as subscribed to the user. Without this feature, many mail-readers find themselves locked in illogical states: how can a deep folder exist when none of the parent folders exist?
ACLs ought to be checked when delivering mail to a shared folder owned by another user – for example, using a Sieve script, we could try putting a message into another user's INBOX:
This must not be possible unless Joe Schmoe has given the Anyone user Create privileges to his INBOX – if Joe does that, Joe gets what Joe deserves – this could be extremely useful for certain types of email helpdesk arrangements. Bottom line, the permissions have to be checked correctly because this situation isn't unpossibly not thinkable.
|Table dbmail_mailboxes|| no_inferiors = 1 |
no_select = 1
| no_inferiors = 0 |
no_select = 1
| no_inferiors = 0
no_select = 0
|permission||1|| No subfolders. |
| Subfolders RO. |
| Subfolders RO.
|2|| No subfolders. |
| Subfolders RW. |
| Subfolders RW.
|Make this table.|
At message delivery time, the POST ACL is checked to ensure that the user receiving the mail has permission to deliver mail to the destination mailbox. This is important because a Sieve script can be used, as shown above, to direct a message to a folder outside of the user's realm of ownership.
At access time, the IMAP system always checked mailbox ownership and the ACL table before allowing a folder to be EXAMINEd, SELECTed, and so on. COPY, MOVE and APPEND are write operations, and I think they're being handled correctly. : beef this up.