Chapter 3: Mail
Terms you'll need to understand:
Domino Named Network (DNN)
Notes Remote Procedure Call (NRPC)
Mail usage reports
Techniques you'll need to master:
Defining the role of the DNN in message transfer
Scheduling mail routing between servers using Connection documents
Monitoring and maintaining mail routing
Troubleshooting mail-routing problems using administrative tools
Controlling mail archiving through policies and settings
Controlling mail file size by implementing mail quotas and warning thresholds
Understanding the role of the public and private keys in encryption
Setting workstation preferences and locations to use mail
This chapter outlines the basic messaging-configuration options that enable the Domino administrator to set up servers for mail routing and to monitor and troubleshoot mail routing within the Domino network. The chapter also covers basic messaging settings such as mail-archiving policies, mail quotas, and mail encryption. We finish the chapter with a brief look at configuring the Notes client workstation to work with different locations for both local and server-based mail.
For the purposes of the exam, it is important to understand when mail routes automatically within a Domino Named Network, as opposed to mail that needs to be scheduled between networks with a Connection document. As with every chapter, it's also important to learn and memorize the console commands related to routing.
Server Messaging Configuration
Configuring the Domino servers for mail routing involves understanding how mail routes between servers based on the server's Domino Named Network (DNN). A DNN is a group of servers in a given Domino domain that share a common protocol and are constantly connected. The administrator must then be capable of creating any necessary Connection documents and using tools to help monitor and maintain routing. A Connection document is a document that contains all of the settings necessary to schedule mail routing between servers in different DNNs.
Setting Up and Configuring Mail Routing
By default, Domino uses Notes Remote Procedure Calls (NRPC), also called Notes routing, to transfer mail between servers. Notes routing uses information in the Domino Directory to determine where to send mail addressed to a given user. Notes routing moves mail from the sender's mail server to the recipient's mail server.
A user creates a mail message in the mail database. When the user sends the message, a workstation task called the MAILER transfers the message to the MAIL.BOX database on the user's server (also known as the user's mail server or home server). MAIL.BOX is the transfer point for all messages being routed to and from a server. The ROUTER task polls MAIL.BOX and asks two questions about the messages waiting to be routed:
Where this message should be deliveredto which recipients on which servers?
How this message should be deliveredwhich routes and connections should be used?
The router consults its routing tables to determine where the recipient's mail database is stored. Routing tables are built in memory on the server when the router first starts and are refreshed every few minutes. These routing tables are built using information in various documents in the Domino DirectoryPerson documents, Connection documents, Domain documents, and so on. The location of the recipient's mail database determines how the message is dispatched by the router. A recipient's mail database can be stored in any of the following locations:
On the same server as the sender's mail databaseIf the sender and the recipient share the same mail server, the message is delivered immediately and the Router task is not involved in the message transfer. The Router task is invoked only for transfer to another server.
On a different server in the same DNNIf the Server document for the destination server is found within the Domino Directory, the router checks that document to determine the network information for the server.
On the portsOn the Notes Network Ports tab of the Server document, the server is assigned to one or more DNNs. As you learned earlier, a DNN is a group of servers in a given Domino domain that share a common protocol and are constantly connected. If the two servers share a DNN, the Router immediately routes the message from the MAIL.BOX file on the sender's server to the MAIL.BOX file on the recipient's server.
On a server in a different DNN within the local Domino domainWhen servers are members of two different DNNs, the Domino administrator must create connections between the two networks.
On a server in an external Domino domainIn this case, the Router must find a Connection document between domains or must route the message using SMTP, configured to route outside of the local domain.
Because mail routes automatically between servers in the same DNN, you do not need to create any Connection documents to facilitate mail routing. Mail routing within a DNN is always automatic and instantaneous.
The exam will likely use scenario questions to test your ability to understand mail routing between servers, based on your understanding of DNNs and domains. When taking the exam, you may find it helpful to draw a diagram of servers with labels for each of the server names. Then place a circle around each of the servers in the same DNN so that you're able to clearly see where automatic mail routing occurs and where it needs to be scheduled by the administrator.
Setting Up and Configuring Message Distribution Using Schedules
By default, when using Notes routing, Domino can transfer messages only to other servers in the same DNN. To extend Notes routing beyond a single DNN, you must create Connection documents in the Domino Directory and specify a routing schedule. Domino does not automatically create Connection documents for mail routing.
The best way to prepare for this exam topic is to practice creating sample Connection documents and populating all of the settings. If you're able to configure some Domino servers and clients, practice putting two Domino servers in different DNNs and practice scheduling mail routing between the two servers with Connection documents.
To schedule Notes routing using a Connection document, follow these steps:
From the Domino Administrator, click the Configuration tab and expand the Messaging section.
Click the Add Connection button.
On the Basics tab, enter the names of both the source (originating) and target (destination) servers, as well as their domain names and the name(s) of the network ports that the two servers will use to connect. Optionally, you can also enter a network address for the target.
Click the Schedule tab and complete the following fields in the Scheduled Connection section:
ScheduleChoose either Enabled to use this schedule to control connections between the specified servers, or Disabled to cause the server to ignore the schedule.
Connect at TimesEnter a time range during which you want mail to route. The default is 8 a.m. to 10 p.m.
Repeat interval ofThe number of minutes between routing attempts; the default is 360 minutes.
Days of weekThe days of the week when the server should use this schedule and route mail. The default is to use this connection for each day of the week.
For 24-hour mail routing, enter 12 a.m. to 11:59 p.m.
Click the Replication/Routing tab and complete the following fields in the Routing section:
Routing taskChoose either Mail Routing to enable Notes mail routing between the servers, or SMTP Mail Routing to enable routing in Internet mail to a server that can connect to the Internet
Route at once ifThe number of normal-priority messages that accumulate before the server routes mail. The default is 5.
Routing CostThe relative cost of this server connection. This field affects the building of least-cost routes in the router's routing tables on the server.
Router TypeThe router can route in one direction with either the Pull or Push options, or the router can trigger two-way routing, with either the Pull Push or the Push Wait options. In the case of the Pull Push routing option, the router on the originating server pushes mail to the destination server and then triggers the destination server to route mail back again. With the Push Wait routing option, the source server first pushes to the target server and then waits to receive a connection from the target. This last option is usually used between servers with dialup connections.
Entering a value of 1 in the Route at Once field causes each mail message to route as soon as it is received in MAIL.BOX.
New connections or changes to existing Connection documents take effect after the next router configuration update, which typically occurs every 5 minutes on the server, when the routing tables are refreshed. To put the new setting into effect immediately, reload the routing configuration by entering the following console command:
Tell router update config
Forcing Mail to Route to a Specific Server
To force the server to immediately route all pending mail to another server, use the Route command at the server console. Pending mail is mail that is sitting in the MAIL.BOX waiting to be routed. The syntax of the command is as follows:
The Route command initiates mail routing with a specific server. This command overrides any mail-routing schedules that you create using Connection documents in the Domino Directory. Use the Route command to send mail to or request mail from a server immediately.
Here are some examples of how to use the Route command:
Route ServerA/AcmeSends mail to ServerA in the Acme organization. The server console displays messages indicating when routing begins.
Route "Server B/Acme"Sends mail to Server B. Use quotes around server names that are more than one word.
Route *Sends mail to all pending destinations.
In the exam questions, be sure to note which server is initiating the command. A server cannot successfully route mail to itself; for example, if the administrator was using the console on ServerA, the command Route ServerA would have no effect. The exam questions will test your ability to read and understand which server console is being used to issue the commands.
If no mail is queued for routing, Domino ignores the Route command. Use the Tell Router show command at the console to check for messages pending for local delivery or to check for held mailmessages that the administrator has configured the router to hold in order to examine them. Often the administrator will configure the router to hold undeliverable messages in order to examine them before releasing them, as in the case of spam. To check which servers have mail queued, use this command at the console:
Tell Router show
As an alternative to using the console, the administrator can route mail directly from the Server, Status tab in the Domino Administrator client interface. This interface mimics the Route command at the console.
To route mail directly from the Server, Status tab, follow these steps:
From the Domino Administrator, click the Server, Status tab.
If necessary, click Tools to display the toolbar and then click Server, Route Mail.
Under Route Mail with Server, enter the name of the server you want to route mail to, or select the name of the server from the list.
Monitoring and Maintaining Mail Routing
Domino provides the administrator with many tools to monitor and maintain mail routing between Domino servers. This section is designed to give the reader a broad overview of many of the tools. Consult Domino Administrator Help for detailed descriptions of how to use each tool.
For the purposes of the exam, it's important to understand what each tool does, but it's not necessary to memorize each command or button in the interface. That being said, the best way to study the monitoring tools is to use them in the Domino Administrator interface so that you can recall the purpose of each tool.
Using the Messaging, Mail tab
The Domino Administrator client has an entire section dedicated to the monitoring and maintaining of mail. The Domino administrator uses this tab extensively during the work day. Using the Messaging, Mail tab, the administrator can observe and monitor the following:
Mail usersYou can display a view of the Domino Directory that lists all users by mail server and provides each user's Notes mail address and mail filename. From this view, you can add, edit, and delete Person documents and send upgrade notifications.
Routing mailboxesYou can display the current contents of each MAIL.BOX database on the server. Servers can be configured to have multiple mailboxes using the Messaging Configuration document. MAIL.BOX databases on the server can contain three types of undeliverable messages: pending messages, designated with no icon; dead messages, designated by a stop-sign icon; and held messages, designated by a red exclamation point.
Pending messagesThese messages are waiting to be routed by the router on the server. Pending messages are not problematic for the administrator unless they start to pile up in the MAIL.BOX, indicating that there is a routing problem.
Dead messagesThese messages are "stuck" in MAIL.BOX because they can't be delivered to the recipient and they can't deliver their failure to the originator of the message. The most common cause of dead mail is spam. The spammer guesses incorrectly the name of a person in your mail system. When the router can't deliver the message, it attempts to deliver a failure to the spammer. The spammer has purposely not provided a way to return messages, so the message gets stuck in your server's mailbox. In the case of spam, the administrator usually uses the information in the dead message to assist in blocking spam and then deletes the dead message. Dead messages might also indicate networking or other problems with the company. In that case, the administrator corrects the problem and then releases the dead message; the failure message then is attempted again.
Held messagesThese messages are held because the administrator has configured the server to hold mail for manual transfer. This is another setting available in the Mail Configuration document. When you configure the router to hold messages, each held message remains in MAIL.BOX indefinitely and is processed only if an administrator releases the message.
Shared mailYou can display shared mail statistics from the Object Store Usage view of the server's Notes Log database. Shared mail, sometimes referred to as the Single Copy Object Store (SCOS), offers an alternative to message-based mail, allowing servers to store a single copy of messages received by multiple recipients in a special central database or object store. By default, the Domino mail system employs a message-based model for mail storage, delivering a separate and complete copy of every document to each recipient's mail file. To use disk space more efficiently, the administrator can set up shared mail on each mail server after setting up the Domino mail system.
Mail routing statusYou can displays a Java applet providing a graphic representation of current mail.dead and mail.waiting statistics for this server. Domino refreshes the information in this view at intervals of approximately 1 minute.
Mail routing eventsYou can display the Routing Events view of the server's Notes Log. This view enables the administrator to scan and search through all console messages related to mail.
Mail routing topologyYou can display Java applets providing graphic representations of the available routing paths defined by Connection documents and Notes Named Networks.
ReportsYou can display information from the server's Reports database. For more information, see the section "Generating Mail Usage Reports," later in this chapter.
You can improve mail performance significantly by creating multiple MAIL.BOX databases on a server. Using multiple MAIL.BOX databases removes contention for a MAIL.BOX, allows multiple concurrent processes to act on messages, and increases server throughput. As a further benefit, having multiple MAIL.BOX databases provides failover in case one MAIL.BOX becomes corrupted. Watch for the exam to mention using multiple MAIL.BOX databases as a way to improve messaging efficiency. When this feature is enabled, the mailbox databases are named MAIL1.BOX, MAIL2.BOX, and so on.
Domino administrators often get requests from users asking them to pinpoint where a mail message is at any given point in time. Domino has a message-tracking system that is similar to the sophisticated tracking systems used by courier companies to trace packages.
Message tracking enables the administrator to check the status of any message that has been routed within the Domino network. Message tracking is configured using the Message Tracking tab in the Messaging Configuration document. Because message tracking isn't enabled by default, the administrator must enable it in the Configuration document and complete the fields to establish the settings for message tracking.
When you configure mail tracking, you can specify which types of information Domino records. For example, Domino administrators can decide whether to track message subjects, they can disable tracking for certain groups of users, and they can decide who should be allowed to track messages from server to server.
The Mail Tracker Collector task (MTC) reads special mail tracker log files (MTC files) produced by the router and copies certain messaging information from them to the MailTracker Store database (MTSTORE.NSF). The MailTracker Store database is created automatically when you enable mail tracking on the server. When an administrator searches for a particular message, Domino searches the MailTracker Store database to find the information.
The Mail Tracker Collector differs from the Statistics Collector (Collect task), which is responsible for gathering statistical information about servers.
When Message Tracking has been enabled, the administrator can issue tracking requests using the Messaging, Tracking Center tab of the Domino Administrator client. The administrator issues the request by clicking the New Tracking Request button and completing the fields in the New Tracking Request dialog box, as illustrated in Figure 3.1.Figure 3.1 The Messaging, Tracking Center tab of the Domino Administrator.
The administrator clicks OK to complete the request. Domino then displays summary results that include the sender's name, recipient, delivery time, and message subject, if subject tracking is allowed. The administrator can then select a message and click Track Selected Message. When the message has been found, Domino displays the following information about the message: delivery status, mailbox status, previous server, next server, unique message ID, inbound message ID, outbound message ID, inbound originator, outbound originator, subject, disposition time, message arrival time, and message size in bytes.
Generating Mail Usage Reports
Over time, the Domino MailTracker Store database (MTSTORE.NSF) accumulates valuable data about message-routing patterns on the server. The Domino administrator can then generate mail usage reports from this data. For example, you can generate reports of recent messaging activity, message volume, individual usage levels, and heavily traveled message routes. You can use the Reports database (REPORTS.NSF) to generate and store mail usage reports. The Reports database is typically created automatically when you set up the first server in the domain, or the administrator can manually create the Reports database from a template.
On the Messaging, Mail tab, the administrator locates the Reports database at the bottom of the left navigation pane and either generates a new report with the New Report button or opens an existing report. The administrator then completes all of the fields in the Create New Report dialog box. Here is a list of some of the types of reports that can be created:
Top 25 users by count
Top 25 users by size
Top 25 senders by count
Top 25 senders by size
Top 25 receivers by count
Top 25 receivers by size
Top 25 most popular "next hops"
Top 25 most popular "previous hops"
Top 25 largest messages
Message volume summary
Message status summary
Mail usage reports provide important information that you can use to resolve problems and improve the efficiency of the mail network. In addition, this information is valuable when you plan changes or expansions to the mail network. For example, you can generate reports that show the 25 users who received the most mail over a given period of time (a day, a week, a month, and so forth) or the volume of mail sent by a specified user over some interval. With this information, you can identify users who might be misusing the mail system. Other reports show the most frequently used next and previous hops, enabling you to assess compliance with mail-use policies.
Agents stored in the Reports database let administrators schedule reports on a one-time, daily, weekly, and monthly basis. By default, Domino generates scheduled reports at midnight at the interval you specifydaily, weekly, or monthly. When a report query is run, the active report agent examines the data collected in the Domino MailTracker Store database to generate the resulting report. You can configure a report to save results in the Reports database or mail results to one or more administrators. Saved reports are organized in the Reports database under several different views.
You cannot generate mail reports if servers are not configured to do message tracking. Reports are generated using the information collected in MTSTORE.NSF on each server. For reporting and tracking to be most effective, message tracking should be enabled on all or most Domino servers in the domain.
Mail-Routing Event Generators
To monitor a mail network, you can configure mail-routing event generators to test and gather statistics on mail routes. These event generators are also known as mail probes. In essence, a mail probe "pokes" at a server's router to see how quickly that server responds to mail requests.
To test a mail route, the ISpy task sends a mail-trace message to a specified user's mail server. This event generator creates a statistic that indicates the amount of time, in seconds, that it takes to deliver the message. If the mail-routing trace fails, the statistic has the value -1. If the Statistic Collector task is running, the Monitoring Results database (STATREP.NSF) stores the statistics. The format of a mail routing statistic is as follows:
In addition, the ISpy task monitors the local mail server by default and generates events for traces that fail. To monitor other Domino mail servers, create a mail probe and set up an event handler to notify you when an event has occurred. Probes are created in Domino Administrator by clicking the Configuration tab and then opening the Monitoring Configuration view. Open the Event Generators, Mail view; then click New Mail Routing Event Generator and complete the fields.
The ISpy task must be running on the server to generate the statistics gathered by the mail probe. To check whether this task is running on the server, enter Show Tasks at the server console. If the ISpy task isn't running, start the task using the command Load runjava ISpy. Add the ISpy task to the server's NOTES.INI file if you want the task to start up the next time the server restarts. The notation of the ISpy task is case sensitive; the task will not initiate if the command is entered as ispy or Ispy.
Troubleshooting Routing Problems
A variety of error conditions can prevent Domino from properly sending and delivering mail. These topics describe common mail-routing problems and tools you can use to help resolve them.
Delivery Failure Reports
A delivery failure is a message that is returned to the sender indicating that the message was not delivered successfully. Delivery failures are generated for one of two reasons:
The address of the mail recipient is incorrect.
The connection to the recipient is not available or is not working.
Users should always try to resend a memo for which they receive a delivery failure report. In resending, the user is presented with the opportunity to fix the address of the recipient. When a memo has been resent once and the user is certain that the address is correct, the user should alert the administrator to the problem so that the administrator can investigate mail connections and server routes.
To troubleshoot mail routing or test mail connections, trace a mail delivery to test whether a message can be successfully delivered without actually sending a test message. The results of the trace are returned to the administrator's mail database in the form of a mail message, listing every server in the route.
From the Domino Administrator, click the Messaging, Mail tab.
If necessary, click Tools to display the toolbar.
From the toolbar, click Messaging, Send Mail Trace.
Address the message to the person you want to trace. Choose Last Router Only to receive a message from the last server to successfully route the message; otherwise, you'll receive a message from each server hop.
Mail-Routing Topology Maps
Mail-routing topology maps are useful to track mail-routing problems between servers because the administrator has a pictorial view of the connections between servers in the domain. To create a mail-routing topology map, follow these steps:
From the Domino Administrator, click the Messaging, Mail tab.
Choose one of the two available views:
Mail Routing Topology by Connections
Mail Routing Topology by Named Networks
Console Commands Used to Troubleshoot Mail Routing
In the interest of saving time, many Domino administrators use console commands where possible instead of using the equivalent option in the Domino Administrator interface. For this reason, Lotus often includes several exam questions related to console commands in all exams. The following is a listing of console commands that are helpful in troubleshooting mail-routing problems or in displaying mail-related information:
Tell Router Delivery StatsShows router delivery statistics
Tell Router CompactCompacts MAIL.BOX and cleans up open router queues. You can use this command to compact MAIL.BOX at any time. If more than one MAIL.BOX is configured for the server, each MAIL.BOX database will be compacted in sequence.
Tell Router Show QueuesShows mail held in transfer queues to specific servers and mail held in the local delivery queue.
Tell Router Exit or Tell Router QuitStops the router task on a server.
Load RouterStarts the router task on a server.
Tell Router Update ConfigUpdates the server's routing tables to immediately modify how messages are routed. This removes the 5-minute delay before a router configuration change takes effect.
By default, MAIL.BOX is automatically compacted at 4 a.m.