ShowTable of Contents
Table of Contents
If your company is like most companies using Lotus Domino, you are using your server to route mail. This article provides a brief introduction to Domino mail routing concepts and helps you to learn more about how to manage a Domino mail environment. Since there are many great resources already available, this article helps guide you to these resources.
For a description of the tasks, databases and templates involved in mail routing, refer to
Mail routing with the Domino mail server.
Managing Spam
As a Domino administrator, one of the most common concerns is how to deal with spam. There are a number of resources and options available. To understand how to use the options available within the Domino server configuration, refer to the articles
Controlling spam: Advanced SMTP settings in Lotus Domino and
Understanding SMTP authentication and securing your IBM Lotus Domino 8 server from spam.
In addition to the SMTP settings, you may also want to create a server-based mail rule to filter mail. For information on creating mail rules refer to the Domino Infocenter topic
Filtering new mail using rules.
In additional to the security capabilities in Domino, many companies use a spam filtering service or software. One example would be
Lotus Protector for Mail Security. If you are using a 3rd party spam filtering service, you may want to configure your server that only mail which is being sent from your vendor will be accepted by your server. You can easily do this by defining SMTP
Inbound Connection Controls. In order to do this, you will need to obtain a list of hosts, IP addresses or IP ranges used by your vendor. You can then define those entries as well as your internal hosts in the field
Allow connections only from the following SMTP internet hostnames/IP addresses. You will find this setting in the configuration document on the
Router/SMTP →
Restrictions and Controls SMTP →
Inbound Controls tab. In the example shown in figure 1, you can see an IP range, IP address, generic host name and the internal private network range allowed for inbound SMTP mail connections. The host name must only match the end of the name so in this case both server1.YourVendorDomain.com and server1.mail.YourVendorDomain.com would be allowed to connect to the Domino server. It is important to consider internal inbound connections if you have any other applications or hardware such as a printer or copy machine that may route mail through your Domino server.
In some companies checking outgoing messages is equally important as checking inbound. If you are in the position that you want all outbound mail to be scanned for possible spam by your vendor, you can easily do this by configuring your vendor as an outbound relay server. You will find the
Relay host for messages leaving the local internet domain field in the configuration document for your server,
Router/SMTP →
Basics tab. In figure 2 the relay host is set to Server.YourVendorDomain.com. Note that if you specify an IP address, it must be enclosed in square brackets. Also, only one value is allowed in this field, so use caution when configuring a relay server as a relay server failure will prevent all outbound mail from routing.
Mail routing and multiple directories
When working specifically with mail routing, the topic of multiple directories is frequently brought up. Maybe you need to have secondary directories with customer or vendor contacts for mail addressing. Perhaps your users have been requesting a way to perform address look-ups when disconnected from the server. Possibly you need to prevent the server from searching secondary directories for mail addresses. Domino provides ways to accomplish all of those goals using directory assistance, extended directory catalogs and/or mobile directory catalogs. For more information refer to
3.4 Multiple Directories.
Journaling
Mail journaling allows administrators to keep a copy of specific messages or all messages as they route through the Domino server. This can be important for security or required for companies with pending litigation. Mail journaling is configured with a combination of settings specified in the configuration document and a mail rule. To access mail journaling settings open the configuration document and access the
Router/SMTP →
Advanced →
Journaling tab as shown in figure 3.
Some of the fields are rather self-explanatory while other settings will determine access and usability of the journal. There are two methods available for journaling:
- Copy to local database
- Send to mail-in database
The default method is to
Copy to local database. When this option is selected, data will be automatically encrypted for the user selected in the
Encrypt on behalf of user field except for those fields listed in the
Field encryption exclusion list field.
The second method is to choose
Send to mail-in database. Why might you choose one versus the other? The advantage of using a mail-in database is that multiple servers can journal to the same database. The disadvantage is that as administrator you must manage the encryption and database rollover as this will no longer be done for you.
Unless you have a tool to manage the mail-in database, using the default option of
Copy to local database is recommended.
The database management options are rather straight forward. You can choose to create a new journal based on size or date. By default a new journal will be created each day. At approximately midnight the current mail journal will be renamed to mj
mmddyyyy.nsf, for example mj11302010.nsf. The last field in the Basics section of the journaling tab is
Journal Recipients. Whether or not you enable this setting you will be able to see the original values chosen in the TO, CC and BCC fields for the message. In some cases, this may be a group. By default, you will just see the group name listed in the journal. Who were members of the group? This could change. To ensure you see all of the actual recipients of the message, you will want to set
Journal Recipients to
Enable.
Assuming you have chosen to copy the journaled message to a local database that the server will manage for you, determining if the field encryption exclusion list should be modified and which user should be used for encryption is slightly more complicated. The values you choose will effect what data will be seen by users accessing the journal when not using the ID listed in the Encrypt on behalf of user field and what data can be included in a full text index. A full text index is built by the Domino server, so only data that can be read by the Domino server can be included in the full text index. The following table will help you match your company requirements with the proper journaling configuration.
| Requirements: | Configuration Details: |
Data must be secured with full data access restricted to one or two users. Message subject, body and recipients must be encrypted.
Full text searching of message subject and bodies is not required. | This is the default configuration. To satisfy these requirements, register a new user and specify that user in the field. For example, At fictional Software Company A , they created a user named Mail Journaling/Administration/Company A. This user should then added to the ACL of the mail journal and we suggest that the person document have a readers list to hide this person from the general user population. The id file and password are then shared and accessed only by the users designated at the company with this authority. Based on the default field encryption exclusion list, anyone with reader authority to the journal will only be able to read the date the message was sent and who was the original sender as shown in Figure 4. When the message is opened with the Mail Journaling/Administration/Company A id, the entire message is visible.
Depending on your security requirements you may want to further secure the id used by creating the id in a private organizational unit and only provide password reset authority to those administrators who are authorized to access the mail journal. For more information on using an ID vault refer to ID Vault . |
All users with reader access or above to the mail journal application should be able to view all messages in the journal.
Users who access the journal must be able to perform complete full text searches of subject and body of all e-mails. | In order to satisfy these requirements, the Encrypt on behalf of user field must be blank which will disable encryption. The entire message can now by seen and data access is controlled by the ACL of the mail journal as shown in Figure 5.
 |
All user with reader access or above to the mail journal application should be able to view the date, sender, recipients and subject of all messages in the journal. The message body should remain hidden unless accessed by the appropriate id file.
A full text search must be able to used to search for recipients, senders and subjects. | In order to satisfy these requirements, register a new user and specify that user in the field. For example, At fictional Software Company A, they created a user named Mail Journaling/Administration/Company A. This user should then added to the ACL of the mail journal and we suggest that the person document have a readers list to hide this person from the general user population. The id file and password are then shared and accessed only by the users designated at the company with this authority. The field encryption exclusion list should be modified to include the SendTo, CopyTo, BlindCopyTo and Subject fields. Once done, anyone with reader authority to the journal will only be able to read those new fields as shown in figure 6. When the message is opened with the Mail Journaling/Administration/Company A id, the entire message is visible as shown in figure 6
.
 |
| Mail journaling has been running with encryption. A new requirement or lawsuit requires that certain mail journals be sent for review. Data encryption must now be removed from some journals. | An agent can be used to decrypt the documents in the journal if needed. For details refer to technote 1089495. |
Journaling notes.ini parameters:
Out of Office Notification
Starting with Domino version 8.0, there are two methods of out of office notification within Domino. The first is controlled by an agent and the second it controlled by the router task and has many benefits over the agent. For information on this topic refer to
The IBM Lotus Notes and Domino Out of Office service: Best practices.
Mail routing in a clustered environment
In a clustered environment, when the primary server is down you mostly likely want any mail destined for users on the downed server to be delivered on its cluster mate. There are several configuration pieces that must be in place in order for this to work. First, a replica of each mail file must exist on another server in the cluster.
Second, cluster mail failover must be enabled in the configuration document for all servers in the cluster as well as any Domino server that will be attempting to send mail directly to the server. You can find the cluster failover setting in the
Router/SMTP →
Advanced →
Controls tab. The
Cluster failover setting should be set to
Enabled for last hop only as shown in figure 7. The setting of
Enabled for all transfers in this domain may also be used; however use caution to avoid mail routing loops with this setting. What is the difference? When failover is allowed for all transfers if a hub server is down, mail can be redirected to another hub server. This setting should only be used in enterprise size deployments and as the administrator you should ensure that both servers are able to send the mail to the desired destination to avoid problems with the mail getting stuck on an alternate hub.
The cluster failover parameter was configured via a notes.ini parameter in order releases of Domino. If you have inherited an environment you should ensure that MailClusterFailover is not specified in your notes.ini or is set to 1 to prevent problems with mismatched settings. To see if the setting is currently in use on your server you can use the console command
show config mail* and review the output. MailClusterFailover should not be included in the output just like the example shown in figure 8. If so, you know that the notes.ini setting is being defined manually in the notes.ini or in a configuration document and should be removed.
> show config mail*
MAILSERVER=CN=server1/O=Company A
MAILTYPE=0
Figure 8: Example of show config mail*
The next piece that must be in place for cluster failover to work is that the cluster.ncf must be populated. The
cluster.ncf file is a text file with a list of all known clusters and cluster members. It is populated automatically when it connects with a server that is a member of a cluster. In enterprise size environments the default cache size may be too small and prevent failover, For more information refer to technote
1102957.
The final configuration piece that is required in order for mail cluster failover to work is a fully populated cluster database directory (cldbdir.nsf). The cluster database directory contains a list of all replica databases in the cluster. As an administrator, you can choose to disable cluster replication for a database. If a database has been marked
out of service in the cluster database directory, then cluster failover will not occur. In figure 9 below you can see the mail\utwo.nsf has been disabled on server1.
Lastly, if you cannot determine why the router task is not properly delivery mail to a cluster server, you can enable additional debug logging by setting RouterDebugClusterFailover=1. This setting is dynamic and can be enabled or disabled using the set config command, for example
set config routerdebugclusterfailover=1. For example, here is an example of cluster failover working normally:
- Error connecting to server Server2/Company A: The server is not responding. The server may be down or you may be experiencing network problems. Contact your system administrator if this problem persists.
- Router: Cluster failover starting for server server2/Company A in domain COMPANY A; mail file mail\uthree
- Router: Cluster failover found server server2/Company A in cluster MailCluster
- Router: Cluster failover found server SERVER1/COMPANY A is a cluster mate of server server2/Company A in cluster MailCluster
- Router: Cluster failover found local failover replica mail\uthree.nsf
- Router: Failing over mail transfer from server2/Company A to [$LocalDelivery]; mail file mail\uthree.nsf
- Router: Message 005758B8 delivered to User Three/Company A
When no replica exists or the replica has been marked out of service then the following message will be posted:
- Router: Cluster failover could not find server by Rep ID for Server2/Company A mail/uthree; Unable to find path to server. Check that your network connection is working. If you have a working connection, go to Preferences - Notes Ports and click Trace to debug
Additional Resources
1.6 Expanding the Domino Domain
3.3 Mass Mailings
Message Tracking
Delivered SMTP Messages Appear To Be Intended For Another Address