Chapter 22 Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue

This chapter describes how to configure a JMQ notification plug-in to produce messages to be consumed by clients in a Message Queue service.

This chapter contains the following sections:Chapter 22, Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue

• 22.1 JMQ Notification Overview

• 22.2 Configuring a JMQ Notification Service

• 22.3 JMQ Notification Messages and Properties

22.1 JMQ Notification Overview

The Messaging Server notification plug-in allows you to deliver notification messages to a messaging service or event service. The messaging service sends the notifications to consumers (client interfaces), which filter and deliver the messages to specified users.

For example, when new email arrives in a user's mailbox, the notification plug-in delivers a notification message to the messaging service. The message consumer, a component of the messaging service, receives the notification and sends it to the user's email client (such as Communications Express or Mozilla mail). The email client can then display a pop-up on the user's computer screen: “You have received a new message.”

Another example: if a user's mailbox exceeds its quota, the notification plug-in produces an over-quota notification message. The message consumer sends a warning to the user and to an administrator who needs to be informed of the event.

22.1.1 Two Notification Messaging Services

You can configure Messaging Server to deliver notifications to two different messaging services:

• Sun Java System Message Queue 3.6 2005Q4

• Event Notification Service

The Message Queue service implements the Java Messaging Service (JMS) specification, providing a message broker, interfaces to create clients that produce or consume messages, and administrative services and control. Message Queue follows the JMS standard for routing and delivery functions, protocols, and message formats.

The Event Notification Service is a component bundled with Messaging Server and Sun Java System Calendar Server. It is a proprietary service that uses a publish/subscribe architecture for sending and receiving event notifications.

You can configure a notification producer for Message Queue, for the Event Notification Service, or for both services.

This chapter describes how to configure notifications for Message Queue only.

For information about the Event Notification Service, see the Sun Java System Communications Suite Event Notification Service Guide.

22.1.2 Notification Plug-ins

To enable Messaging Server to produce notifications to Message Queue or the Event Notification Service, you must configure a plug-in for that service:

• The JMQ notification plug-in allows you to deliver notification messages to the Message Queue broker.

• The iBiff plug-in allows you to publish notification events to the Event Notification Service.

For information on how to load the iBiff plug-in and configure the Event Notification Service, see “Appendix B: Administering Event Notification Service in Messaging Server,” in the Sun Java System Messaging Server Administration Guide.

22.1.3 Benefits of Using JMQ Notification

The JMQ notification plug-in, with Message Queue, provides the following benefits:

• Message Queue implements the JMS standard.

• With Message Queue, you can produce messages to a topic or a queue, or to both of these delivery methods. For a brief definition, see 22.1.3.1 Publishing to a Topic or a Queue.

• Message Queue offers enhanced load balancing during message distribution, especially when messages are produced to a queue.

• The JMQ notification plug-in allows you to configure up to five notification plug-ins. The different plug-ins can produce messages to a topic, to a queue, to the Event Notification Service, and so on. For details, see 22.1.3.2 Using Multiple JMQ Notification Plug-ins.

• Message Queue provides reliable delivery of notifications.

  For example, if you configure the JMQ notification plug-in to produce messages with the persistent flag enabled, the message remains in the Message Queue broker until a consumer receives it. The message is saved so that, if a server goes down, the message can be retrieved and made available to the appropriate consumer.

22.1.3.1 Publishing to a Topic or a Queue

A topic and queue use different messaging delivery patterns; each one can be configured in a Message Queue service.

Topic. When a message producer sends a message to a topic, a publish/subscribe architecture is used. In this broadcast pattern, a producer sends a message to a topic destination. Any number of consumers can be subscribed to this topic destination. Each consumer subscribed to the topic gets its own copy of the message. If no consumers are subscribed to the topic, the message is discarded.

The Event Notification Service also uses a publish/subscribe architecture; it is similar to the topic pattern defined in Message Queue.

Queue. When a message producer sends a message to a queue, a point-to-point architecture is used. In this pattern, a producer sends a message to a queue destination from which only one consumer can receive it. If several consumers are waiting for messages from the queue, only one subscriber will receive the message. If no consumers are waiting, the message is held until either the message times out, or a consumer expresses an interest in the queue.

Producing messages to a queue allows you to spread the message load across multiple consumers.

22.1.3.2 Using Multiple JMQ Notification Plug-ins

You can configure from one to five notification plug-ins.

Messaging Server provides a plug-in library at the following default location:

/opt/SUNWmsgsr/lib/libjmqnotify

You use the configutil utility to specify parameters for a plug-in and to point the plug-in to the library of executable code.

If you specify more than one plug-in, each plug-in produces notification messages independently of the others. For example, if two plug-ins are configured with a delete-message parameter, and a message is deleted from a user's mailbox, both plug-ins will produce a notification message.

By configuring multiple plug-ins, you can take advantage of different message-distribution patterns for different purposes. For example, you could configure three different plug-ins to produce messages

• To a queue (using Message Queue)

• To a topic (using Message Queue)

• To the Event Notification Service

22.1.3.3 Configuring Parameters for a Notification Plug-in

For each plug-in you configure, you must define a separate set of configutil parameters.

The parameters determine two kinds of information:

• The kinds of notification messages to produce. For example, enabling the LogUser parameter causes a notification message to be sent whenever a user logs in or out.

• Configuration information needed by Message Queue. For example, the jmqHost parameter identifies the IP address of the host where the Message Queue broker is running.

For instructions on how to configure a plug-in, see To Configure a JMQ Notification Plug-in.

22.2 Configuring a JMQ Notification Service

This section briefly describes how a JMQ notification plug-in fits into the context of a complete Message Queue service. It then provides detailed instructions for configuring a JMQ notification plug-in.

22.2.1 Planning for Your JMQ Notification Service

A JMQ notification plug-in is only one part of a Message Queue service. A messaging service also includes clients that consume the messages and the Message Queue infrastructure (the broker, administration components, and so on).

The following steps outline the tasks you should perform to create a Message Queue service that supports Messaging Server:

1. Design your notification message service.

   Define the notification messages needed for your Messaging Server installation. The planning and design phases of your message-service development lifecycle lie outside the scope of this chapter. However, you should answer the following design questions before you configure the JMQ notification plug-in:

   • Which message events do you need to produce notifications? For a list of the available notification messages, see 22.3.1 Notification Messages.

   • Do you intend to produce messages to a queue, a topic, or both?

   • Do you intend to use the proprietary Event Notification Service as well as the Message Queue service?

   The answers to these questions will help you decide whether to configure one notification plug-in or multiple plug-ins, and to determine how to configure each plug-in.

2. Install, configure, and deploy the Message Queue product.

   For information about installing Message Queue, see the Sun Java System Message Queue Installation Guide.

   For information about configuring and deploying Message Queue, see the Sun Java System Message Queue Administration Guide.

3. Write one or more Message Queue clients that will consume the JMQ notification messages.

   The clients must conform to the requirements for a Message Queue client API. A simple example of client source code, written in C, is available in the following path:

   /opt/SUNWmsgsr/examples/jmqsdk/

   The source file name is jmqclient.c.

   This client source code receives messages from the JMQ notification messages defined by the parameters in the libjmqnotify library. It then sends the message output to stdout.

   For information about writing Message Queue clients in C or Java, see the Sun Java System Message Queue Developer's Guide for C Clients or the Sun Java System Message Queue Developer's Guide for Java Clients.

4. Configure and enable the JMQ notification plug-in for producing notification messages.

   The remainder of this chapter describes how to configure the notification plug-in.

5. Configure and start the runtime Message Queue clients.

   For information about deploying the runtime Message Queue clients, see the Sun Java System Message Queue Administration Guide.

To Configure a JMQ Notification Plug-in

In this procedure, you first configure the message events that will produce notifications. Next, you specify the information needed by Message Queue. Finally (in step 9), you configure the plug-in name by specifying a parameter after the name of the plug-in library:

'/opt/SUNWmsgsr/lib/libjmqnotify$plug-in_name'

If you do not specify a plug-in name, jmqnotify is used by default.

Before You Begin

You should install, configure, and deploy the following products:

• Sun Java System Messaging Server

• Sun Java System Message Queue 3.6 SP3 2005Q4 or later

Most of the configutil parameters you will configure in the following steps are optional. For a list of their default values, see Table 22–2.

1. Configure the notification message parameters.

   For each kind of notification message you want to include in the plug-in, use the local.store.notifyplugin command with the configutil utility.

   For example, to enable notifications for new messages, enter:

   configutil -o local.store.notifyplugin.jmqnotify.NewMsg.enable -v 1

   where jmqnotify is the name of the plug-in

   and -v 1 enables notifications for this message. A value of 0 disables notifications for this message.

   For a list of all the JMQ notification messages, see 22.3.1 Notification Messages.

   For definitions of the configutil parameters that enable the JMQ notification messages, see “Chapter 3: Messaging Server Configuration,” in the Sun Java System Messaging Server Administration Reference.

   A few notification messages use more than one configutil parameter to enable the message with additional features. For example, some messages can carry message headers in the notification text. For instructions on how to configure these messages, see Syntax for newflags and oldflags Properties.

   ---

   Note –

   You must configure parameters separately for each plug-in you configure.

   Thus, if you configure two plug-ins, named jmq1 and jmq2, and you want to enable new-message notifications for both plug-ins, you must run the local.store.notifyplugin command twice:

   configutil -o local.store.notifyplugin.jmq1.NewMsg.enable -v 1

   configutil -o local.store.notifyplugin.jmq2.NewMsg.enable -v 1

   ---

2. Specify the host where the Message Queue destination (broker) is running.

   For example, enter the following command:

   configutil -o local.store.notifyplugin.jmqnotify.jmqHost -v "127.0.0.1"

   where jmqnotify is the name of the plug-in

   and "127.0.0.1" is the IP address of the host machine for the Message Queue broker.

3. Specify the port for the Message Queue broker.

   For example, enter the following command:

   configutil -o local.store.notifyplugin.jmqnotify.jmqPort -v "7676"

   where jmqnotify is the name of the plug-in

   and "7676" is the port for the Message Queue broker.

4. Specify the user ID and password of the Message Queue user authorized to produce messages to the service.

   For example, enter the following commands:

   configutil -o local.store.notifyplugin.jmqnotify.jmqUser -v "guest"

   configutil -o local.store.notifyplugin.jmqnotify.jmqPwd -v "%$#a62t&"

   where jmqnotify is the name of the plug-in

   and "guest" and "%$#a62t&" are the user ID and password, respectively, for the Message Queue user.

5. Configure the type of destination (topic or queue) and the name of the destination to which messages will be sent.

   Follow these steps:

   1. Specify whether the destination is a topic or queue.

      For example, enter the following command:

      configutil -o local.store.notifyplugin.jmqnotify.DestinationType -v "queue"

      where jmqnotify is the name of the plug-in

      and "queue" specifies that the destination is a queue. The allowed values for this parameter are "queue" and "topic".

   2. Specify the destination name.

      For example, enter one of the following commands:

      configutil -o local.store.notifyplugin.jmqnotify.jmqQueue -v "JES-MS"

      or

      configutil -o local.store.notifyplugin.jmqnotify.jmqTopic -v "JES-MS"

      where jmqnotify is the name of the plug-in

      jmqQueue or jmqTopic identifies the destination type. The jmqQueue and jmqTopic parameters are synonymous and mutually exclusive; you can only use one of these parameters in one plug-in.

      "JES-MS" is an example name of the queue or topic to which messages will be sent.

6. Specify the message priority.

   For example, enter the following command:

   configutil -o local.store.notifyplugin.jmqnotify.Priority -v 3

   where jmqnotify is the name of the plug-in

   and -v 3 is the Message Queue priority assigned to messages produced by this plug-in.

   The default value of the Priority is 4.

7. Specify the length of time (in milliseconds) that messages are retained by the Message Queue broker.

   For example, enter the following command:

   configutil -o local.store.notifyplugin.jmqnotify.ttl -v 100

   where jmqnotify is the name of the plug-in

   and -v 100 specifies that a message is retained by the Message Queue service for 100 milliseconds before being either delivered or discarded. A value of 0 means that a message is retained permanently; it does not time out.

8. Specify the message persistence.

   For example, enter the following command:

   configutil -o local.store.notifyplugin.jmqnotify.Persistent -v 1

   where jmqnotify is the name of the plug-in

   and -v 1 specifies that persistent messages are used in the Message Queue service. Allowed values are 1 (persistent) and 0 (non-persistent).

9. Configure the plug-in name.

   To configure a single plug-in with the default name, you can enter either the fully qualified name of the plug-in library or the name of the library and its plug-in parameter:

   configutil -o local.store.notifyplugin -v /opt/SUNWmsgsr/lib/libjmqnotify

   or

   configutil -o local.store.notifyplugin -v '/opt/SUNWmsgsr/lib/libjmqnotify$jmqnotify'

   where libjmqnotify is the library name

   and jmqnotify is the default name of the plug-in parameter.

   Use the dollar sign ($) to separate the library name from the parameter.

   Enclose the entire value in single quotes ('value'); if you do not, the shell will interpret the dollar sign.

   The configutil parameters read by the default plug-in have the following names:

   local.store.notifyplugin.jmqnotify.*

   To configure a different plug-in name such as jmq42, you would enter the following command:

   configutil -o local.store.notifyplugin -v '/opt/SUNWmsgsr/lib/libjmqnotify$jmq42'

   The configutil parameters read by the jmq42 plug-in have the following names:

   local.store.notifyplugin.jmq42.*

To Configure Multiple Plug-ins

1. Configure a separate set of JMQ notification parameters for each plug-in you intend to create.

   For example, suppose you configure two plug-ins named jmq1 and jmq2. Assume you want to enable new-message notifications for both plug-ins and purged-message notifications for the jmq2 plug-in only. In this case, you would run the local.store.notifyplugin command three times, as follows:

   configutil -o local.store.notifyplugin.jmq1.NewMsg.enable -v 1

   configutil -o local.store.notifyplugin.jmq2.NewMsg.enable -v 1

   configutil -o local.store.notifyplugin.jmq2.PurgeMsg.enable -v 1

   You also must specify parameters that enable the plug-ins to communicate with the Message Queue service.

   For step-by-step instructions for configuring the all the notification parameters, see To Configure a JMQ Notification Plug-in.

2. Configure the plug-in names.

   To configure two plug-ins named jmq1 and jmq2, you would enter the following command:

   configutil -o local.store.notifyplugin -v '/opt/SUNWmsgsr/lib/libjmqnotify$jmq1$$/opt/SUNWmsgsr/ \ lib/libjmqnotify$jmq2'

   In this example, two instances of the plug-in library are run.

   Use a single dollar sign ($) to separate the library name from the parameter that specifies the plug-in name.

   Use two dollar signs ($$) to separate the first plug-in instance from the next one.

   Enclose the entire value in single quotes ('value'); if you do not, the shell will interpret the dollar signs.

   In this example, the first instance builds its configuration from parameters with the name jmq1:

   local.store.notify.jmq1.*

   The second instance builds its configuration from parameters with the name jmq2:

   local.store.notify.jmq2.*

22.2.2 Specifying Notification Messages that Use More Than One configutil Parameter

For most notification messages, you specify the message by running a single local.store.notifyplugin command.

However, the following notification messages are (or can be) configured with more than one local.store.notifyplugin command:

1. NewMsg

2. UpdateMsg

3. DeleteMsg

4. MsgFlags

The procedures that follow describe how to set up these notification messages.

To Configure New-Message and Updated-Message Notifications with Message Headers and Message Bodies

You can add the message headers and message bodies to the text of notification messages sent when there are new or updated email messages.

Including message headers and message bodies is optional; you can include both features, one feature only, or neither feature. The default is to send messages without message headers or message bodies.

1. Specify the new-message or updated-message notification:

   configutil -o local.store.notifyplugin.jmqnotify.NewMsg.enable -v 1

   configutil -o local.store.notifyplugin.jmqnotify.UpdateMsg.enable -v 1

   where jmqnotify is the name of the plug-in

   and -v 1 enables notifications for these messages. A value of 0 disables notifications.

2. Specify the maxHeaderSize parameter with a value greater than zero, as in the following example:

   configutil -o local.store.notifyplugin.jmqnotify.maxHeaderSize -v 1024

   where jmqnotify is the name of the plug-in

   and 1024 is the maximum size of the header to be sent. The default value of maxHeaderSize is 0, which sends no header information with the message.

3. Specify the maxBodySize parameter with a value greater than zero, as in the following example:

   configutil -o local.store.notifyplugin.jmqnotify.maxBodySize -v 1024

   where jmqnotify is the name of the plug-in

   and 5120 is the maximum size of the message body to be sent. The default value of maxBodySize is 0, which sends no body with the message.

To Configure Deleted-Message Notifications with Message Headers

You can add the message headers to the text of notification messages sent when email messages are deleted.

Including message headers is optional. The default is to send notifications without message headers.

1. Enable notifications to be sent when email messages are deleted:

   configutil -o local.store.notifyplugin.jmqnotify.DeleteMsg.enable -v 1

   where jmqnotify is the name of the plug-in

   and -v 1 enables notifications for this message. A value of 0 disables notifications.

2. Specify the ExpungeHeaders parameter:

   configutil -o local.store.notifyplugin.jmqnotify.ExpungeHeaders -v 1

   where jmqnotify is the name of the plug-in

   and -v 1 enables message headers to be carried with deleted-message notifications. The default value of ExpungeHeaders is 0, which prohibits deleted-message notifications from carrying header information.

   You must configure the ExpungeHeaders parameter to enable DeleteMsg messages to carry message headers.

3. Specify the maxHeaderSize parameter with a value greater than zero, as in the following example:

   configutil -o local.store.notifyplugin.jmqnotify.maxHeaderSize -v 1024

   where jmqnotify is the name of the plug-in

   and 1024 is the maximum size of the header to be sent. The default value of maxHeaderSize is 0, which sends no header information with the message.

22.2.2.1 Configuring Notifications for Changes in Message Status

You can configure a notification message to be sent when an email message has changed status.

Information Delivered in Message-Flag Notifications

A message-flags notification is produced whenever a status flag has changed because the email message was:

• Answered

• Flagged

• Deleted

• Seen (read)

• Draft

When a message-flags notification is sent, the notification carries the following properties:

• The flags set for the email message before its status changed

• The flags set for the email message after its status changed

This information is carried in two properties, oldflags and newflags, which are 5–character strings.

For a description of the values of these two properties, see Syntax for newflags and oldflags Properties.

Configutil Parameters Needed for Message-Flag Notifications

To enable message-flag notifications, you must configure the following configutil parameters:

• local.store.notifyplugin.MsgFlags

• local.store.notifyplugin.*.MsgFlags.enable

The first MsgFlags parameter enables the IMAP server and message store to identify and track the changing values of the status flags so that this information can be delivered in notification messages.

This parameter applies to all notification plug-ins. Therefore, you must enable the parameter if any notification plug-in uses message-flag notifications. If no plug-in uses message-flag notifications, be sure that this parameter is disabled (its default value).

The second parameter, *.MsgFlags.enable, allows message-flag notifications to be sent for a particular plug-in library.

You must configure both parameters to enable notifications for message flags.

To Enable Notifications When Message-Status Flags Have Changed

1. Enable status flags to be tracked and status information to be carried with message-flag notifications:

   configutil -o local.store.notifyplugin.MsgFlags -v 1

   where -v 1 enables message-flag information to be sent with message-flag notifications. A value of 0 disables this notification.

2. Enable message-flag notifications to be sent by a particular plug-in:

   configutil -o local.store.notifyplugin.jmqnotify.MsgFlags.enable -v 1

   where jmqnotify is the name of the plug-in

   and -v 1 enables message-flag notifications for this plug-in. A value of 0 disables notifications.

22.3 JMQ Notification Messages and Properties

This section describes the following topics:

• 22.3.1 Notification Messages

• 22.3.2 Rules and Guidelines for Notification Messages

• 22.3.3 Notifications for Particular Message Types

• 22.3.4 Default Values of the configutil Parameters

• 22.3.5 Notification Message Properties

22.3.1 Notification Messages

Notification messages can be generated for various kinds of events that occur in the message store. For example, when a user logs in, a Login message can be produced and delivered to the Message Queue broker.

A configutil parameter specifies each kind of message to be produced. You determine which events will generate messages by configuring various configutil parameters. The configutil parameters are referenced by one or more JMQ Notification plug-in libraries.

All messages are delivered to a topic or a queue, depending on whether the destination type is set to "topic" or "queue". For information on how to configure the Message Queue destination, see To Configure a JMQ Notification Plug-in.

Each message is identified by the following message header:

MQ_MESSAGE_TYPE_HEADER_PROPERTY

The JMQ Notification plug-in supports the messages shown in the following table.

For a list of the configutil parameters that enable these messages, see 22.3.4 Default Values of the configutil Parameters.

22.3.2 Rules and Guidelines for Notification Messages

The following rules and guidelines apply to the supported notification messages:

• The text of most notification messages is a single blank space. (The blank space is used because Message Queue does not permit an empty message body.) The exceptions are as follows:

  • The NewMsg, UpdateMsg, and DeleteMsg messages can include a message header when configured with the maxHeaderSize parameter. You must set maxHeaderSize to a value greater than zero.

    To include a message header with a DeleteMsg message, you also must set the ExpungeHeaders parameter to a value of 1.

  • NewMsg and UpdateMsg message can include a message body when configured with the maxBodySize parameter. You must set maxBodySize to a value greater than zero.

    For NewMsg and UpdateMsg, by default the message body is not delivered (is turned off). This prevents overloading Message Queue. No other messages include a message body.

• Notification messages can be generated for changes to the INBOX alone, or to the INBOX and all other folders. The following configuration parameter allows for INBOX only (value = 0), or for both the INBOX and all other folders (value = 1):

  local.store.notifyplugin.jmqnotify.noneInbox.enable

  The default setting is to generate messages from the INBOX only (value = 0).

  There is no mechanism to select folders; all folders are included when the variable is enabled (value = 1).

• The NewMsg notification is issued only after the message is deposited in the user mailbox (as opposed to “after it was accepted by the server and queued in the message queue”).

• Messages are not generated for POP3 client access.

• All messages can be suppressed by issuing XNOTNOTIFY. For example, an IMAP script used for housekeeping only (the users are not meant to be notified) might issue it to suppress all messages.

22.3.3 Notifications for Particular Message Types

Notifications can deliver status information about messages of different types, such as text messages, voice mail, and image data. Users often expect these heterogeneous message types to be stored in the same mail folder. For example, a user may want new text messages and voice mail to arrive in the user's cell phone inbox.

To configure these message types, you use configutil commands such as store.messagetype.enable. For information about configuring and managing message types, see “Managing Message Types” in “Chapter 18: Managing the Message Store.”

Once the message types have been configured, JMQ notification messages can identify the particular message types. You can write your Message Queue client to interpret notification messages by message type and deliver status information about each type to the mail client.

For example, suppose new messages of different types arrive in a user's mailbox. 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.

The following notification messages can carry information that tracks particular message types:

NewMsg
UpdateMsg
ReadMsg
TrashMsg
DeleteMsg
PurgeMsg
OverQuota
UnderQuota

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.

The message-specific count is carried in the numMsgs property and delivered with the notification message. For ReadMsg and TrashMsg notification messages, the number of messages seen (numSeen) and the number marked as deleted (numDeleted) are also counted by message type.

The Event Notification Service does not support message types. Use a JMQ notification plug-in to deliver information about message types.

22.3.4 Default Values of the configutil Parameters

The notification messages and the configuration information needed by Message Queue are configured with configutil parameters.

Table 22–2 shows these parameters and their default values.

For complete definitions of the configutil parameters, see “Chapter 3: Messaging Server Configuration,” in the Sun Java System Messaging Server Administration Reference.

22.3.5 Notification Message Properties

Every message carries additional information defined in properties. Different properties are present for different messages. For example, NewMsg indicates the IMAP uid of the new message.

22.3.5.1 Standard Notification Message Properties

Table 22–3 describes the standard notification message properties. These properties are present in all JMS messages.

22.3.5.2 Properties Specific to Particular Notification Messages

Table 22–4 describes the properties carried with particular notification messages.

Each message includes a subset of the properties shown in the table below. For a list of the properties associated with each message, see Table 22–5.

Subscribers should allow for undocumented properties when parsing the message reference. This allows for future compatibility when new properties are added.

Syntax for newflags and oldflags Properties

The newflags and oldflags properties are 5–character strings. The string must have the following values:

• If the /answered flag is set, the first character is "A". If not, it is blank (“ “).

• If the /flagged flag is set, the second character is "F". If not, it is blank (“ “).

• If the /deleted flag is set, the third character is "D". If not, it is blank (“ “).

• If the /seen flag is set, the fourth character is "S". If not, it is blank (“ “).

• If the /draft flag is set, the fifth character is "R". If not, it is blank (“ “).

22.3.5.3 Properties Carried with Each Notification Message

Table 22–5 shows the properties associated with each notification message.

For example, to see which properties apply to a TrashMsg message, look in the column header for “ReadMsg, TrashMsg.” A TrashMsg message can use mailboxName, numMsgs, uidValidity, numSeen, and numDeleted (in addition to the standard properties).

* The numDeletedn, numMsgsn, numSeenn, and numSeenDeletedn properties are carried with notifications only if message types are defined in the message store.