Author: Aaron Stone
Date: August 12, 2006

A mailbox, or mail folder, may have permissions assigned to it in the database. The permissions are:

• no_inferiors: mailbox cannot contain other mailboxes.
• no_select: mailbox cannot contain messages.
• permission: 1 for read-only, 2 for read-write.

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:

• lookup_flag
• read_flag
• seen_flag
• write_flag
• insert_flag
• post_flag
• create_flag
• delete_flag
• administer_flag

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:

  fileinto "#Users/joeschmoe/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.

ACL	Operation
	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.