Mailboxes

Mailbox Names Message Flags Mailbox Access Control Lists (ACL) Mailbox Formats Mailbox Classes Locked Mailboxes Creating Mailboxes Mailbox Subscription Mailbox Aliases CommuniGate Pro Accounts contain one or several mailboxes. Each mailbox has its own unique name and it can contain zero or more messages. The POP, IMAP, WebUser Interface, and Real-Time Application modules provide access to Account Mailboxes. Several storage formats can be used for CommuniGate Pro Mailboxes. A multi-mailbox Account can contain Mailboxes stored in different formats. Each Account always has the INBOX Mailbox. Any message delivered to a CommuniGate Pro Account is stored in its INBOX mailbox - unless some Automated Processing Rules instruct the Server to store the message in a different Mailbox.

Mailbox Names

When an Account is created, its INBOX mailbox is automatically created. The system and/or domain administrator can specify additional mailboxes to be created at that time.

A user can create a mailbox using an IMAP mailer applcation or using the WebUser Interface.

Mailboxes can be "nested": for any mailbox "A" you can create a sub-mailbox "B" - in the same way as you can created a file directory inside some other file directory. The CommuniGate Pro Server uses the slash (/) symbol as the hierarchy separator:

INBOX/important

is the name of the submailbox important "inside" the INBOX mailbox.

CommuniGate Pro allows you to store messages in some Mailbox X and at the same time you can create submailboxes X/Y, X/Z for that Mailbox. This feature is implemented by providing two "invisible" mailbox entities - one for storing messages, one - for serving as a "directory" for the nested mailboxes. The "directory" entity is created automatically, as soon as you try to create the first submailbox. You can, though, create the "directory" entity without creating the "mail storage" entity: use the ABCDEF/ name as the new mailbox name to create only the directory entity with the ABCDEF name. The name ABCDEF will be listed, but will not be "selectable" - and you will not be able to store messages in the ABCDEF mailbox. You can later create the regular ABCDEF mailbox and the "storage" entity for your ABCDEF mailbox name will be added.

It is impossible to delete the INBOX mailbox. You can rename the INBOX mailbox, though. In this case a new empty INBOX mailbox will be created automatically.

Mailbox names are case-sensitive. Some file systems (NTFS, for example) provide case-insensitive file naming conventions. When these file systems are used for CommuniGatePro account/mailbox storage, the mailbox names are still case-sensitive, but you cannot create two mailboxes with names that differ in case only. The INBOX mailbox name is an exception: it is always a case-insensitive name.

Message Flags

Messages in Mailboxes have individual flags. These flags can be set when the message is being stored in the mailbox, and they can be updated using mailbox access protocols and methods, such as IMAP, MAPI, WebUser Interface, Real-Time Applications.

Some flags are set automatically, even when the access protocol used does not support flag modification. For example, the Seen flag is set automatically when the message is being read using the POP protocol RETR command.

Several components (such as Automated Rule, CG/PL programs, etc.) can access message flags by name. They can also use "negative names" to instruct the server to reset a certain flag or to look for messages that do not have that flag set.

The following table lists the supported message flags along with their IMAP and Negative names:

Name	Description	IMAP Name	Negative Name
Seen	This flag is set when the message was read by a client. It can be set automatically as a result of certain mailbox access protocol operations, and it can be set and reset explicitly with mail client applications.	\Seen	Unseen
Read	same as Seen		Unread
Answered	This flag is set when a reply was sent for this message. This flag is explicitly set and reset with mail client applications.	\Answered	Unanswered
Flagged	This flag is set to attach a "flag" to the message (for example, a mail client can show this message to the user as an important one). This flag is explicitly set and reset with mail client applications.	\Flagged	Unflagged
Draft	This flag is set for messages that have not been sent yet. It tells a mail client that it can open and edit this message. This flag is explicitly set and reset with mail client applications.	\Draft	Undraft
Deleted	This flag is set for messages that were marked for deletion. Some mail clients allow users to mark some mailbox messages first, and then delete ("expunge") all marked messages from the Mailbox. This flag is explicitly set and reset with mail client applications.	\Deleted	Undeleted
Redirected	This flag is set when a copy of the message was sent (redirected) to someone. This flag is explicitly set and reset with mail client applications.	$Forwarded	NotRedirected
MDNSent	This flag is set when an MDN ("read report") for the message has been sent. This flag helps mail clients to send only one MDN report for each message. This flag is explicitly set and reset with mail client applications.	$MDNSent	NoMDNSent
Hidden	Messages with this flag set are visible only to the Mailbox Account owner and to those users who have the Admin Access Right for this Mailbox. This flag allows users to grant access to their Mailboxes to others while keeping certain messages private (hidden).	$Hidden	NotHidden
Service	Messages with this flag set are not visible to IMAP or POP clients. MAPI clients can use this flag to create service items invisible to users (such as mailbox forms).	$Service	NotService
Media	If this flag is set, the message is treated as containing some "media" (audio/video) data.	$Media	NotMedia

Mailbox Access Control Lists

The CommuniGate Pro Server maintains an Access Control List (ACL) for every mailbox it creates. Each element of the Access Control List contains a name and a set of Mailbox access rights granted to that name.

The Access Control Lists are used to control the Foreign Mailbox Access feature that allows one Account user to access mailboxes in other Accounts.

An ACL element name can be:

anyone

This ACL element specifies the access rights granted to everybody.

anyone@

This ACL element specifies the access rights granted to everybody in the same CommuniGate Pro Domain.

anyone@domainName

This ACL element specifies the access rights granted to everybody in the CommuniGate Pro domainName Domain.

accountName

This ACL element specifies the access rights granted to the accountName Account user.

accountName@domainName

This ACL element specifies the access rights granted to a user in a different CommuniGate Pro Domain.

#groupName

This ACL element specifies the access rights granted to all members of the groupName Group (in the same Domain).

An ACL element name can has a + or a - prefix.

Account owners always have all access rights to all mailboxes in their own Accounts.

For any other someaccount Account, the effective access rights are checked.

The effective access rights are calculated in several steps:

• If there is an ACL element for the someaccount name (without a + or a - prefix), then the Access right specified in that ACL element are used as the effective access rights.
  Otherwise
• All ACL elements without a + or a - prefix and matching the someaccount name are merged to form the "direct" access rights.
• All ACL elements with the - prefix and matching the someaccount name are merged to form the "removed" access rights.
• All ACL elements with the + prefix and matching the someaccount name are merged to form the "added" access rights.
• The "removed" access rights are removed from the "direct" access rights.
• The "added" access rights are merged with the "direct" access rights.
• The resulting "direct" access rights are used as the effective access rights.

A Server Administrator with the All Accounts and Domains access right has all access rights for all Server or Cluster mailboxes.

Domain Administrators with the CanViewMailboxes access right have all access rights for all mailboxes in their Domains.

The following Mailbox access rights are supported:

l (Lookup)

If you grant a user the Lookup access right, that user will be able to see this mailbox when it asks the Server to list all mailboxes in your Account.

r (Read/Select)

If you grant a user the Read access right, that user will be able to open (select) this mailbox and see (read) the messages in this mailbox.

s (Seen)

If you grant a user the Seen access right, that user will be able to mark messages as read (seen). Usually a message is automatically marked as seen when a user reads it. But if this access right is not granted to a user reading the mailbox, the mailbox message "seen" status will not be changed.

w (Write/Flags)

If you grant a user the Write access right, that user will be able to set message flags: i.e. to mark messages as answered or "flagged", and to reset the message flags.

d (Delete)

If you grant a user the Delete access right, that user will be able to mark messages as deleted and to compress the mailbox, removing all its messages marked as deleted.

i (Insert)

If you grant a user the Insert access right, that user will be able to append messages to this mailbox and to copy messages from other mailboxes into this one.

p (Post)

This access right is not used by modern mailers.

c (Create)

If you grant a user the Create access right, that user will be able to create new submailboxes "inside" this mailbox.

a (Administer)

If you grant a user the Administer access right, that user will be able:

• to modify the mailbox ACL
• to modify the mailbox meta-data (such as the Mailbox Class)
• to see Hidden mailbox messages.

When a submailbox is created, it inherits the ACL of the "parent" mailbox. This means that if you create the INBOX/sales mailbox, it is created with the same ACL as specified for the INBOX mailbox.

The Access Control Lists can be set and modified using either the WebUser Interface or using a decent IMAP client.

In order to be able to delete a foreign mailbox, a user should have:

• the Create access right for the outer (parent) mailbox, and
• the Delete access right for the specified mailbox.

In order to be able to rename a foreign mailbox, a user should have:

• the Create access right for the outer (parent) mailbox of the original mailbox, and
• the Delete access right for the specified original mailbox, and
• the Create access right for the outer (parent) mailbox of the new mailbox (mailbox name).

When granting access rights, the real Account names, not Account Aliases should be used. If an Account j.smith has two aliases john.smith and jonny, the access rights should be granted to the name j.smith.

Samples:

Grant the Lookup, Select, and Seen access rights to all users in the same domain, excluding the user John, who should have only the Lookup right, and the user Susan who should have the Lookup, Select, Seen, and Delete rights:

anyone@		Lookup, Select, Seen
-john		Select, Seen
+susan		Delete

Grant the Lookup, Select, and Seen access rights to all users in a different company2.com Domain, excluding the user john@company2.com who should have no access rights, and grant the Lookup, Select, and Delete rights to the user susan in a yet another company3.com Domain.

anyone@company2.com		Lookup, Select, Seen
-john@company2.com		Lookup, Select, Seen
susan@company3.com		Lookup, Select, Delete

Mailbox Formats

CommuniGate Pro stores received messages in Account mailboxes. The server supports several mailbox formats, and the mailbox type is defined by the mailbox file (or directory) name extension.

For single-mailbox accounts, the mailbox type is specified when the account is created.

Each multi-mailbox account has a setting that specifies the default type for all new mailboxes created in this account. A user can explicitly specify the mailbox type creating a mailbox in a multi-mailbox account: if the maibox name is specified as name.extension, then the mailbox name of the extension type is created.

The TextMailbox (.mbox) Format

The mailbox files with this extension store messages in the legacy BSD mailbox format. Each message in the mailbox is preceded with the a From-line:

From <return-path>(flags-UID) time stamp

This is the same format as one used in legacy mail systems, but with a "comment" added after the return-path part. The .mbox format remains compatible with legacy applications (local mailers), and at the same time it allows the CommuniGate Pro Server to store the required message information (message status flags and the unique mailbox message ID).

If a mailbox file has been copied from an old system, or when it is used as an External INBOX and old applications can add messages to this mailbox, some messages may have no "comment;" part. CommuniGate Pro allows a user to work with such messages, but it does not store message flags if they were modified, and it does not remember the message UIDs between sessions. The simplest solution is to copy such messages to a different mailbox and then copy them back to the original mailbox - the copy operation places the correct information into the From-line.

When a message is being stored in the .mbox-type mailbox, all message lines are checked. If there is an empty line followed with the line starting with the letters From, the '>' symbol is inserted before the letter F.

The TextMailbox mailboxes become less effective as their size grows. When a TextMailbox is being opened, it has to be parsed, in order to detect message boundaries and retrieve the UID, flags, and other per-message information. When some messages are being deleted from the middle of a TextMailbox mailbox, the Server has to copy the remaining messages data, compressing the mailbox. To make these processes more efficient, the CommuniGate Pro server can deal with mailbox data in large chunks. A special semaphore object limits the number of buffers allocated for large mailbox processing. Changing this parameter can change the overall large mailbox access (you may want to increase or decrease it, depending on the OS and file system you use).

To improve TextMailbox opening speed, the CommuniGate Pro can maintain a mailbox index (.bdx) file alongside the TextMailbox mailbox file. If the index file exists, the Server reads it instead of parsing the entire mailbox file. CommuniGate Pro automatically creates an index file when it the mailbox size exceeds the specified limit. The Server removes the index file if the mailbox becomes smaller than that limit.
The Index file is created when any message in the mailbox is modified or deleted. If new messages have been added to the mailbox, but the mailbox has not been opened, or it has been only read without any flag modification, the Index file may not be created.

You can modify the TextMailbox Manager settings by opending the Obscure page in the Settings realm of the WebAdmin Interface:

TextMailbox Manager
Concurrently used large buffers: disabled1234571015203050100other Index Mailboxes larger than: 0 Kbyte1 Kbyte3 Kbytes10 Kbytes30 Kbytes100 Kbytes300 Kbytes1 Mbyte3 Mbytes10 Mbytes30 Mbytes100 MbytesOther

Concurrently used large buffers

Use this setting to specify how many concurrent operations (parsing, deletion) the TextMailbox Manager can perform on large mailboxes.

Index Mailboxes larger than

Use this setting to specify the minimal size for mailboxes that need indexing.

The MailDirMailbox (.mdir) Format

Mailboxes with this extension are file directories. Each mailbox message is stored as a separate file in the mailbox directory.

The message file name has the following format:

iiii-flags-timestamp

where iiii is the message unique ID, flags are the message status flags, and the timestamp is the message internal time stamp - the time (GMT) when the message was added to the mailbox, in the yyyymmddhhmmss format.

Note:

On the Unix platforms, the .mdir mailboxes implement the shared storage model: if the same message is directed to many accounts/mailboxes, only one message file is created, and a hard link to that file is placed into each mailbox directory. When a message is removed from all mailboxes, the file is automatically deleted by the OS.

Note: most of freeware mail systems use either the mbox-like or mdir-like formats, and designers of those systems make various claims about the advntages of the formats they have selected. It is very important to remember that:

• CommuniGate Pro does not use OS or file system features (locks) to provide multi-access to mailboxes. CommuniGate Pro mailboxes in all formats can be accessed by several clients at the same time, and all synchronization is implemented in the CommuniGate Pro Mailbox Manager that works in the same way for all mailbox formats.
• CommuniGate Pro uses efficient mechanisms to parse mailboxes, so many claims about various mailbox formats being 'slower' or 'faster' than other formats usually do not apply to CommuniGate Pro installations.
• CommuniGate Pro allows users to create mailboxes in different formats, even within the same Account.

Note: the .mbox format is more efficient than .mdir in most cases, this is why this format is used as the default one. The .mdir format is recommended only for those mailboxes that contain many (20 or more) large (100K or more) messages. If a user has a Proposals mailbox where she stores all messages with attached documents, each 50-70K in size, then this mailbox may work faster if it is created in the .mdir format.

Mailbox Classes

Each Mailbox can have a Class attribute. This attribute specifies the type of the information this mailbox is created for: Calendar, Contacts, Tasks, Notes, etc. If a Mailbox does not contain the Class attribute, it means that it is created to store regular E-mail messages.

The Mailbox Class does not restrict the types of data that can be stored in the Mailbox: E-mail and Contacts messages can be stored in mailboxes with the Tasks Class, Notes messages can be stored in Calendar Class mailboxes, etc. The Mailbox Class information is used with the advanced user interfaces (WebUser, MAPI) to present the Mailbox content in the proper format.

When a Mailbox is created with an advanced client interface, the interface can set the Mailbox Class. Mailbox Classes can also be updated using the CommuniGate Pro CLI/API.

Locked Mailboxes

Each Mailbox can have the Locked attribute. If this attribute is set, the Mailbox cannot be deleted or renamed.

A locked Mailbox can be deleted or renamed together with its parent Mailbox, if the parent Mailbox itself is not locked.

You can specify the Locked attribute for the Mailboxes created using the Account Template. The Mailbox Locked attribute can also be updated using the CommuniGate Pro CLI/API.

Creating Mailboxes

Every Account has a setting that specifies the default format for new mailboxes that can be created in this Account.

The Account user can explicitly specify the storage format for a new Mailbox by adding the format extension to the new Mailbox name. If a user tells the CommuniGate Pro Server to create the newmailbox.mdir Mailbox, the .mdir-formatted mailbox newmailbox is created.

Mailbox Subscription

The CommuniGate Pro Server allows an account user to subscribe to some mailboxes. The account mailbox subscription is a simple list of mailbox names. This list is not used by the Server itself - the Server just stores one subscription list for each account.

Many IMAP mailers use the account subscription list and show only the mailboxes the account is subscribed to. The WebUser Interface can also be configured to show only the subscribed mailboxes.

You can modify the account subscription either via a decent IMAP mailer, or using the WebUser Interface.

You can use the account mailbox subscription to make some not-so-decent IMAP mailers access foreign mailboxes: make sure that your IMAP client is configured to use the account mailbox subscription, and add the desired foreign mailbox name into the subscription list.

Note:Some IMAP mailers tend to rebuild account subscription lists: they empty the subscription, and then subscribe you to all mailboxes in your own account.

The account mailbox subscription is stored in the account .info service file.

Mailbox Aliases

Many IMAP clients (such as Microsoft Outlook and Outlook Express) cannot handle foreign mailboxes directly, and they cannot use the Account mailbox subscription to access foreign mailboxes.

Mailbox aliases can be used to let these IMAP clients access foreign mailboxes.

Mailbox alias is a name associated with some [foreign] mailbox name. For example, you can create a mailbox alias salesBox for the ~sales/INBOX mailbox name. You will see the salesBox mailbox in your IMAP mailer, but in reality this will be the INBOX mailbox in the sales account.

Mailbox aliases can be created only on the topmost level of the account mailbox hierarchy, that means that the mailbox alias name cannot contain the slash ("/") sign.

Mailbox aliases can contain just the name of the foreign account (~accountName). Such an alias provides access to all accessible mailboxes in that foreign account. The mailbox alias itself is presented as an unselectable mailbox name.

Sample configuration:

The owner of the account chief has granted "lookup" and other access rights for his mailboxes INBOX and Pending to the assistant account.

The user assistant has created the mailbox alias boss pointing to ~chief.

When the user assistant connects to her account using any IMAP client or the WebUser Interface, she sees all her own mailboxes, the unselectable mailbox boss, and also the boss/INBOX and boss/Pending mailboxes.

If the user cheif creates a new mailbox Urgent in his account and grants access rights for that mailbox to the assistant account, the user assistant will immediately see the new mailbox as the boss/Urgent mailbox.