Cause

Lotus Domino journal handling

Any incoming and outgoing mail document is (if configured) stored by the mail server in a so-called “journal” , a container for collecting exact copies of incoming and outgoing mail documents.

You are viewing: What Is Single Instance Storage

This means that the documents in the journal are exact copies of the mails that were composed by the sending mail server.

On a Lotus® Domino® mail server, two different types of journals are available, the “copy-to journal” and the “mail-in” journal.

For the “copy-to journal“, before a copy of an incoming mail document is transferred to the user’s mail box (inbox), various properties are added to the document or modified for the document by the mail server.

• Router information is added. This includes information about how the document is passed within the mail server infrastructure to the user’s mailbox.
• Group/alias expansion is performed. This is done if an alias or group is defined that forces the mail to be delivered to another user or a set of users. For example, “[email protected]” could be an account that is an alias for one or more users who must be informed about administrative issues.
• Delivered date is added. This property informs a user (and probably confirms the sender) about when the mail was finally placed into a user’s mailbox.
• Other properties: Depending on the mail server system and configuration, there may be other properties that are also modified for mail documents transferred to the user’s mailbox.

As can be seen from this list of properties, a mail document that is transferred by the mail server to the user’s mailbox and the mail document that is copied to the journal are not identical copies. They differ significantly with regard to several different properties.

As a consequence, the single instance store feature that is provided by IBM CommonStore cannot treat copies of mail documents in the journal and in the user’s mailbox as being identical and subsequently cannot store them as one copy in the archive.

The “mail-in journal” works a bit differently. The mail-in journal does not include the set of BCC recipients whereas the copy-to journal includes this mail property.

Subsequently, as the mail-in journal is not complete because BCC recipients are not included, the single instance store feature cannot consider mail documents with BCC data in the mail-in journal and mail documents in the user’s mailbox as being identical, and subsequently cannot store them as one copy in the archive.

The complete set of properties that is used by the single instance store feature to distinguish mails from one another and identify identical ones is documented in the CommonStore for Lotus Domino: Administrator’s and Programmer’s Guide under the section “Calculation of the hash key for mail documents”

Lotus Domino BCC field handling

Under Lotus Domino, if a mail document is sent to a list of BCC recipients, each recipient will receive a unique copy of the original mail that was sent with only the recipient’s name listed in the BCC field.

The sender of the mail will receive a document with the complete BCC list. Recipients who are not on the BCC list but on the TO or CC list will receive a mail document with an empty BCC list. This leads to a whole set of different mail documents that must be stored individually and cannot be stored as one instance because, if only one instance were stored, which should it be. The sender’s copy with the complete BCC list, or one of the BCC recipients with only their name on the list, or what. The idea of the BCC concept is NOT to reveal who else is on the BCC list. So in order to keep this information private for each user an individual mail document must be stored.

Read more : What Is A Good Chaser For Tequila

As a consequence, the single instance store feature in IBM CommonStore cannot treat copies with BCC recipients as identical and subsequently cannot store them as one copy in the archive.

Microsoft Exchange journal handling

Any incoming and outgoing mail document is (if configured) stored by the mail server in the so-called “journal recipient mailbox“, a special mailbox for collecting incoming and outgoing mail documents.

This means that the documents in the journal are copies of the mails from the sending mail server.

On a Microsoft® Exchange mail server, three kinds of journaling are available: “message-only journaling”, “BCC journaling”, and “envelope journaling”.

For “message-only journaling” the copy sent to the recipients and the copy in the journal recipient mailbox are identical.

For “BCC journaling” the copy in the journal recipient mailbox is different from the one sent to the recipients. It contains a list of all recipients in the BCC field.

For “envelope journaling” the copy in the journal recipient mailbox is also different from the one sent to the recipients. For each message a so-called envelope object is created in the journal recipient mailbox. This envelope object contains the original mail as an attachment and other properties (such as distribution lists that may be expanded by the system through dictionary lookup) as plain text in the message body. The original mail isl not modified by the journal and the attached message is identical to the one sent to the recipients. As a consequence, the single instance store feature in IBM CommonStore will treat copies of mail documents in the journal and in the user’s mailbox as identical and subsequently will store them as one copy in the archive.

The set of properties that is used by the single instance store feature to distinguish mails from one another and identify identical ones contains the mail properties PR_INTERNET_MESSAGE_ID and PR_ENTRY_ID, and the IBM CommonStore archiving type.

Microsoft Exchange BCC field handling

Under MS Exchange, if a mail document is sent to a list of BCC recipients, each of the recipients will receive a copy of the original mail that was sent with the BCC field empty. (The user can however deduce that he or she is on the sender’s BCC list if his or her ID does not appear in the TO or CC field.)

The “Sent Items” folder in the sender’s mailbox will contain a message with the complete BCC list. Recipients who are not on the BCC list but on the TO or CC list will also receive a mail document with an empty BCC list.

This means that there are up to three different types of mail documents, one that contains the empty BCC list, one that does not contain BCC information at all, and (if BCC journaling is enabled) one that contains the entire recipient list in the BCC field. Only in the case of mail documents with a BCC recipient list will more than one instance be generated on the mail server.

As a consequence, the single instance store feature in CommonStore can treat copies with empty BCC recipients fields as identical and subsequently will store them as one copy in the archive. The sender’s mail with the complete BCC recipient list and the mail document in the journal recipient’s mailbox (if BCC journaling is used) are stored as a separate copy in the archive.

Read more : What Is Bobby Brantley Doing Now

In order to search for recipients in the BCC list, CommonStore for Exchange stores the BCC recipients as attributes in the underlying Content Manager 8 item type. This way users can search for their mails and the BCC list information will not be revealed.

Modified Microsoft Exchange messages

There is a further limitation for the single instance store feature: Only unmodified messages qualify for the single instance store. Unfortunately, certain Outlook actions will result in mail document modifications that no longer allow the system to consider mail documents as being identical.

If any of the following actions are applied, the corresponding mail documents no longer qualify for the single instance store:

– Reply – Reply to all – Forward – Follow Up – Changing a category (using the “Categories” menu item) – Moving to PST file

Moving, for example by dragging and dropping a mail to an Outlook folder, does not modify a mail document.

Microsoft Outlook PST files

Messages in PST files may or may not be considered modified based on the process that added the message to the PST file.

• If a mail is moved to a PST archive using the genuine Outlook function, the mail is considered modified and no longer qualifies for the single instance store.
• If a mail is delivered to a PST file because you specified this PST file as the place where you want the new e-mail to be delivered to, the mail is not considered modified and still qualifies for the single instance store.

Microsoft Outlook 2003 and cached mode

If the sender of a message uses Outlook 2003 in cached Exchange mode (offline), two copies of the same message end up in the archive even if the CommonStore single instance store feature is enabled. One copy is a copy from the inbox folder of a recipient, the other is a copy from the sent items folder of the sender.

This is caused by the fact that the CommonStore for Exchange single instance store algorithm relies on a message flag indicating that a message has not been modified. Checking this flag ensures that modications to individual message copies do not get lost during single instance storing. Without this flag, messages would be considered to be identical although they are not. Only the one copy would be archived and any changes to the other copy would get lost during subsequent stubbing of the archived messages.

If Outlook 2003 is used in cached Exchange mode, sent messages do not contain this modification flag, which is why an additional copy of each mail document is archived.

Encrypted mail documents

Encrypted mail documents are processed the same way as all other mails are so there is no fundamental problem for the single instance store feature here.

Source: https://t-tees.com
Category: WHAT