Automated Processing (Rules)

The CommuniGate Pro Server can automatically process messages and signals using sets of Automated Rules.

The Server-wide and Cluster-wide sets of Automated Rules are applied to all messages and to all signals transferred via the Server or the Cluster.

The Account-level sets of Automated Rules are applied to all messages and to all signals sent to a particular Server Account.

Each Rule in a set has a name, a priority, a set of conditions, and a set of "actions". The higher priority Rules are checked first: a Rule with the priority level of 9 is applied before a Rule with the priority level 1.

If a message or a signal meets all Rule conditions, the Rule actions are performed, and automated processing either stops, or proceeds checking other, lower-priority Rules.

Specifying Rules

System administrators can specify Server-Wide and Cluster-Wide 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.

Creating, Renaming and Removing Rules

When the list of Rules appears in a browser window, the Rule names and priorities can be modified:

Priority Name Edit Delete

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.

Rule Conditions

Each Rule can have zero, one, or several conditions. The conditions are checked in the same order they are specified. If a message meets all the Rule conditions, the Rule actions are performed.

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 substring, the is not * 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
This condition checks the current time of day in the Server time zone. This condition allows you to compose rules that are applied to messages only at certain times of day.

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.


Current Date   [is | is not | less than | greater than]  date string
This condition checks the current time and date. This condition allows you to compose rules that are applied to messages only before or after the specified date and time.

A date string should be specified in one of the following formats:

  • DD MM YYYY hh:mm
  • DD MM YYYY hh:mm:ss
  • DD MM YYYY hh:mm:ss +ZZZZ
  • DD MM YYYY hh:mm:ss -ZZZZ
DD is the day of month
MM is month specified as 3-letter English abbreviation:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
YYYY is the year
hh is the hour
mm is the minute
ss is the second
+ZZZZ or -ZZZZ is the time zone; if the time zone is not specified, the Server time zone is used.


Current Day   [is | is not | in | not in]  day string
This condition checks the current day of week (using the Server local time zone). This condition allows you to compose rules that are applied to messages only on certain days of week.

Days should be specified either as numbers (0 for Sunday, 6 for Saturday), or as RFC822 abbreviations (Sun, Mon, Tue, Wed, Thu, Fri, Sat).


Existing Mailbox [is | is not]  string
The parameter specifies a mailbox name, and this condition checks if the specified Mailbox exists (or if it does not exist). A Mailbox "exists" if it is possible to open the Mailbox with the specified name and to add a message to it. If this condition is used in an Account-level Rule and the parameter specifies a Mailbox in a different Account, and that Mailbox exists, but the current user cannot add a message to it, the Mailbox is treated as one that "does not exist" for this Rule condition.


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.

String Lists

The CommuniGate Pro Server can store named lists of strings as the Account DataSet subsets. Each list can contain zero, one, or several strings. The Rule Condition operations can refer to those lists, if:

For example, the Condition operation

Sender    in    #BlockedSenders
checks if the message sender's address is included into the String List called BlockedSenders.

String List subsets can be used as WebUser Interface Address Books.

Rule Actions

Each Rule can have zero, one, or several actions. If a message meets all the Rule conditions, the Rule actions are performed.

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:

Stop Processing
This action should be the last one in a Rule. Execution of this Rule stops and no other (lower-priority) Rules are checked for that message. The message is stored in the INBOX.

Reject [error message text]
This action should be the last one in a Rule. Execution of this Rule stops and no other (lower-priority) Rules are checked.
If a Rule is a Signal processing one, the signal is rejected with an error code.
If a Rule is an Email processing one, the message is rejected, and a negative Delivery Notification is sent back to the message sender.
If the action parameter text is not empty, it is used as the error message text.
You can still store the rejected message using the Store action before the Reject action.
IF Subject is *UCE*
Reject   please do not send such messages here

A connection is made to the remote Web server specified in the URL, and an HTTP GET request with the specified URL is sent to that server. If any response is received, the response is discarded. If no response is received within 10 seconds, the HTTP connection is closed.

SendIM [message text]
An Instant message with the specified message text is sent.
If the message text starts with the
To: user@domain
line, then the Instant Message is sent to the specified address. Otherwise, the message is sent to the current Account (for Account-level Rules), or it is not sent at all (for Server-wide/Cluster Rules).

FingerNotify [ address ]
The Server connects to the computer at the specified network address, port 79 (the finger port), and sends the nm_notifyuser string to that computer. If the address is not specified, and the action is executed as a part of an Account-Level Rule, the network address of the last user Login is used.

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.

Write To Log string
A Major-Level (Level 2) record with the message ID and the specified string is placed into the System Log.

Only the Server Administrator is allowed to specify this action.

Remember 'From' in string
This action can be used in Account-Level Rules only. The operation parameter specifies the name of a string list that exists in or should be created in the Account dataset. The message author (From) address is added to the specified list.

If the list already has 500 or more elements, the new element is not added.

Domain-Wide Rules

Domain Administrators can specify Domain-wide Rules.

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.

Cluster-Wide Rules

The Dynamic Cluster Administrators can see an additional link on the Rules pages of the WebAdmin Interface. This link can be used to open the list of Cluster-wide Rules.

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.

CommuniGate® Pro Guide. Copyright © 1998-2006, Stalker Software, Inc.