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:
Notifier
Log Level:
Queue Size:
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.
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.
