Domino 6 server mail rules

Domino 6 server mail rules

by
Mark
Dowdy

Level: All
Works with: Notes/Domino 6
Updated: 03-Feb-2003

In Domino 6, you can incorporate mail rules on the server. This by itself may not seem like very big news; mail rules have been a feature of Domino since R5. However, in R5 mail rules only ran on individual mail files. In Domino 6, mail rules have been enhanced to run on MAIL.BOX and to affect all messages on the server.

This Performance Perspectives column looks at Domino 6 server mail rules and explains how to create them. We'll also discuss how mail rules affect server performance. We assume you're an experienced Domino administrator.

What are mail rules?
Mail rules define actions you want the server to take on certain messages. When a new message meeting a specified condition arrives in MAIL.BOX, the server automatically performs the designated action. For example, you can customize rules to block spam mail or to intercept messages with questionable content. For more information on mail rules, see the Domino 6 Administrator Help.

Mail rules work as follows: Whenever MAIL.BOX receives a new message from the SMTP process, from a Router on another server, or from a client depositing a message, the server evaluates the fields in the message against the registered mail rules. When a message meets a defined condition, Domino takes the specified action with that message.

Note that mail rules (whether server or individual) are not intended to serve as a complete anti-virus solution and should not be considered a replacement for anti-virus software. Although you can configure rules to quarantine messages with known virus attachments, the available rule actions do not include typical anti-virus features, such as generating warnings after detecting a virus or automatically disinfecting files.

Server mail rules are stored in Server Configuration documents. After creating a Configuration document and saving it, click on these tabs: Router/SMTP - Restrictions and Controls - Rules. In Domino 6, you can create up to 100 rules for your server.

Each rule consists of two components:

The conditions that need to be met
The actions you want to take with the message if the conditions are met

Both are described in the following sections.

Conditions
There are three parts to a condition:

The message item to examine. This is the particular field you want to specify—From, Subject, Body, and so on.
Logical operator or qualifier. This can be:
contains <text>and does not contain <text>
is and is not
is less than <number> and is greater than <number>
Value to check. This identifies the content to search for in the message item. Note that wildcard characters such as asterisks (*) are not allowed. Examples of values include "VBS", "Fun Love", "EXE", or "discount offer."

You can have multiple conditions connected with Boolean operators (AND and OR) to form a logical expression.

Actions
The following actions are available:

Journal this message. This action copies the message to a journaling database and then delivers the message as normal. Note that journaling must be enabled on the Router/SMTP - Advanced - Journaling tab.
Move to database. This action moves the message to a different database that you specify (for example, an archive or quarantine database).
Don't accept message.
Don't deliver message.
Change routing state.

The following screen shows the options available when creating a mail rule.

Edit Rule dialog box

How do mail rules affect server performance?
In our tests, we used a Netfinity box with four 700 MHz Xeon processors and 2 GB of memory, running Windows 2000. For storage, we used an IBM EXP200 array, configured for RAID0, for the data files.

We ran a workload simulating 3,000 Notes 6 mail users. We reran the test with more rules added each time. To produce a worst-case scenario, we had each rule's condition check for a string in the subject line of the message that did not exist ("fooxx"). We specified 10 different conditions for each mail rule, so the server looked for 10 unique strings in each rule each time. The conditions were all tied together with logical ORs to ensure that each was evaluated each time. In our final test, we used a set of 10 rules, each with 10 conditions. But this time we checked the body of the message—the body of a message is much larger (10 KB) than the subject lines, so the performance hit is typically much higher.

There was no significant increase in the memory footprint of the server when running these tests, so it was not included. Every mail message was delivered in each test run, so the router CPU remained fairly constant. Therefore, we also excluded this data.

The major platform statistics for which we observed significant variation were total CPU utilization percentage and server task CPU percentage. (The server task runs the rules.)

The following table shows total CPU percentage and server CPU percentage.

	Total CPU usage (percent)	Server task CPU usage (percent)
Baseline and all runs with 3,000 Notes 6 mail users	15	8
Test 1: 10 rules each with 10 conditions - 100 unique strings searched for in the Subject field	15	8
Test 2: 25 rules each with 10 conditions - 250 unique strings searched for in the Subject field	16	10
Test 3: 50 rules each with 10 conditions - 500 unique strings searched for in the Subject field	32	28
Test 4: 10 rules each with 10 conditions - 100 unique strings searched for in the Body field	47	38

The following chart shows this CPU usage data in graphic form:

Effects of server rules on CPU utilization

In conclusion...
From our tests, we derived the following practices to help improve the performance of server rules:

Check the logic of your ANDs and ORs, or you will not test for what you may think you are testing.
Move the most common words or phrases to the beginning of your conditions list. For some formulas, the sooner the logic is successful, the less CPU is used because the searching stops once the correct set of conditions is met.
Move the most used rules to the top of the Configuration documents list. The rules are evaluated in the order in which they are listed. There are arrows to change the rules sequence. (Note that all rules are evaluated with one exception—when a delete [or don't accept message] action is encountered. This stops processing of remaining rules.)
Don't include words that are uncommon. If only one user complains that a particular word needs to be added to the list, set up a rule in the user's personal mail file to search only messages sent to that user, instead of every mail message going to the server.
Don't search the body of the message unless it is really needed. Searching the body has the most impact on your CPU utilization.

We hope you found this column helpful—let us know if you'd like more information about mail rules.

ABOUT THE AUTHOR
Mark Dowdy joined IBM/Lotus in 1994, performing backend automation for the Domino server and programmability teams. He joined the Domino Performance team in 1999, testing Domino applications. Mark is currently working on the next generation of Lotus J2EE products.