How Exchange Assistant Rules Work

This technical discussion first appeared on the msexchange discussion list on September 6, 1996. Thanks to Scott Briggs of Microsoft to allowing his explanation to be republished here.

Technically, rules are not profile-specific. The Exchange Server itself has no knowledge of profiles in the client sense. The profile-specific nature of rules is merely the way the Exchange client attempts to perform, in a predictable manner, the client side actions of rules.

A rule is composed of criteria, a set of actions, and a few other assorted flags and properties. When a new message is delivered to an Exchange (Public or Private) Folder, the rules table (contained in the folder) is opened by the server. For each rule in the table (rule order evaluation is based on a sequence number property in each rule) the criteria is evaluated against the properties contained in the message being delivered. If the criteria evaluation results in a "TRUE" expression, then the actions associated with the rule are applied. Some set of actions (zero or more) within the rule can be performed by the server at this time. Some set of actions (zero or more) within the rule cannot be performed by the server. The actions that the server cannot perform, because they require direct client interaction, are stored in a message called a Deferred Action Message (DAM) within a hidden folder called a Deferred Action Folder (DAF).

The DAM created by the Exchange Server contains the information that comprises each action within the rule that could not be executed by the server. For example, the alert action described below, contains a textual stream, i.e. the message displayed in the New Items of Interest dialog. This text is stored within the array of actions in the rule.

When a user creates a rule, but before the rule is saved, the actions in the rule are examined. If any of the actions require client interaction, then the rule is stamped, by the client in a client-specific manner, to indicate the profile used to create the rule.

When the client is logged on to the server it has the opportunity to process DAMs. The Exchange client code examines each DAM in turn and decides if it can be processed based on a property contained within the DAM, from the original rule that the Exchange client stamped, as described above. (From my grammar you now see why I code instead of write for a living).

A flow chart:

1) User creates a rule.

1a) Action 1 is an alert with the text "foobar"

1b) Action 2 is a forward to "John Smith"

2) User saves the rule.

2a) Before the save actually occurs, the client examines each action in the rule. If any require client side support, then the rule is stamped with the ID of the profile that was used to create/modify it. In this case, because of the alert action, this rule is profile-specific (as defined by the Exchange Client).

2b) The rule is then actually saved to the server, which couldn't care less about the property stamped in 2a.

3) A message is now delivered to this folder.

4) The server compares the criteria contained within each rule in the folder, and if a match occurs, then the actions of that rule are triggered.

4a) In this case, the server can perform the forward action independent of the client, and it now does so.

4b) The alert action, however, is not something that the server can do, so it creates a DAM that references the message that triggered the rule and all the actions that it was unable to execute -- in this scenario, only the alert action. Among the properties contained within the DAM is the stamp that the client placed on the rule.

5) The Exchange client notices a DAM in the DAF.

5a) The client checks the "stamp" property on the DAM. If the stamp matches the current profile, then the DAM will be processed and deleted. If the stamp does not match, then the DAM is ignored, and the client await the next DAM to be created by the server.

5b) In this case, the DAM contains the correct "stamp" for the current profile, and the New Items of Interest dialog is displayed.