Automated Processing (Rules) |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
To specify Server-Wide Message (Queue) Rules,
open the Queue pages in the Settings section of the WebAdmin Interface and click the Rules link.
To specify Server-Wide Signal Rules,
open the RealTime pages in the Settings section of the WebAdmin Interface and click the Rules link.
System administrators can specify Account Rules using links on the Account Settings page.
Account users can specify their Rules themselves, using the WebUser Interface. System or Domain administrators can limit the set of Rule actions a user is allowed to specify.
System and Domain Administrators can specify Domain-Wide Rules using the Rules links on the Domain Settings page.
When the list of Rules appears in a browser window, the Rule names and priorities can be modified:
After you have modified the Rule names and/or priorities, click the Update button. The list is displayed re-sorted by priority.
Rules with the disabled priority are not applied to the messages, but they are not deleted from the Account Rules set, and they can be re-enabled at any moment.
To create a new Rule, enter its name in the field on the top and click the Add Rule button.
To remove a Rule, select the checkbox in the Delete column and click the Update button.
To modify the Rule conditions and actions, click the Edit link.
The condition operations is and is not process their parameters as "pictures": the asterisk (*) symbols in parameters are processed as wildcards that match zero or more symbols in the tested string. To check that a string contains the @thatdomain substring, the is *@thatdomain* operation should be used, and to check that a string does not end with the somedomain.com substring, the is not *somedomain.com operation should be used.
The condition operations in and not in process their
parameters as sets of one or more "pictures" separated with the comma (,)
symbols. The tested string is compared to all picture strings. The in
condition is met if the tested string matches at least one picture string.
The not in condition is met if the tested string does not match any
picture string in the specified set.
Note: do not use excessive spaces around the comma signs: spaces before the
comma sign become trailing spaces of the previous picture, and spaces after the
comma sign become leading spaces of the next picture.
The following Rule conditions can be used in message and signal processing Rules:
Time Of Day [is | is not | less than | greater than] time string
A time string should be specified as hh:mm or hh:mm:ss, where hh is the hour, mm - minutes, ss - seconds. Time strings can contain the am or pm suffix.
Sample:
Current Date [is | is not | less than | greater than] date string
A date string should be specified in one of the following formats:
Sample:
Current Day [is | is not | in | not in] day string
Days should be specified either as numbers (0 for Sunday, 6 for Saturday), or as RFC822 abbreviations (Sun, Mon, Tue, Wed, Thu, Fri, Sat).
Sample:
Existing Mailbox [is | is not] string
Sample:
This condition is useful in Domain-Wide Rules: a Rule can check if the current Account has a special Mailbox, and copy certain messages to that Mailbox only if it exists.
For example, the Condition operation
String List subsets can be used as WebUser Interface Address Books.
Rule Action parameters can contain Macro Symbols (^X, where X is a letter). Different sets of Macro Symbols are processed in Signal and Email Rules.
The following Rule actions can be used in message and signal processing Rules:
This action should be used with the NotifyMail® utility installed on client computers.
Users are allowed to specify this action only if they are allowed to specify execute-type actions.
You can configure the Notifier settings using the Obscure page in the Settings WebAdmin realm.
Only the Server Administrator is allowed to specify this action.
If the list already has 500 or more elements, the new element is not added.
When a message is being delivered to any Account by the Local Delivery module, or when a signal targets any Server Account, the "effective" set of Account-level Rules is applied. The first Rules in the effective set are Domain-wide Rules with priorities above 5, then it includes all Account-level Rules, and then - all Domain-wide Rules with priorities equal to or less than 5.
This method guarantees that all Domain-Wide Rules with priorities higher than 5 are applied before any Account Rule. If such a Domain-Wide Rule uses the Stop Processing action, no Account Rules are applied.
Note: Domain-Wide Rules are "mixed" with the Account Rules and are applied in the same environment as the Account Rules, "on behalf" of the Account user.
When you modify the Cluster-wide Rules set on any Cluster Member, the set is automatically updated on all Cluster members.
The effective set of "server-wide" rules for each Cluster member is a union of the Server-Wide Rules explicitly set on that Cluster member and the Cluster-wide Rules.
Rules from both sets are applied together, in the order specified with the Rule priority attribute. For example, messages can be processed with a high-priority Cluster-wide Rule, then with a medium-priority Server-wide Rule, then with a low-priority Cluster-wide Rule.