E-mail by itself, without all the other features of Notes, has been known to change corporate culture. E-mail is the lifeblood of communication for many organizations today. Reliable, fast delivery of e-mail is the number one priority for Notes
administrators. A lonely Notes administrator only need pull the plug on the mail server to hear the phone ring.
Notes Mail is designed to work with most existing e-mail packages (with the appropriate mail gateway package). The list of third-party mail gateways for Notes is so extensive that Notes has been proposed as a universal mail gateway, able to take mail
from anywhere and route it anywhere. Notes Mail can connect directly to any MAPI- or VIM-compliant mail package as well as MHS, Profs (an IBM mainframe mail system), the Internet, and more. Connecting Notes to other mail systems continues to get easier
with each release. The Notes e-mail system is called, naturally enough, Notes Mail.
Notes Mail supports the asynchronous transfer of messages between nonconnected servers and workstations.
By default, any document in any database can be mailed. Notes can deliver mail to any Notes database, not just mailboxes. The Notes administrator simply needs to set up an address for a database in the Public Address Book, and that database can receive
mail. Personal mailboxes are simply Notes databases with views, forms, and agents tailored for e-mail. You could copy any or all of the features from the default personal mailbox to any other database. You need to set up a Mail-In Database document in the
Public Address Book for any non-mailbox that is to receive mail. The Mail-In Database document defines a mail address for the database.
Notes supports encryption and electronic signatures (introduced in Chapter 3) for all databases, but these features are especially easy to use as part of sending and receiving mail. Administrators or users can configure mailboxes to encrypt incoming or
outgoing mail. In addition, users can choose to sign a mail message. Signing a message enables the recipient to validate the identity of the sender and guarantees that a message wasn't altered in transit.
Notes mailboxes also come with agents for archiving mail, sending out-of-office notices, and populating personal address books. Mail forwarding can be done for individual messages by users. Administrators can have all messages forwarded by entering a
forwarding address in the person record for a user in the Public Address Book.
Your primary consideration when planning for Notes Mail is reliability. The two most critical factors are ensuring that adequate disk space exists for personal mailboxes and configuring connection documents and foreign domain documents to enable mail
routing between Notes and other networks or mail systems.
Every Notes user has a personal mailbox. Administering these mailboxes is easier when you group them together on one server. Having one mail server also reduces the number of connection documents that must be set up. The only users who shouldn't be
using server-based mail are remote and mobile users. This type of user needs to have a copy of her personal mailbox on her workstation and dial into a server to replicate mail.
E-mail reliability is enhanced by minimizing the number of documents that must be configured in the Address Book. You should pay particular attention to the number of connection documents that must be maintained. You need a pair of connection documents
to route mail between servers on different networks or in different domains.
At least one server in each Notes named network must have a connection document to a server on the other Notes named network to route mail between the two networks. This is true even when both networks are in the same domain. Notes is smart enough to
route mail between networks if there is a single server connected to the other network. The router will automatically forward mail to the server that is connected to the other network. This system means that you never need more than one pair of connection
documents to route mail between networks. You should pick two or three servers on each of your Notes networks to act as gateways to Notes networks, and specify more than one link between networks so that mail will be routed even if one of the connected
servers fails. This method greatly reduces the number of connection documents and the chance for error.
A single connection document can be used to schedule both mail routing and replication. You can reduce the number of connection documents by taking advantage of this feature. If you want to route mail more often than you replicate, you will need to set
up one pair of connection documents for mail routing and one for replication. Do this only if replication is taking a long time to complete. Setting up multiple connection documents between servers makes it possible to have overlapping connection
documents. Overlapping connection documents specify conflicting or duplicate information and can confuse the router.
All servers in a domain must use a common Public Address Book for mail routing to work reliably. Make sure that all servers are regularly replicating the Address Book to keep connection and server documents updated.
Finally, restrict access to connection documents to a few administrators. This plan reduces the chance of error when you add or delete servers on the network. Use roles in the Public Address Book to specify the administrators with the right to create
and modify connection documents.
All mail servers serving more than 50 users should set a quota on the size of individual mailboxes. To calculate a quota for mailboxes, you must determine the amount of disk space you can devote to mailboxes and then divide by the number of mailboxes
you need. Leave some disk space unassigned, to handle users that must have additional disk space.
Administering Notes mail is simplified when you use mail serversservers dedicated to mail. We recommend placing all personal mailboxes on a single server (large organizations will need multiple mail servers). Grouping mail on one server
allows you to provide a consistent level of service to your users. Grouping mailboxes
By isolating mail from the effects of other Notes databases, you ease performance monitoring and troubleshooting. A server running a troublesome application is no place for a mailbox. That person's mail is unavailable while the server is down. Server
crashes are the main cause of corrupted databases. You can avoid corrupting personal mailboxes by grouping them on a single mail server. Mail servers also minimize the number of servers involved with routing mail. Any server on the same network as the mail
server delivers mail directly to the mail server. In a hub-and-spoke environment, only the source server, the hub, and the mail server are involved. Fixing mail delivery problems is easier when fewer servers must be considered.
The release of a poorly performing application will have minimal impact on your mail delivery when you are using a mail server. This wouldn't be the case if mail were intermingled with other applications. Other applications have more unpredictable loads
due to index building and replication overhead. As you add applications and users to a Notes database server, performance may fall dramatically; as you add users to a mail server, performance degrades slowly (if at all). By monitoring memory and free disk
on your mail server, you can plan ahead for upgrades. You should be able to predict when you will need a second mail server by tracing mail performance as users are added.
Mail servers also minimize network traffic. Mail sent from one user to another user on the same home server is placed directly in the recipient's mailbox without any network traffic. For organizations sending large files, graphics, or multimedia
presentations, this is a real concern. More organizations fall into this category every day. Plan ahead and save headache later by using mail servers now.
Mail servers also allow you to save disk space. Notes stores messages delivered to more than one person just once. Instead of the actual message, a pointer is placed in each person's mailbox. If John and Sally have the same home server (their mailboxes
are on the same server), a message addressed to both of them is stored a single time.
The router is the Notes task responsible for delivering mail. The router scans MAIL.BOX looking for new messages, and uses the Name and Address Book (NAB) to determine what action to take with the message. The router runs on all Notes servers, not just
on a mail server. All notes servers need a MAIL.BOX database and a copy of the NAB in order to route mail.
Mail routing is more complex when sending across domains or networks. Remember, all servers in a domain share a single NAB. Notes needs additional information when routing mail between networks and domains. This information is provided by connection
records and nonadjacent domain records. The primary benefit of grouping servers together in a single domain is simplified mail routing.
A mail message is altered as it is delivered. The Notes workstation substitutes full hierarchical names for any short names used, and expands groups to their individual members. The router also modifies the message, adding fields to make troubleshooting
easier and modifying recipient and originator addresses. Addresses are modified when sending between domains to provide complete path information for replies.
Figure 14.1 shows mail being routed within a domain. A message is sent by being placed in MAIL.BOX on any server. The router scans MAIL.BOX, finds the message, and reads the SendTo field. (All Notes mail must have a SendTo field.) The recipient's person
record in the NAB is used to find the correct home server. The server document for the home server is checked to see which network the server is on. The router connects to the home server and places the message in MAIL.BOX on that server. A field,
RouteServers, is added to the message, showing that the message was created on the source server and was sent to the home server. The recipient and originator addresses aren't modified. The router on the home server places the message in the correct
personal mailbox.
Figure 14.2 shows how the message is modified at each step.
Figure 14.1.
Delivering mail within a domain on the same network.
Figure 14.2.
E-mail is modified during delivery. Each server may modify the address and RouteServers fields.
In this scenario, three documents need to be correctly configured in the NAB: a person document for the recipient, and server documents for the source and home servers.
Multiple recipient messages are handled in a similar manner. Only one mail message is sent per home server. The router doesn't send multiple messages, one per recipient, to a home server.
You can specify a destination in another domain by adding an "@ domain" to the recipient address. For example, to send mail to Benny/Transport/TCom in the TCom domain from the Acme domain, the address is Benny/Transport/TCom @ TCom. The router
treats anything to the right of "@" as a domain name. If the domain name is different from the current one, the router looks through connection documents for any server in its domain with a connection to a server in the recipient domain. If no
direct connection is found between the domains, nonadjacent domain documents are searched. Nonadjacent domain documents specify the next server in the path to the destination domain. This next server then must know how to deliver the message. Figure 14.3
shows the path a mail message takes when being delivered to a different domain (in this case, one that isn't directly connected). Figure 14.4 shows the connection documents needed to route mail from the TCom domain to the Acme domain.
Figure 14.3.
Mail routing between domains.
Figure 14.4 shows the connection, server, and domain documents needed to route mail from the TCom domain to the Acme domain. Another set of documents is needed to route mail from the Acme domain to the TCom domain. In a real situation, there would be a
pair of connection documents for servers B and C as well as for servers C and D. The Acme domain would need an adjacent domain record for the Lippi domain and a nonadjacent domain record for the TCom domain.
Figure 14.4a.
Figure 14.4b.
Figure 14.4c.
Figure 14.4d.
Figure 14.4e.
Figure 14.4f.
Figure 14.4g.
Figure 14.4h.
Figure 14.4i.
Connection, server and domain documents needed to route mail in figure 14.3.
Mail is routed through the Lippi domain on the way to the Acme domain. The router in each domain adds its domain name to the originator name and deletes its domain name (if present) from the rightmost domain name list. This is done so that at any point
during transmission, should an error occur, the message can be returned to the original sender. If the original recipient in Figure 14.3 is John/Marketing/Acme @ Acme and the original sender is MyName, the recipient and sender fields of the delivered
message would be John/Marketing/Acme and MyName @ TCom @ Lippi.
The router doesn't expand names and groups to the left of the @. The destination domain expands any groups, but doesn't expand any simple names into full hierarchical names. Typos in a group name or recipient address aren't be discovered until the
router in the destination domain can't deliver the message. A recipient must have an unambiguous address when it is received by the destination domain. A single exact match must be found in the local Name and Address Book for either a person or a group, or
the message will be returned.
The router efficiently handles multi-domain mail when multiple recipients are specified. Only a single copy of the message is sent to any destination domain. This isn't necessarily the case for gateways. Mail sent through a gateway is handled by the
gateway and not the Notes router, so all bets are off when routing mail through a gateway.
A Notes network is any collection of servers that can connect directly to each other using a common protocol. Servers on different networks may or may not be in the same domain. Networks and domains are two different concepts.
Figure 14.5 shows mail routing between networks. A mail message must go through two intermediate hops before being delivered to the home server. The router compares the network lists in the server documents for the source server and home server. No
match is found. The connection documents are then scanned to find a path to the home server (the connection documents are already loaded into memory, so scanning is very fast). The router is searching for any combination of connection documents that define
a complete path to the home server. (To be completely correct, a Notes server actually scans all connection documents when booted and keeps an in-memory network diagram for use with routing messages.) For example, the router may find a server on its
network with a connection to the home server, a server on its network with a connection to another server on the same network as the home server, or a server with a remote connection to the home server. The router can deliver the message successfully in
any of these cases. If no complete path is found, the mail is returned as undeliverable.
Figure 14.5.
Mail routing between servers within a domain, but on separate networks.
In this scenario, at least five documents in the NAB need to be correctly configured: a person document for the recipient, and four server documents (one for each server). To deliver the message, all three networks need to be operational and the bridge
between them needs to be working. Figure 14.6 shows the server documents needed to route mail from Server A to the home server in Figure 14.5. Normally, connection documents are needed to route mail from one named network to another. In this case, the
intermediate servers are defined to be on two networks, making a connection document unnecessary. If either server B or server C wasn't on two networks, one or more connection documents would be needed to link at least one pair of computers from each named
network. The moral of the story here is that you can reduce the number of connection documents by defining gateway servers that exist on two named networks.
Figure 14.6a.
Figure 14.6b.
Figure 14.6c.
Figure 14.6d.
Documents required to route mail in Figure 14.5.
The mail message is modified as in Figure 14.2. RouteServers would list Server A, Server B, Server C, and the home server.
Notes maintains a history of connections that have recently failed, and will attempt to reroute mail around failed connections by searching connection documents for a different path. Alternate path selection focuses on finding different servers to use.
Notes doesn't support automatically trying alternate ports to a single server. If Notes Server A attempted to connect to Server B using port LAN0 and failed, and COM2 was also configured as a connection to Server B, Notes wouldn't automatically attempt to
use COM2 to connect to Server B.
The router always attempts to use the "least cost" route when delivering mail. Each connection has an associated cost; the cost of a route is the sum of the costs of the individual connections. The router can't use alternate, more expensive
routes. Only routes that are equal in cost to the original route are considered. This prevents a flood of traffic across bridges or the use of multiple dial-up connections to route mail.
You can configure this cost in the connection document, or rely on the defaults. The default cost for LAN connected servers is one. You should change this to two for servers connected across a bridge. COM ports have a default cost of five. If multiple
routes of identical cost exist, the server that comes first alphabetically is used.
Connection documents contain Allow Mail Only From and Deny Mail From fields. These fields can be used to cut off mail delivery from untrusted domains. These fields control mail coming from other domains, not domains that can be reached from your domain
(if you don't want mail going to a domain, don't create a connection document for it). The router checks incoming mail against the entries in these fields. If there are domains listed in the Allow Mail Only From field, and the domain submitting the message
isn't listed, the message is rejected. If there are domains listed in the Deny Mail From field, and the domain submitting the message is listed, the message is rejected.
Mail routing between servers on a network is immediateyou never need to schedule mail delivery between servers on a network. Servers on separate networks or domains use connection documents to specify a mail delivery schedule. You can have servers
deliver mail periodically and/or deliver mail when the number of pending mail messages exceeds a threshold. You can have mail delivered automatically whenever two servers connect for replication, or specify a schedule just for mail delivery.
You should carefully plan mail delivery between modem-connected servers. Build a schedule that lets users exchange a message and reply within a half day. Trouble tickets generated in response to an alarm are delivered via mail; another reason to specify
a connection interval of no more than a half day (two hours is better) between modem-connected servers.
You can always route mail immediately by using the Route command at the server console.
Each Notes message has an associated priority. These priorities affect how mail is delivered between servers that aren't on the same Notes named network (mail always is delivered immediately if the destination is a server on the same Notes named
network). Users can specify high, normal or low priority when sending a message. High priority messages are routed immediately regardless of what is in the server or connection documents. Normal priority mail is routed at the next scheduled mail delivery
time. Low priority mail is routed only during off-peak hours. By default, low priority mail is delivered between 12:00 a.m. and 6:00 a.m. Low priority mail is seldom used in most organizations, so the default delivery times should be sufficient.
WARNING: Make sure that your connection documents between modem-connected servers specifies a connection time between 12:00 a.m. and 6:00 a.m., or low-priority mail will never be delivered.
You can disable mail priorities on a server by setting the MailDisablePriority parameter in the NOTES.INI file to 1. This causes all mail to be routed using normal priority. Chapter 13, "Administrative Tools," discusses ways to edit NOTES.INI.
Appendix B, "NOTES.INI Parameters," contains a complete list of mail-related parameters.
The router can be configured to enable mail transfer to multiple servers simultaneously. The router needs one thread for each server to which it is transferring mail. The default is to configure one thread per server port. Because a server can easily
connect to more than one server using a LAN port, you may want to increase this limit. There is virtually no penalty to increasing this limit, as threads are created only when they are needed. To increase the maximum number of router threads, edit the
MailMaxThreads parameter in the NOTES.INI file. Set this parameter equal to 32 or 64, depending on your operating system. UNIX systems don't support threads, so processes are used instead.
Notes 3.x administrators report assigning anywhere from 50 to 500 users to a single mail server. Notes 4.0 should result in higher usage capacities. Because server capacity varies according to platform and usage, no definitive answer is possible. You
should collect information during the pilot installation (discussed in Chapter 5, "Building a Deployment Plan") to determine an estimated mail server capacity in your organization. Monitor the following statistics to determine the usage pattern
in your organization:
These statistics can be tracked using information in the Notes log.
When configuring your mail servers, always allow room for growth. Over time, you will need to add more users and allow users to do more with their mailboxes.
Shared mail reduces the disk space requirements for personal mailboxes. Messages addressed to multiple recipients are stored only a single time in the shared mail repository. Users' mailboxes contain links to mail stored in the shared database. User's
never need be aware that their mail is stored in a shared mail database. They can view, edit, forward, and replicate their mailboxes without worrying about shared mail.
Shared mail can significantly reduce the disk space requirements on a mail server, but there is a price to be paid. Creating, deleting, and moving personal mailboxes take one extra step. You must link new databases to the shared database and unlink
mailboxes that are being moved or deleted.
Shared mail must be enabled by an administrator. The default is not to use shared mail. These are the steps in configuring shared mail:
The router creates a shared mail database and edits NOTES.INI for you. Make sure that the router is running on a server; then enter the following command at the server console:
Tell Router Use SharedDatabaseName
SharedDatabaseName is the full path name for the shared mail repository. The directory that you specify must be part of the Notes data directory tree. Otherwise, the router can't find the shared database when the server is rebooted.
The router will create the shared database and set the Shared_Mail parameter in the NOTES.INI file to 2. The router also creates MAILOBJ.NSF in the Notes data directory. MAILOBJ.NSF is a database pointer to the actual shared mail database. As there can
be only a single MAILOBJ.NSF file, the router can store mail only in one shared mail database. You can always change this database, but can never have two active at one time.
The Shared_Mail parameter controls which messages are placed in the shared database. A value of 2 tells the router to place all messages in the shared database. This setting can waste space by allowing messages addressed to a single user to be stored in
the shared database. This can also cause the shared database to grow very large, slowing mail performance. By setting the Shared_Mail variable to 1, only mail addressed to more than one recipient is stored in the shared database. Other mail will be stored
in personal mailboxes.
After you have created a shared mail repository, you can link mailboxes to the database. You can link individual mail files or entire directories. If you are going to process an entire directory, you should first exclude any mailboxes that won't use
shared mail. To exclude a mailbox enter this command at the server console:
Load Object Set -Never MailboxName
MailBoxName is the file name of the mailbox, including the directory, that should be excluded. You can always reverse this setting with the following command:
Load Object Reset -Never MailboxName
You can link a mailbox to a shared repository with the following command:
Load Object Link MailboxName SharedDatabaseName
MailboxName can be either the name of a single database or a directory. For example, you could enter
Load Object Link c:\notes\data\mail shared.nsf
to link all databases in the mail directory to the database shared.nsf.
The Link parameter causes all messages in the mailbox that aren't already linked to another shared database to be linked to the shared database. All new messages also are linked. To link all messages, including those that are already linked to another
shared database, use this command:
Load Object Relink Mailbox SharedDatabaseName
When linking a database to a shared mail database, if more than five messages are copied from the mailbox to the shared database, the mailbox is compacted. See Chapter 17, "Administering Notes Databases," for more detail on compacting
databases. To prevent compaction of mailboxes, use this command:
Load Object Link -Nocompact Mailbox SharedDatabaseName
Mail boxes aren't compacted even if more than five messages are copied to the shared database.
You can check to see which mailboxes use shared mail with this command:
Load Object Info Mailbox
You can only check for a single mailbox at a time.
You must unlink all personal mailboxes from a shared mail database before deleting it. Otherwise, users will be knocking down your door wondering where their mail went. To unlink all personal mailboxes, use the following command at the server console:
Load Object Unlink SharedMailDatabase.nsf.
This will cause all shared messages to be copied to the personal mailboxes of all recipients. Because this action can cause a significant increase in the amount of disk space used, make sure that you have plenty to spare before trying this command.
You must wait 24 hours after unlinking personal mailboxes before deleting the shared mail database. This time allows the router to copy documents from the shared database back into the personal mailboxes.
The Collect server task is responsible for purging messages from the shared database. After each recipient of a message has deleted the link from his or her personal mailbox, the Collect task will remove the message from the shared database. The Collect
task runs daily at 2:00 a.m.
The Collect task also can be used to delete obsolete links in personal mailboxes. Links in personal mailboxes can become obsolete when a shared mail database is corrupted. Some messages in the shared mail database may not be recoverable, yet a user's
mailbox still may contain links to the messages. The user can't read these messages. To remove these obsolete links from a database enter the following command at the server console:
Load Object Collect MailboxName
You may need to move personal mailboxes when people change jobs or when a mail server is overloaded. Follow these steps:
Load Object Unlink MailboxName
If the user is moving to a different mail system, enter a forwarding address in the user's person document and have the user forward all stored mail to himself.
Mail gateways are an unfortunate reality of life. Different mail systems use different mail addressing schemes, different internal formats, and support different features. Gateways may offer less than either e-mail system. Mail gateways have higher
administrative overhead and fewer features than a homogeneous e-mail system. Notes mail features lost with most gateways include encryption, nondelivery notices, high priority mail delivery, and confirmation of delivery to the recipient. If possible, we
recommend using a single e-mail system for internal use, whether that e-mail system is Notes or some other system. Notes can directly use any VIM- or MAPI-compliant mail system.
E-mail gateways all work in essentially the same way. A message is treated either as an entry in a database or as a file in a directory. Gateways are responsible for understanding the formats used by the two mail systems being connected. Mail system A
writes out messages destined for a user of mail system B to a special database or directory, generally configured by the administrator. The AtoB gateway scans this database or directory, reads any new mail, performs all conversions, and places the message
in a new database or directory, where mail system B takes over.
In Notes, gateways are configured as foreign domains. Other e-mail systems appear to Notes as a separate domain. The Notes administrator uses foreign domain documents to specify a particular database to which all e-mail is sent for users of a particular
mail system. The gateway program for the other e-mail system must be configured to read this database. In order for this to work well internal to an organization, users of other mail systems should be listed in a "gateway" Notes NAB stored in a
different directory from the main Public Address Book. All users need access to both of these Address Books. Non-Notes e-mail users also must be listed in the directory of the other e-mail package. In multiple-mail-package environments, double the amount
of work of a single e-mail environment may be required to keep mail routing correctly configured. Directory synchronization is meant to solve this problem.
Directory synchronization is the process of posting updates automatically from one e-mail directory to another e-mail directory. This system removes the administrative burden of keeping multiple copies updated. Some directory synchronization
products require that one or the other e-mail system be the master from which all changes originate. These gateways are suitable only for single departments in the process of converting mail programs. If you have multiple departments, each with their own
e-mail package and their own administrator, assigning one as the master directory will be impossible. Before buying a gateway, make sure that it will work in your environment.
You must create a foreign domain document for every mail gateway you install. The foreign domain record enables users to address mail to the gateway. Mail sent to users of the other mail system must specify the foreign domain. For example, if you have
set up a gateway to Microsoft Exchange and given it the foreign domain name Exchange, to address mail to Peggy Sue, an Exchange user, enter Peggy Sue @ Exchange in the To: field.
To create a foreign domain document:
Check the documentation that came with the gateway product when filling out the fields in the foreign domain document. Some fields may have to contain specific values for your gateway to work.
You can restrict the domains that can send mail to this gateway by specifying a list of domains allowed to send mail or by specifying a list of domains that can't send mail. The default is to allow all domains to send mail. (There is no way to restrict
who can receive mail from a gateway using a foreign domain document. See the documentation that came with the gateway for this feature.) Follow these steps:
You must have author access to domain documents to create a foreign domain.
Monitoring Notes mail is a matter of configuring the desired mail monitors on each server. Notes uses reconfigured agents to generate mail events and to provide mail statistics. Events are discussed in detail in Chapter 13, "Administrative
Tools." Events are generated by the Event server task. The Event task doesn't run by default; we recommend running Event on all servers. To run Event automatically at server startup, add Event to the NOTES.INI variable ServerTasks=.
On servers running both the Event and Report tasks, run Event first, as it's the Event task that creates the Statistics & Events database used by both tasks. List Event first in the ServerTasks= variable.
To configure which mail events to report and the database/server used to collect events, you create Event Monitor documents in the Statistics & Events database (EVENTS4.NSF).
When the Event server task has been run at least one time, you can create monitor documents to monitor Notes mail. To create an mail event monitor, follow these steps:
We recommend using a centralized collection point for mail events. This plan speeds up identification and resolution of problems. Designate a single server as the collection point for all mail events on a network. The Event task writes all events directly to the STATREP.NSF database on the collection server. Avoid using Mail to alert you of Mail errors.
SNMP products allow administrators to view status and error information on the entire network through a single console. We recommend using an SNMP tool when managing large networks of servers.
Severity | Event Description |
Fatal | No Name and Address Book database found. Unable to allocate mail message queue item. Unable to locate Name and Address Book. |
Failure | Error delivering to <server name> <mail file name>. Error transferring to <database name>. Groups cannot be nested more than 6 levels deep when mailing. Maximum hop count exceeded. Message probably in a routing loop. No route found to domain <domain name> from server <server name> via server <server name>. Check Server, Connection and Domain documents in Name & Address Book. No route found to domain <domain name> from server <server name>. Check Server, Connection and Domain documents in Name & Address Book. No route found to server <destination server> from server <initial server>. Check Server and connection documents in Name & Address Book. Recipient's Name & Address Book entry does not specify a mail file. Recipient user name <user name> not unique. Several matches found in Name & Address Book. The number of documents and/or attachments in the selected messages exceeds the capacity of your mail system. There were too many recipients listed in the message. This recipient's public key has been disabled in the Address book. Too many recipients. Recipient addresses must total less than 2MB. User <user name> not listed in public Name & Address Book. Your Domain does not have access to route messages to the specified domain. Your mail system is unable to complete your requested action. *** UNKNOWN ROUTER ERROR *** |
Warning (high) | Unsupported use of group name; Cannot send to a Group @ Domain nor auto-forward to a Group. |
Warning (low) | A duplicate recipient was specified and will be ignored. Invalid SendTo or CopyTo field value. This recipient's public key could not be found in the Address book. This recipient does not have a North American license. You are already sending mail. You must complete sending it first. You do not have a mail system specified. Use Tools Setup Mail... to set it. |
Normal | Mail held in outgoing mailbox for transfer to <number of> users. Mail submitted for delivery. (1 Person/Group). Mail submitted for delivery. (<number of> People/Groups). New mail has been delivered to you! |
The Notes administrator must check the mail event reporting database at least twice a day. Consider specifying an agent that will mail the administrator a notice whenever more than three unread documents are waiting in the event reports database.
You can prevent a flood of the same message by editing the message document. Open the Stats and Events database and select Names and MessagesMessages from the navigator. Open the message you want to alter and go into edit mode (Ctrl+E). Set the
minimum number of minutes between events by editing the Suppression Time field. For Fatal and Failure level mail events, we recommend setting the suppression time to at least one minute except for Route not found messages. Set
the suppression time to at least 15 minutes for Route not found-type messages. This setting gives the administrator time to fix any corrupted connection documents or reboot a Notes server (whichever is required). Route not found-type messages are also the ones most likely to multiply quickly, generating an event for each mail message being routed.
The statistics reporter automatically generates a variety of statistics, including the number of dead mail messages and the number of pending messages. Use the number of pending messages as a rough guide to mail performance. If you regularly have
several mail messages pending, you may need to change your mail schedule or get a faster connection (if the server is remote).
Whenever a user is having mail problems, check the Mail Routing Events view of the Notes log. You can control how much information is logged by using the Log_MailRouting parameter in the NOTES.INI file. These are the possible values for Log_MailRouting:
See Chapter 13, "Administrative Tools," for details on editing NOTES.INI.
Gateways are the source of most mail problems. A little planning can eliminate mail problems caused by applications sending out notices. Other sources of mail problems are corrupted NABs or simple human error.
Notes generates a nondelivery report whenever it can't deliver a message. Most nondelivery reports are caused by typos in the address field. Other possible causes include
Nondelivery reports are returned to the originator of the message, not to the Notes administrator.
Dead mail is mail that can't be delivered or returned to the sender. Mail that can't be delivered within 24 hours is placed in the dead mail pile. When a Notes user generates mail that can't be delivered, Notes returns that mail to the user; it isn't
considered dead mail.
Common causes for dead mail include
Configure the Statistics Agent to mail you notices of dead mail. Notes administrators should respond to dead mail within two hours. In addition to using a dead mail agent, you can check for dead mail by using the server console command SHOW TASKS or by
opening MAIL.BOX on your servers.
You can usually determine the cause for dead mail by checking the message. To open a piece of dead mail, follow these steps:
There are several questions to ask when tracking down the cause for dead mail:
After determining the cause of the problem, correct one or both of the recipient or originator addresses and resend the message. To resend dead mail, follow these steps:
Problems with creating or sending mail are usually caused by either a corrupt mailbox or the user not having added his mailbox to the desktop. A users can add his personal mailbox to his desktop by using File, Database, Open, selecting his home server,
and selecting his personal mailbox from the list of databases.
Check that the home server listed in the user's person document in the NAB is the same as the one configured on the user's desktop.
Use a mail agent to monitor the number of messages waiting to be delivered. Have a notice mailed to you whenever the number of waiting message passes a particular threshold.
If you're lucky, this is caused by a network problem. The connection to the next server is down and mail is backing up. If you're unlucky, the MAIL.BOX on the server is corrupt and needs to be restored. This problem can also be caused by spelling errors
in the server's server document in the NAB. Also check the spelling of the domain name in the NOTES.INI file on the server.
If you suspect a corrupted NAB, try running Fixup before resorting to a rebuild. If you must restore the local NAB, create a replica from another server.
Notes users can create their own NABs in addition to the corporate NAB provided by Notes administrators. Each NAB must be listed on the NAMES= line of NOTES.INI. Notes doesn't treat all NABs alike. The first NAB is the only one used when routing mail
between servers. The second and any subsequent NABs are used only for recipient name lookup. Use multiple NABs to
Don't use multiple NABs to
Notes doesn't look in the second or subsequent NABs for server documents, connection documents, or groups. The NABs are searched in the order listed in NOTES.INI, for a full or partial match for each recipient. If a match is found, the current NAB is
searched for any other alternate recipients. For example, if a match is found in the second NAB listed in NOTES.INI, Notes doesn't search the first or third NABs for alternate recipients.
To configure a workstation or server to use multiple Name and Address Books, follow these steps:
The NOTES.INI file will be updated to reflect the local Name and Address Books.
Users have a common set of concerns that you can preempt by providing the following mail agents. These agents are in the MAILAGNT.NTF template database on the CD for this book. We recommend making these a part of the standard personal mailboxes.
To include these agents in your standard personal mailboxes, follow these steps:
A vacation agent is used to notify people that you are out of the office. The agent automatically sends this notice the first time mail is received from a user. You can also set up the mail agent to exclude certain addresses. If you subscribe to
Internet mailing lists, use this feature to prevent out-of-office notices being sent to your lists.
To use the vacation agent, the user needs to change the dates the agent runs, enter her own vacation notice text, and enable the agent. The vacation agent is a standard part of a Notes mailbox. To enable a vacation agent, follow these steps:
Figure 14.7.
An Out of Office profile.
You can create multiple Out of Office profiles if you know you will be taking multiple trips.
Keeping mail organized is a universal problem. Finding a particular old message becomes a chore. Your users can avoid this problem by creating one or more agents to file messages automatically in folders. First, the user needs to create folders for each
category of mail he receives. Create categories for major projects, for each person from whom you regularly receive mail, or for any Internet mailing lists to which you subscribe. A sample filing agent is included with MAILAGNT.NTF. Each user will need to
create agents for his own particular categories.
To create a filing agent for the Key Measurements folder, follow these steps:
Keep in mind this caveat for the filing agent: Running multiple versions of this agent may cause confusing outcomes. If the search criteria overlap, causing a single mail message to be processed by more than one agent, the destination folder can't be
predicted.
Instead of deleting old mail, archive it to another database. Archiving mail to a local database saves disk space on the server (which you may or may not want to do). The mail archive agent is configured once by users for their personal mailboxes.
Here's a caveat for the archiving agent: Archiving old mail to a local disk uses disk space faster. The archived mail probably isn't being backed up. Users still should prune their archived mail every six months or so, deleting unimportant messages
rather than simply deleting the oldest messages.
To enable mail archiving, follow these steps:
Figure 14.8.
An archive profile for a user's mailbox.
The program creates the archive database and enables the archive agent. To edit your archive profile, open the Archiving view in your personal mailbox.
You can install Notes and never use Notes Mail. All Notes workstations can be configured to use some other mail transport system. You can tell Notes to bypass its own mail system and use an alternate mail package by following these steps:
Figure 14.9.
The Mail Preferences panel of the User Preferences dialog box.
You still get to use the Notes mail interface when originating mail from a Notes workstation (although you don't have to). Notes uses whatever transport system you specify.
You can encrypt individual mailboxes, individual messages, or all mailboxes on a server. Mail encryption prevents anyone except the recipient of a message from reading the message body. Message headers aren't encrypted.
For details on how to configure mail encryption, see Chapter 18, "Administering Notes Security."
With Release 4.0, Notes Mail has come of age. Notes Mail directly supports advanced features such as encryption, electronic signing, mail forwarding, and out-of-office notices. Administrators can set up mailboxes that store message bodies in a shared
mail database. Automatic monitoring and alarms also reduce the effort required to keep mail working.
Even with all these features, a little planning can pay off. You should consolidate user mailboxes onto a common server. This can reduce network traffic, and increase the reliability of mail routing.
The source of most mail problems will be mail gateways. Mail gateways are programs that know how to transfer mail from a Notes mailbox into a mailbox of another mail system such as SMTP mail (Internet mail). You should monitor mail gateways daily to
catch any problems.