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:
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.
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).
|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).
|Media||If this flag is set, the message is treated as containing some "media" (audio/video) data.||$Media||NotMedia|
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:
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:
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:
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:
In order to be able to rename a foreign mailbox, a user should have:
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.
|anyone@||Lookup, Select, Seen|
|firstname.lastname@example.org||Lookup, Select, Seen|
|-email@example.com||Lookup, Select, Seen|
|firstname.lastname@example.org||Lookup, Select, Delete|
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.
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:
The message file name has the following format:
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:
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.
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.
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.
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.
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 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.
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.