33.1 How Message Retention Works
To understand how message retention works, you need to understand what GroupWise does and what the message retention application does, as explained in the following sections:
33.1.1 What GroupWise Does
During installation of the message retention application, the application uses the GroupWise Trusted Application API to create a trusted application record in the GroupWise system. The trusted application record includes a flag that designates it as a message retention application. This flag is surfaced through the trusted application’s Provides Message Retention Service setting in ConsoleOne ().
Figure 33-1 Edit Trusted Application Dialog Box with the Provides Message Retention Service Setting Turned On
When ConsoleOne reads a trusted application record that has the Provides Message Retention Service setting turned on, it adds a tab to the GroupWise Client Environment Options ().
Figure 33-2 Environment Options Dialog Box with the Retention Tab Open
You use this tab to enable message retention at the domain, post office, or user level, meaning that you can enable it for all users in a domain, all users in a post office, or individual users.
Turning on message retention alters the GroupWise client purge behavior by preventing a user from purging any messages from his or her mailbox that have not yet been retained.
33.1.2 What the Message Retention Application Does
Different message retention applications might vary slightly in their approach to retaining messages. This section provides a general approach to message retention.
To determine whether or not mailbox messages have been retained, the message retention application adds a time stamp to the mailbox. The message retention application can use the GroupWise Object API or GroupWise IMAP support to write (and read) the time stamp. In addition, you can use the GroupWise Time Stamp Utility to manually set the time stamp.
The time stamp represents the most recent date and time that message retention was completed for the mailbox. Messages delivered after the time stamp cannot be purged until they have been retained. This requires that the message retention application retain items chronologically, oldest to newest. For example, assume a mailbox has a message retention time stamp of May 7, 2010 12:00:00. The mailbox has three folders with a total of seven messages:
Figure 33-3 Three Folders with Seven Messages
The message retention application reads the existing time stamp (May 7, 2010 12:00:00) and selects a time between that time and the current time. For example, suppose the current time is May 9, 2010 14:00:00. The message retention application could choose May 8, 2010 12:00:00 as the new time stamp. It would then retain any messages delivered between the existing time stamp (May 7, 2010 12:00:00) and the new time stamp (May 8, 2010, 12:00:00).
In the above example, messages 1, 4, and 6 are older than the existing time stamp (May 7, 2010 12:00:00). The message retention application would not retain these messages again, assuming that they had already been safely retained. Messages 2 and 5 have dates that fall between the existing time stamp (May 7, 2010 12:00:00) and the new time stamp (May 8, 2010, 12:00:00) so they would be retained. Messages 3 and 7 have dates that fall after the new time stamp (May 8, 2010, 12:00:00) so they would not be retained until the next time the message retention application ran against the mailbox.
Optionally, the message retention service can be associated with an archive service. For more information, see Section 4.2.7, Archive Service Settings.