Introduction
In today's workplace, we're used to sharing things -- printers, copiers, offices, computers... But, mail? Mail is an area where we still like to think that what's yours is yours, and what's mine is mine. Never mind that when we receive the same message, what's "yours" is exactly the same as what's "mine"!
With Domino shared mail, also known as "single copy object store," administrators can set up message sharing without ever affecting the user's mail experience. The reason is that the sharing occurs at the server level. Instead of delivering separate copies of a message to each recipient's mail file, shared mail allows a server to maintain only one copy of the mail message in a central, shared mail database. Users can then access and work with the message -- delete, reply, edit, save, or resend it -- just as they would if the message were stored in their own mail files. This message sharing can result in a significant saving of server disk space. For example, when we've enabled shared mail on servers here at Iris, we've had disk space savings of up to 35 percent.
This article introduces you to shared mail, with a look at the security features and basics of enabling shared mail. Then, we'll turn to some specific tips for how to manage the size of the shared mail database, move users between servers that use shared mail, use shared mail with Domino clusters, and how to disable shared mail. Finally, we'll look at the exciting new shared mail features available now in Domino R5.
An introduction to shared mail
Shared mail was first introduced in R4 as a way for administrators to save server disk space, and the feature continues to be relevant today. For those administrators migrating to Domino mail from other mail packages, shared mail may seem very familiar (for example, shared mail is similar to the cc:Mail Post Office storage model). And for other administrators looking for a way to get a handle on the growing mountain of messages exchanged within their organization -- a way to reduce message traffic and make the messaging infrastructure more scaleable, efficient, and economical -- shared mail is the natural, built-in solution.
So, what is shared mail? When we use the term "single copy object store" to refer to shared mail, the feature seems almost self-explanatory. Whether a message is addressed to one person or several hundred, shared mail enables the server to store a single copy of the message in its object store. In this case, the object store is a shared mail database. "Pointers" to the object store documents give users the experience that they each have a single copy of the document, which is actually being shared among them. The disk space savings can be significant, and the reduced data copying can produce performance benefits. For example, when you send a departmental message to 100 users, instead of the server saving 100 copies of the message in the individual mail files, the server saves a single copy in its shared mail database.
After you enable shared mail on your server, the Mail Router splits incoming messages into two parts: header and content. The header includes the message's To, cc, bcc, Subject, and From fields. The content includes the body text of the message and any file attachments. The following diagram shows the parts of a mail message:
During delivery, the Mail Router stores the message content in the shared mail database, and stores a copy of the header in each user's mail file with a pointer back to the content in the shared mail database. For example, for a message with three recipients (user1, user2, and user3), the Router delivers three separate headers (one to each recipient) and sends a single copy of the message content to the shared mail database:
When the user opens the message, the header activates a link to the corresponding message content in the shared mail database. The message appears as though it is entirely stored in the user's mail file. Users can delete, reply, change the view or folder, edit, save, resend, and perform all the same tasks with the mail message as they would with the same message stored in their own mail files.
Each user can edit, save, and resend the original message, without affecting how the message appears to the other users. If one user edits the message, Domino places a copy of the complete edited note into the user's mail file, and removes its pointer to the shared mail database. No edits are made to the original message content, so the other recipients can still access the original message.
Likewise, when one user deletes a shared message, Domino deletes only the header in the user's mail file; the content remains in the shared mail database. After all users delete the messages from their mail files, the Object Collect task (which runs daily at 2 AM by default) purges the obsolete message from the shared mail database.
Security features of the shared mail database
When users view the message content in the shared mail database, they actually request that the server retrieve this information and make it available to them in their own mail databases. Users, therefore, never directly access the shared mail database. But since the shared mail database contains "the meat" of so many users' messages, the database also includes the following security features:
- The database ACL specifies Server access only. The server ID that created the database is listed as Manager, with the user type "Server." This means that a user cannot use the server ID to access the database from a Notes workstation. The setting also prevents replication of the database to another server.
- The database is encrypted with the server's ID. Again, only the server ID that created the database can access it.
- The database does not appear in the Open Database dialog box, and users cannot add an icon for the database to their desktop.
- The database contains no views, and none can be added to it.
- The database includes backlinks to message headers, so that when a user reads a message, Domino can verify that the headers really match the content. This is a precaution against an administrator attempting to spoof message headers.
If a user chooses to encrypt incoming mail, that user's mail will not be stored in the shared mail database. The reason for this is that an incoming message would be encrypted so that only this user (the recipient) could decrypt it, and any other recipients of the same message would not be able to decrypt the encrypted copy of it. If, on the other hand, the sender of a message selects the option to encrypt an outgoing message, the message is encrypted so that all recipients of the message can decrypt it. So, a sender-encrypted message can be stored in the shared mail database, because each recipient can decrypt the message.
Some basics about enabling shared mail
To create the shared mail database and enable it on your server, you should make sure that the Mail Router is running and then enter the following command at the server console:
Tell Router Use Shared.nsf
where Shared.nsf is the full name of the shared mail database that you want to use on this server, including the directory. (The shared mail database must reside within the logical directory structure that is controlled by the server.)
The Mail Router then creates the specified shared mail database and sets the NOTES.INI Shared_Mail setting to 2, which enables shared mail for the transfer and delivery of mail to this server. In addition, Domino automatically creates a file called mailobj.nsf, which is a database link file that always points to the actual shared mail database. (Entering the Show Server command at the server console displays the enabled status for shared mail, the name of the shared mail database, and the size of the shared mail database.)
Once enabled, you can use shared mail for both transfer and delivery (Shared_Mail=2, the default), or you can use it for delivery only (Shared_Mail=1). When shared mail is enabled for delivery only, the Router stores only those messages addressed to two or more local recipients in the shared mail database. The message is split only once during delivery. Messages being transferred through the server are kept intact in MAIL.BOX, and those messages being delivered to a single local recipient are delivered intact to the recipient's mail file. (Every Domino server has a mailbox database (MAIL.BOX), located in the Domino data directory, that holds pending mail -- that is, mail awaiting delivery to other users or servers.)
In contrast, when shared mail is enabled for both transfer and delivery, the server splits every message it receives regardless of the number of recipients (that is, the content goes to the shared mail database and the header goes to MAIL.BOX). Then, during delivery, the Router merges the header and content together, examines the recipient list, and either transfers the message on to the next server, or delivers it to the local recipients (with the content staying in the shared mail database and the header going to the users' mail files).
The shared mail setting that you decide to use depends on your situation. In general, use setting 1 (enabled for delivery) when your server has mostly transfers and some deliveries. Use setting 2 (enabled for transfer and delivery) when your server has mostly deliveries and some transfers. Both settings provide similar disk space savings, but using the "transfer and delivery" setting minimizes the size of user mail files by concentrating all mail in the central database.
Here are some interesting tidbits on how different features behave when you enable shared mail:
- For Calendar and Scheduling features, Domino stores invitations and scheduling information in the same way that it stores shared mail messages. This is true for anything that is handled by the Router.
- Users that access mail via POP3 or IMAP see no change with shared mail. The reason is that these protocols are just for the retrieval of mail. The Router delivers mail in the same way, no matter what protocol users use to access the mail.
- If users create a local replica of their mail file, the full copies of any shared messages appear in their replica. (This is usually necessary because remote clients cannot open the shared mail database on the user's home server.)
- These are just some of the basics about enabling shared mail. For more in-depth information on shared mail, see the Administration Help. Next, we'll look at some tips for administering your shared mail.
Tips for administering shared mail
Once you have shared mail enabled on your server, you're ready to start managing it! In this section, you'll first learn about the Object Store Manager. Then, we'll look at some specific tips for how to manage the size of the shared mail database, move users between servers that use shared mail, use shared mail with Domino clusters, and how to disable shared mail.
An introduction to the Object Store Manager
For most administration tasks, you access the Object Store Manager by entering the Object Link or Object Collect commands at the server console. The Object Link task helps you set up sharing of existing mail messages -- that is, mail messages that were delivered prior to the enabling of shared mail. To run the Link task, enter the following command:
Load Object Link user.nsf shared.nsf
where user.nsf is the name of a user mail file or an entire directory containing mail files, and shared.nsf is the name of the shared mail database.
During the "link" operation, the Object Store Manager opens each message in the mail file, splits the message into its header and content portions, stores the content in the shared mail database, and stores the header in the mail file with a link back to the content. You can also use the Link command to force mail file replicas on other servers to use the shared mail database. We'll look at the "unlink" and "relink" options in the following tips.
The Object Collect task helps you to purge obsolete messages in the shared mail database. The task runs by default at 2 AM, but you can also run it manually. To run the Collect task, enter the following command:
Load Object Collect shared.nsf
where shared.nsf is the name of the shared mail database.
During the "purge" operation, the Object Store Manager opens the content part of messages in the shared mail database, checks whether any headers still refer to the message, and if there are none, it purges the content (that is, it removes the content without leaving a deletion stub). This purge increases empty space in the database, which Notes then reuses before allocating additional storage space. (With R4.62 or later, you can also run the Object Collect task without actually deleting documents from the shared mail database by using the -Nodelete option. This way, you can have a "test" run of the task to see exactly which documents it would delete, and how much space it would free up.)
In addition, the Object Collect task automatically generates shared mail statistics, such as how many messages are shared by a certain number of users. You can view these statistics in the Statistics database or at the server console by using the Show Stat Object command. Later in this article, you'll see how these statistics are available through the new R5 Domino Administrator.
For more information on using the Object Link and Object Collect tasks, see the Administration Help.
Managing the size of the shared mail database
At any given time, there can be only one shared mail database to which the Router is actively writing. Of course, this active shared mail database may become quite large, even though the Object Collect task runs by default daily to purge obsolete messages. In R4.x, the shared mail database is limited to 4GB. However, you can enable an unlimited number of additional shared mail databases to have unlimited mail storage space on a Domino server. For example, you may want to create a new shared mail database on the server every week, and make it be the shared mail database that the Router uses for new mail deliveries.
To determine the active shared mail database, the Router actually looks first to mailobj.nsf, which is the database link file that always points to the active shared mail database. Domino automatically creates mailobj.nsf when you enable shared mail. It also automatically updates the file when you create a new shared mail database to use for new mail deliveries.
To create a new shared mail database for new mail deliveries, enter the following command:
Tell Router Use Shared2.nsf
where Shared2.nsf is the full name of the new shared mail database that you want to use on this server, including the directory. This automatically stores the content part of new messages in the new shared mail database. Existing shared mail databases must remain online so that users can still read their existing messages.
As a side note, you should back up all shared mail databases frequently, at least as often as you would back up regular mail files. At a minimum, back up shared mail databases at least once a day. Remember that you cannot use replication of the shared mail databases as a backup method, because the security settings prevent replication.
Moving users between servers that use shared mail
If you want to move users to a new server and still have them use shared mail, do the following:
- Choose File - Replicate - New Replica to make a replica of the mail file on the new server. The replication process creates an unlinked copy of the user's mail file on the server. Make sure to populate the new replica.
- Relink the user's mail file to a shared mail database on the new server by entering the following command:
Load Object Link -Relink user.nsf shared.nsf
where user.nsf is the name of the user's mail file, and shared.nsf is the name of the shared mail database. Domino then relinks all messages in the mail file to point to the new shared mail database.
- On the first server, create a new, empty replica of the user's mail file. This way, the next time the Object Collect task runs, it will see that all headers in the user's mail file have been deleted. It can then purge any obsolete messages.
- Delete the user's original mail file from the first server.
Note: If you delete the user's mail file without creating an empty replica (like we did in Step 3), the Object Collect task assumes that the file is only temporarily unavailable, and continues to maintain all linked messages in the shared mail database.
Using shared mail with Domino clusters
For a Domino cluster in which some servers have shared mail enabled, you can create replicas of user mail files, and use cluster replication to increase mail reliability. Although you cannot use cluster replication to keep shared mail databases synchronized, you can use cluster replication to replicate information across to another mail file replica. The clustered servers do not need to have shared mail enabled, but they do need to have a shared mail database. To create a replica on a clustered server and have the replica still use shared mail, do the following:
- If shared mail is not enabled on the clustered server, create a shared mail database by entering the following command:
Load Object Create shared.nsf
where shared.nsf is the name of the shared mail database. This creates a shared mail database without enabling shared mail on the server.
- Choose File - Replicate - New Replica to make a replica of the mail file on the clustered server. The replication process creates an unlinked copy of the user's mail file on the server. Make sure to populate the new replica.
- Link the new replica to the shared mail database on the clustered server by entering the following command:
Load Object Set -Always user.nsf shared.nsf
where user.nsf is the name of a replica mail file or a directory of replica mail and shared.nsf is the name of the shared mail file storing mail replicas. After each replication, the messages will be linked to shared.nsf.
You should use these steps on each cluster member server that is hosting replica mail files. Once activated, Domino clustering (not the Domino Router task) automatically splits any replicated messages into their header and content portions, saving the headers in the individual mail databases and the content portions in the shared mail database on the target server.
Note: You can also use this same procedure for mail file replicas located on servers not in a cluster -- that is, servers kept synchronized by standard Domino replication.
Disabling shared mail
Let's say that you've decided that you no longer want to use shared mail in your organization. You can disable shared mail by simply changing the NOTES.INI Shared_Mail setting to 0. Then, the Router stops adding new messages to the active shared mail database. Users continue to have access to existing messages in the shared mail database; therefore, it is important that you do not move or remove the shared mail database, as this would result in the loss of e-mail messages.
If you want to move completely away from using shared mail, you can unlink your users' existing messages from the shared mail database, and then delete the shared mail database altogether. To do this:
- If you're using R4.62 or later, verify the total number and size of messages shared in the shared mail database by entering the following command:
Load Object Info -Full
The shared mail information then displays on the server console, and in the Misc. Events view in the server's Log file. Use this information to determine if you have enough disk space available for storing complete copies of the shared messages in the recipients' mail files. (You can also run this command on a specific shared mail database or individual mail file.)
- Unlink the messages in the shared mail database by entering the following command:
Load Object Unlink shared.nsf
where shared.nsf is the name of the shared mail database. Domino then unlinks each document in the shared mail database and stores the full copies in the recipients' mail files.
- Delete the original shared mail database.
Shared mail improvements in R5
As you may have noticed, most administration of shared mail in R4.x occurs at the server console. Now in R5, you can keep an eye on shared mail in the new Domino Administrator. For example, you can use the Messaging/Mail tab to see exactly how shared mail is being used on a server. As shown in the following screen, you can see the object store filename, the mail databases using that object store, the number of documents referenced in the object store for each mail database, and the total size of documents in the object store for each mail database. Notice that you can click on the column titles to sort the data in different ways:
You can use this shared mail information on the Mail tab in a number of ways. Basically, this panel gives you all the background information you need to know before you use the procedures we covered in the previous section. For example, you can see how one particular user's mail file uses shared mail, including how many documents it points to in the object store and the total size of those documents. This can help you determine how much disk space you would need if you were to unlink the user's mail file from the shared mail database. Likewise, you can see the total size of all documents in the shared mail database, so you'd know how much space you would need if you unlinked the entire shared mail database.
The shared mail information on the Mail tab actually displays from a new Object Store Usage view in the server's Log file. The view is populated when the Object Info -Full command runs by default at 3 AM. Using R4.62, you would need to manually run the Object Info -Full command at the server console to see this same information.
In addition, you can now more easily view shared mail statistics in the Domino Administrator by using the Server/Statistics tab. As shown in the following screen, you can see a graphical display of the statistic Object.mailobj.nsf.SharedBy.x -- that is, you can see the number of objects in the shared mail database that are shared by a certain number of users. For example, this server's shared mail database has 115 objects that are shared by three users:
The Statistics panel also displays the statistic Object.mailobj.nsf.SharedBy.Greater, so you can see the number of messages in the shared mail database that are shared by more than 20 users. To see these same statistics in previous releases, you would need to enter the Show Stat Object command, or use the Reporter task to report the statistics to the Statistics database (statrep.nsf).
Conclusion
Shared mail can help you to conserve server disk space, while still allowing users to work with their mail as if it were just "theirs." We hope that these tips will help you to better manage shared mail today, and get you ready for the new ways you can work with shared mail for tomorrow.
ABOUT MARC
Marc Zehngut has been at Iris for 5 years. Currently, he works in the R5 Administration Client development group. Before that, he was in the server development group, and worked on shared mail, the IMAP server, and Profile documents, among other things. Marc has BS and MS degress in computer science from Union College. Prior to Iris, he worked at Digital Equipment Corporation for over 10 years. His hobbies include photography, woodworking, and spending time with his family.