This section includes the following topics:
A unified messaging application can receive, send, store, and administer messages of many types, including text messages, voice mail, fax mail, image data, and other data formats. The message store allows you to define up to 63 different message types.
One method of manipulating messages by type is to organize the messages by their types into individual folders.
With the introduction of the message type feature, you do not have to maintain different message types in individual mailbox folders. Once you configure a message type, the message store can identify it, no matter where it is stored. Thus, you can store heterogeneous message types in the same folder. You also can perform the following tasks:
Track the usage of message types
Send notifications grouped by message type
Set and administer different quotas for different message types, whether they are stored in the same folder or different folders
Move messages from one folder to another, according to criteria configured uniquely for each message type
Expire messages according to criteria configured for each message type
In a unified messaging application, data of heterogeneous formats are given standard internet message headers so that Messaging Server can store and manage the data. For example, when voice mail is sent to an end-user's phone, a telephone front-end system adds a message header to the incoming voice mail and delivers it to the message store.
In order to recognize and administer messages of different types, all components of the unified messaging system must use the same message-type definitions and the same header fields to identify the messages.
Before you configure the message store to support message types, you must
Plan which message types you intend to use
Decide on the definition for each message type
Decide which header field to use
For example, if your application includes phone messages, you can define this message type as “multipart/voice-message” and use the Content-Type header field to identify message types.
You would then configure the telephone front-end system to add the following header information to each phone message to be delivered to the message store:
Content-Type: multipart/voice-message
Next, you would configure the message store to recognize the multipart/voice-message message type, as described in the sections that follow.
You define a message type by giving it a unique definition such as multipart/voice-message. By default, the message store reads the Content-Type header field to determine the message-type. If you prefer, you can configure a different header field to identify the message types.
The message store reads the Content-Type (or other specified) header field, ignoring case. That is, the message store accepts the header field as valid even if the header's combination of uppercase and lowercase letters differs from the expected combination.
The message store reads only the message-type name in the header field. It ignores additional arguments or parameters.
To define a message type, use the configutil utility to set values for the store.messagetype parameters. For instructions, see To Configure Message Types.
Configuring a message type allows the message store to identify and manipulate messages of the specified type. It is the first, essential step in administering message types in a unified messaging application.
To take full advantage of the message-type features provided by the message store, you also should perform some or all of the following tasks:
Configure a JMQ notification plug-in and write Message Queue clients for retrieving notifications that track the status of the message types
Configure quota roots that apply to each message type
Write expire rules and set LDAP attribute values to expire and purge messages according to message type
These tasks are summarized in the following sections:
To configure a message type, use the configutil utility to set the store.messagetype parameter values that define and identify the message type.
Enable message types by setting the store.messagetype.enable parameter to on.
This configutil parameter allows the message store to identify and manipulate message types. You must set this parameter before you can configure an individual message type.
For example, enter the following command:
configutil -o store.messagetype.enable -v 1 |
Define and identify the message type by setting the store.messagetype.x parameter.
The variable x identifies this particular message type in the message store. The variable x must be an integer greater than zero and less than 64. You can define up to 63 message types by iteratively configuring this parameter with unique integers.
You define the value of the message type with a text string that describes the type.
For example, to define a text message type, you could enter the following command:
configutil -o store.messagetype.1 -v text/plain |
To define a voice message type, you could enter the following command:
configutil -o store.messagetype.2 -v multipart/voice-message |
Provide a flag name for the message type by setting the store.messagetype.x.flagname parameter.
This parameter creates a unique flag that identifies the message type. The flag is automatically set whenever a message of this type first arrives in the message store and remains associated with the message until it is purged. The flag name value is a text string that describes the message type. It does not have to be the same as the value set with the store.messagetype.x parameter.
The variable x is the integer ID of the message type defined with the store.messagetype.x parameter.
For example, to define flag names for the message types configured in the preceding step, enter the following commands:
configutil -o store.messagetype.1.flagname -v text configutil -o store.messagetype.2.flagname -v voice_message |
Configure a quota root name for the message type by setting the store.messagetype.x.quotaroot parameter.
This parameter enables the quota function to identify and manage a quota root for this message type. The parameter value is a name—a text string that describes the message type. It does not have to be the same as the value set with the store.messagetype.x parameter.
The variable x is the integer ID of the message type defined with the store.messagetype.x parameter.
When this parameter is configured, you can set a quota that applies to the specified message type. For more information, see 20.7.4 Administering Quotas by Message Type.
For example, to enable the use of quota roots for the message types configured in the preceding steps, enter the following commands:
configutil -o store.messagetype.1.quotaroot -v text configutil -o store.messagetype.2.quotaroot -v voice |
To configure an alternate header field for identifying the message type, set the store.messagetype.header parameter.
By default, the message store reads the Content-Type header field to determine the message type. Configure the store.messagetype.header parameter only if you want to use a different header field for identifying the message type. The value of this parameter is a text string.
For example, to use a field called X-Message-Type, enter the following command:
configutil -o store.messagetype.header -v X-Message-Type |
When you configure the store.messagetype.x.flagname parameter for a message type, you create a unique flag that identifies the message type. This flag cannot be modified by end users.
Messaging Server presents the message-type flag as a user flag to IMAP clients. Mapping the message type to a user flag allows mail clients to use simple IMAP commands to manipulate messages by message type.
For example, you can perform the following operations:
Use the IMAP FETCH FLAGS command to display a message-type flag name as a user-defined flag to the client.
For a sample use of the IMAP FETCH FLAGS command, see Example 20–1, shown below.
Use a message-type flag as a keyword in an IMAP SEARCH command.
For a sample use of the IMAP SEARCH command, see Example 20–1, shown below.
The message-type user flag is read only. It cannot be modified by IMAP commands.
The following examples assume you configure the message-type configutil parameters with the values shown here:
store.messagetype.enable = yes store.messagetype.1 = text/plain store.messagetype.1.flagname = text store.messagetype.1.quotaroot = text store.messagetype.2 = multipart/voice-message store.messagetype.2.flagname = voice_message store.messagetype.2.quotaroot = voice |
The following IMAP session fetches messages for the currently selected mailbox:
2 fetch 1:2 (flags rfc822) * 1 FETCH (FLAGS (\Seen text) RFC822 {164} Date: Wed, 8 July 2006 03:39:57 -0700 (PDT) From: bob.smith@siroe.com To: john.doe@siroe.com Subject: Hello Content-Type: TEXT/plain; charset=us-ascii * 2 FETCH (FLAGS (\Seen voice_message) RFC822 {164} Date: Wed, 8 July 2006 04:17:22 -0700 (PDT) From: sally.lee@siroe.com To: john.doe@siroe.com Subject: Our Meeting Content-Type: MULTIPART/voice-message; ver=2.0 2 OK COMPLETED |
In the preceding example, two messages are fetched, one text message and one voice mail.
The message-type flags are displayed in the format configured with the store.messagetype.*.flagname parameter.
The Content-Type header fields identify the message types. The message-type names are displayed as they were received in the incoming messages. They use mixed uppercase and lowercase letters and include the message-type arguments such as charset=us-ascii.
The following IMAP session searches for voice messages for the currently selected mailbox:
3 search keyword voice_message * SEARCH 2 4 6 3 OK COMPLETED |
In the preceding example, messages 2, 4, and 6 are voice messages. The keyword used in the search is voice_message, the value of the store.messagetype.2.flagname parameter.
Notifications can deliver status information about messages of different types, such as text messages, voice mail, and image data. Messaging Server uses Sun Java System Message Queue to send notification information for message types. For information about configuring the JMQ notification plug-in for Message Queue, see Chapter 22, Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue
To enable the JMQ notification plug-in to recognize a particular message type, you must configure the store.messagetype parameters, including the store.messagetype.x.flagname parameter. For details, see To Configure Message Types.
Once the message types have been configured, JMQ notification messages can identify the particular message types. You can write a Message Queue client to interpret notification messages by message type and deliver status information about each type to the mail client.
The JMQ notification function counts the number of messages currently in the mailbox, by message type. Instead of sending one count, an array specifying the count for each message type is sent with the notification message.
For example, a NewMsg notification message can carry data to tell the user that, for example, there are seven new voice mail messages and four new text messages in the user's inbox.
For more information about sending notifications by message type, see 22.3.3 Notifications for Particular Message Types
When you set a quota for a message type, you include that value in a quota root. A quota root specifies quotas for a user. It can specify different quotas for particular message types and mailbox folders, and it can specify a default quota that applies to all remaining message types, folders, and messages not defined by type.
For complete information about setting and managing quotas, see 20.8.2 Quota Theory of Operations
Before you can set quotas for message types, you must configure the following parameters:
Set the store.messagetype.x.quotaroot parameter for each message type. For details, see To Configure Message Types.
Set the store.typequota.enable parameter to on.
For example, enter the following command:
configutil -o store.typequota.enable -v 1 |
Use one of the following methods to set quotas for message types:
Set message-type quotas for a user with the LDAP attributes mailQuota or mailMsgQuota (or both).
For information about how to set quota roots with these attributes, see the mailQuota and mailMsgQuota entries in Chapter 3, Messaging Server and Calendar Server Attributes, in Sun Java Communications Suite 5 Schema Reference.
Set default message-type quotas that apply to all individual users when the mailQuota and mailMsgQuota attributes are not set.
To set default quotas, use the store.defaultmessagequota or store.defaultmailboxquota parameter (or both).
For information about how to set quota roots with these parameters, see 20.8.4 Configuring Message Store Quotas.
When you set a quota for the message type with a configutil parameter or LDAP attribute shown above, you must use the quota root specified with the store.messagetype.x.quotaroot parameter.
The example described in this section sets the following quotas for the user joe:
The default mailbox storage quota is 40 M
The default mailbox message quota is 5000
The storage quota for the Archive folder is 100M
The storage quota for text message types is 10 M
The message quota for text message types is 2000
The storage quota for voice message types is 10 M
The message quota for voice message types is 200
This quota root permits greater storage in the Archive folder (100 M) than in all the other folders and message types combined (60 M). Also, no message limit is set for the Archive folder; in this example, only storage limits matter for archiving.
The message types have both storage and number-of-message quotas.
The message-type quotas apply to the sum of all messages of those types, whether they are stored in the Archive folder or in any other folder.
The default mailbox quotas apply to all messages that are not text or voice message types and are not stored in the Archive folder. That is, the message-type quotas and Archive quota are not counted as part of the default mailbox quotas.
To set the quota root in this example, you would take the following steps:
Configure the store.messagetype.x.quotaroot parameter as follows:
store.messagetype.1.quotaroot = text store.messagetype.2.quotaroot = voice |
Configure the mailQuota attribute for the user joe as follows:
mailQuota: 20M;#text%10M;#voice%10M;Archive%100M |
Configure the mailMsgQuota attribute for the user joe as follows:
mailMsgQuota: 5000;#text%2000;#voice%200 |
When you run the getquotaroot IMAP command, the resulting IMAP session displays all quota roots for the user joe's mailbox, as shown here:
1 getquotaroot INBOX * QUOTAROOT INBOX user/joe user/joe/#text user/joe/#voice * QUOTA user/joe (STORAGE 12340 20480 MESSAGE 148 5000) * QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000) * QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200) 2 getquotaroot Archive * QUOTAROOT user/joe/Archive user/joe/#text user/joe/#voice * QUOTA user/joe/Archive (STORAGE 35424 102400) * QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000) * QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200) |
The expire and purge feature allows you to move messages from one folder to another, archive messages, and remove messages from the message store, according to criteria you define in expire rules. You perform these tasks with the imexpire utility.
Because the imexpire utility is run by the administrator, it bypasses quota enforcement.
For information about how to write expire rules and use the imexpire utility, see 20.9 To Set the Automatic Message Removal (Expire and Purge) Feature
You can write expire rules so that messages of different types are expired according to different criteria.
The expire feature is extremely flexible, offering many choices for setting expire criteria. This section describes one example in which text and voice messages are expired according to different criteria.
The example assumes you have configured text and voice message types as follows:
store.messagetype.1 = text/plain store.messagetype.2 = multipart/voice-message |
Assume also that the message store is configured to read the Content-Type header field to determine the message type.
TextInbox.folderpattern: user/%/INBOX TextInbox.messageheader.Content-Type: text/plain TextInbox.messagedays: 365 TextInbox.action: fileinto:Archive VoiceInbox.folderpattern: user/%/INBOX VoiceInbox.messageheader.Content-Type: multipart/voice-message VoiceInbox.savedays: 14 VoiceInbox.action: fileinto:OldMail VoiceOldMail.folderpattern: user/%/OldMail VoiceOldMail.messageheader.Content-Type: multipart/voice-message VoiceOldMail.savedays: 30 VoiceOldMail.action: fileinto:Trash Trash.folderpattern: user/%/Trash Trash.savedays: 7 Trash.action: discard |
In this example, text messages and voice mail are expired in different ways, and they follow different schedules, as follows:
Text messages are moved from a user's inbox to the user's Archive folder one year after they arrive in the message store.
Voice mail is moved from the inbox to the OldMail folder after two weeks. If the user saves a voice message, the saved date is reset, and the message is moved two weeks after the new date.
Voice mail is moved from the OldMail folder to the Trash folder after 30 days. The user also can save a voice message in the OldMail folder, which postpones the removal of the message for another 30 days after the new saved date.
Messages of all types are discarded seven days after they are moved to the Trash folder.
The expire rules move voice mail to Trash automatically. Text messages are moved to Trash when a user deletes them.
Note: The savedays rule causes a message to be expired the specified number of days after the message is saved. In a typical voice mail system, a user can save voice mail on the voice mail menu. For text messages, a message is saved when it is moved to a folder. The messagedays rule causes a message to be expired the specified number of days after it first arrives in the message store, no matter which folder it is stored in or how often it is moved.