test

Sun Java System Messaging Server 6.3 Administration Guide

20.7 Managing Message Types

This section includes the following topics:

20.7.1 Message Type Overview

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:

20.7.1.1 Planning the Message-Type Configuration

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

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.

20.7.1.2 Defining and Using Message Types

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:

These tasks are summarized in the following sections:

ProcedureTo Configure Message Types

To configure a message type, use the configutil utility to set the store.messagetype parameter values that define and identify the message type.

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

20.7.2 Message Types in IMAP Commands

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:

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
Example 20–1 IMAP FETCH Session Based on the Message-Type configutil Configurations

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.

Example 20–2 IMAP SEARCH Session Based on the Message-Type configutil Configurations

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.

20.7.3 Sending Notification Messages for Message Types

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

20.7.4 Administering Quotas by Message Type

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

20.7.4.1 Before You Set Message-Type Quotas

Before you can set quotas for message types, you must configure the following parameters:

20.7.4.2 Methods of Setting Message-Type Quotas

Use one of the following methods to set quotas for message types:

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.

20.7.4.3 Example of a Message-Type Quota Root

The example described in this section sets the following quotas for the user joe:

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:

  1. Configure the store.messagetype.x.quotaroot parameter as follows:


    store.messagetype.1.quotaroot = text

store.messagetype.2.quotaroot = voice

  2. Configure the mailQuota attribute for the user joe as follows:


    mailQuota: 20M;#text%10M;#voice%10M;Archive%100M

  3. 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)

20.7.5 Expiring Messages by Message Type

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.

Example 20–3 Sample Rules for Expiring Different Message Types


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:

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.