Skip to end of metadata
Go to start of metadata
Starting with Oracle Communications Unified Communications Suite 7.0.6, and Delegated Administrator and Calendar Server 7.0.5, the documentation for Connector for Microsoft Outlook 8.0.2, Contacts Server 8.0, Instant Messaging Server 9.0.2, Delegated Administrator, and Calendar Server 7.0.5 is available on the Oracle Documentation site at


imexpire automatically expires messages in the message store based on administrator-specified criteria. With Messaging Server 5.x and 6.x, imexpire was executed in two phases. The first phase expires messages that meet the expire criteria; the second phase purges (removes) from the message store all messages that have been discarded by imexpire or expunged by users. With Messaging Server 7, the second phase is performed by the impurge daemon process.


Expire Actions

The expire phase can perform one of these actions:

  • Discard – removes messages from the mailbox immediately.
  • Archive – archives messages by using the AxsOne archive store.
  • Fileinto – moves messages to a specified mailbox folder.
  • Report – prints the specified mailbox name, uid, and uid validity to stdout.

By default, imexpire discards messages.

For details about how the imexpire actions can be performed, see Message Store Maintenance Queue, Configuring Message Expiration, and Message Store Message Expiration.

Expire Criteria

The expire criteria can be set with configutil parameters or in a file called store.expirerule. Here are some of the criteria that can be specified:

  • Folder pattern
  • Number of messages in the mailbox
  • Total size of the mailbox
  • Age, in days, that messages have been in the mailbox. This criterion dates the age of a message from the time it first arrives in the message store (is first received by the user).
  • Age, in days, that messages have been saved in a particular mailbox folder. This criterion dates the age of a message from the time it is moved to a particular folder or re-saved in a folder.
  • Size of message and grace period (days that a message exceeding the size limit will remain in the message store before removal)
  • Whether a message has been flagged as seen or deleted
  • By message header field such as subject or message ID
  • According to a sieve script, as defined in RFC 3028

You can use imexpire to install a local expire rule file (store.expirerule) without conflicting with existing expire rules. If an expire rule file configured for the same partition or mailbox is executing while you try to install a new expire rule file, a warning message appears and the new expire rule file is not installed. Use the imexpire -i option to install a local expire rule file.

You can exclude a particular user or mailbox folder from all expire criteria by setting the exclusive expire rule for that user or mailbox without specifying any other rules in the expire rule file.

The functionality of imexpire has been expanded and the interface has changed since earlier versions of Messaging Server. However, this version continues to support older imexpire configurations.


imexpire must run locally on the Messaging Server; the stored utility must also be running.


The location of imexpire is msg-svr-base/sbin.



The options for this command are:

Option Description
-f file Use the expire rules specified in file. All other expire rules are ignored.

When used with the -i option, -f file refers to the expire-rule file to be installed.

Use a full path name to specify file. The expire rules in file must use the same format as the rules in the global expire configuration file.
-i Install a local expire-rule configuration file. This option must be used with either the -p partition option to specify a message store partition or the -x mailbox option to specify a mailbox. In addition, it must be used with the -f file option to specify the expire rule file to install.
-n Trial run only – do not perform expire. A description of what would happen without this flag is output.
-v 0|1|2 Log expire statistics. The number specifies the log level, where
0 = store level statistics (default setting)
2 = mailbox level statistics
3 = message level statistics
Messages are logged to the log file by default. When the -d option is used, messages go to stdout.
-d Display debug output to stdout/stderr.
-p message_store_partition Expire the specified message store partition.
-u user Expire the specified user.
-t num Maximum number of threads per process. Default is 50.
-r num Maximum number of threads per partition. Default is 1.
-m num Maximum number of rules in a policy. Default is 128.
-x mailbox Name of the mailbox to which the local expire rules apply. For example: user/joe/INBOX. This option is used with the -i option to install a local configuration file that will expire messages in the specified mailbox and its sub-folders.


Install a local expire rule configuration file for the user jdoe. These expire rules will apply to jdoe's memos folder.

Enhancements Introduced in Messaging Server 7 Update 5

Messaging Server 7 update 5 provides the following enhancements to imexpire:

New Attributes for Spam and Virus Scanning Through an MTA Channel

To facilitate spam and virus scanning through an MTA channel, the following attributes have been added to imexpire:

Attribute Description
channel An MTA channel.
rescanhours Rescan messages that have not been scanned for the specified number of hours.

New Sieve Body-Test Functionality

Sieve body-test functionality has been added to the imexpire utility. The test can find and perform actions on existing email messages in the Message Store on keywords in the body part.

To enable a Sieve body-test, set ENABLE_SIEVE_BODY=1 in option.dat.

Example usage in store.expirerule:

folderpattern: *
sieve: require "body"; body :contains "bug";
action: discard

messagestore messagestore Delete
messagingserver messagingserver Delete
reference reference Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.

The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.