Automated Rules

The CommuniGate Pro Server can automatically process E-mail 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 E-mail Messages and to all Signals sent to the 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, use the WebAdmin Interface to open the Mail pages in the Settings realm, and click the Rules link.
To specify Server-Wide Signal Rules, use the WebAdmin Interface to open the Real-Time pages in the Settings realm, and click the Rules link.

System and Domain 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:

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 Inactive priority are not applied, but they are not deleted from the Rule 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 an E-mail Message or a Signal 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 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 both E-Mail Queue and Signal processing Rules:

Submit Address [is | is not | in | not in] string
This condition checks the E-mail or Signal submit address.
If the Message or Signal was generated within the Server itself, its submit address is empty.
Otherwise the "submit address" string contains the name of the component that received or generated the E-mail Message or Signal, and (separated with a space symbol) the network (IP) address the E-mail or Signal came from, optionally followed with the IP port number (separated with a colon symbol).
If the Message or Signal was generated locally, with an internal Server component (such as Rules), the network address field contains [0.0.0.0].
Sample (Queue Rule):

Sample (Signal Rule):

Time Of Day [is | is not | less than | greater than | in | not in] time string
This condition checks the current time of day in the user's time zone (for the Account-level Rules) or in the Server Time Zone (for the system-wide Rules).

This condition allows you to compose rules that are applied 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.

If the condition is in or not in, then the parameter string should contain a pair of time strings, separated with the minus (-) symbol.
If the second time value is not smaller than the first one (as in 08:30-5:15pm), the in condition is met at any time after 8:30 and before 17:15.
If the second time value is smaller than the first one (as in 22:30-5:15), the in condition is met at any time after 22:30 and at any time before 5:15.

Sample (Queue Rule):

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 or Signals only before or after the specified date and time.

To compare dates only, specify the date string in the following format:

  • DD MMM YYYY

To compare date and time, specify the date string using one of the following formats:

  • DD MMM YYYY hh:mm
  • DD MMM YYYY hh:mm:ss
  • DD MMM YYYY hh:mm:ss +ZZZZ
  • DD MMM YYYY hh:mm:ss -ZZZZ
where:
DD is the day of month
MMM is month specified as a 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 user-specified time zone is used for the Account-level Rules and the Server time zone is used for the Server-wide and Cluster-wide Rules.
Sample:

Current Day [is | is not | in | not in] day string
This condition checks the current day of week. It allows you to compose rules that are applied to Messages or Signals only on certain days of week.
Days should be specified either as numbers (0 for Sunday, 6 for Saturday), or as RFC822 abbreviations (Mon, Tue, Wed, Thu, Fri, Sat, Sun).
Sample:

Preference [is | is not | in | not in] string
The string must contain the Account Preference name and the preference data picture, separated with the colon (:) symbol. This condition compares the specified Account Preference value with the data picture.
Sample:

FreeBusy [is | is not | in | not in] status string
This condition should not be used in the Server-wide or Cluster-wide Rule. The condition retrieves the Account Free-Busy data and retrieves the status value for the current time. This status value is compared to the specified status string.
Sample:

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.
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.

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:
  • The Rule is an Account-level (or a Domain-wide) one.
  • The condition operation is in or not in.
  • The operation parameter is specified as a string.
  • The operation parameter starts with the hash (#) symbol.
For example, the Condition operation
Sender    in    #Blocked
checks if the E-mail Message or Signal sender's address is included into the String List called Blocked.

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


Rule Actions

Each Rule can have zero, one, or several actions. If an E-mail Message or Signal meets all the Rule conditions, the Rule actions are performed.

Rule Action parameters can contain Macro symbol combinations (^X, where X is a letter).
Different sets of Macro symbol combinations are processed
See the Signal Rules and E-mail Rules sections to learn about the Macro symbol combinations available.

The following Rule actions can be used in all Message and Signal processing Rules:

Reject errorMessage
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 the specified error code.
If a Rule is an E-mail 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 report text.
E-mail processing Rules can still store rejected Messages using the Store action before the Reject action.
Sample:

SendURL URL (Execute URL URL)
An HTTP 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.
When the URL parameter is processed using Macro Substitution, the calculated values are URL-encoded first.
Sample:

Send IM messageText
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-wide Rules).
Sample:

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 can be used with the Finger-based utilities (such as NotifyMail®) installed on client computers.
Sample:

Users are allowed to specify this action only if they are allowed to specify execute-type actions.

System Administrators can use the WebAdmin Interface to configure the Notifier settings.

Open the General pages in the Settings realm, and find the Notifier panel on the Others page.

Write To Log recordText
A Major-Level (Level 2) record with the Message or Signal ID and the specified recordText string is placed into the System Log.
Only the Server Administrator is allowed to specify this action.
Remember 'From' in stringList
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 or Signal sender (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.