The Email Rules Protocol enables the client/server interaction that allows a messaging system to implement automatic message processing (message rules (2)). This protocol provides a specific mechanism through which the server and the client can implement a flexible message processing system. Mail delivery is a complex operation that allows the server and the client to implement their own additional processing that is not covered by this protocol.
Rules (2) are sets of conditions and associated actions (2) that enable a user to automatically organize, categorize, and act on messages as the messages are delivered to a folder. Rules can be set on any server folder (either public folders or private folders).
Rule (2) evaluation is triggered when e-mail messages are delivered in a user's mailbox or when messages are first saved to a public folder. The clauses in a condition in a rule (2) are evaluated against the properties of the incoming message. If the condition evaluates to "TRUE", the rule (2) actions (2) are executed either by the server or by the client. If all actions (2) in a rule (2) can be executed by the server, the rule (2) is said to be a server-side rule. If any action (2) cannot be executed by the server (for example, the server doesn't have access to user's personal message store; therefore, it has to defer to the client any action (2) moving messages to a personal message store), the rule (2) has to be executed by the client, and it is said to be a client-side rule.
Server-side rules are handled entirely by the messaging server, independent of the state of the client. Client-side rules do not execute until the client connects to the particular message store on the server. For each message that needs to be acted on by the client as a result of a client-side rule, the server will create a message called Deferred Action Message (DAM) in a special folder called the Deferred Action Folder (DAF) as described in [MS-OXOSFLD].
All enabled rules (2) in a folder are evaluated in sequential order, one by one, until all rules (2) in the rules table for the particular folder have been evaluated. If the conditions of a particular rule (2) are met, its associated set of actions (2) is executed. If a rule (2) is an "exit level" rule (2) (according to a flag in the rule (2) state property) and the rule (2) condition is met, then the evaluation of subsequent rules (2) is canceled. Otherwise, evaluation of the next rule (2) continues even if a rule (2) action (2) moves the message, in which case the remaining rules (2) continue to run against the moved message.
If the rule (2) action is to copy or move a message to a server folder, the server will verify the existence of the destination folder. If the destination folder also has rules (2) (this is not common), the server will evaluate the destination folder rules (2) against the moved message after evaluating the remaining rules (2) in the original folder. If the destination folder does not exist, the server will create a Deferred Error Message (DEM) in the DAF, and the client will display an error when it processes the DEM.
When a folder is deleted, all rules (2) set on that folder are also deleted.
This protocol enables two slightly different types of rules (2): standard rules, which are more commonly used, and extended rules, which provide greater storage capacity, but for performance reasons, the server can choose to limit their usage. The way the two types of rules (2) are created and modified differs, but they are processed identically by the server and by the client.
The following subsections describe the main components covered in this protocol.