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.
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.
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):
-
If the Account-level Rule condition is is, is not, in, or not in
the work string can be used as time string.
If the current day of week is included into the "working days" set and the current time of day is inside the "working hours" range
specified for this Account, then the is and in conditions are met.
Otherwise, the is not and not in conditions are met.
- 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:
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.
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.
The CommuniGate Pro Server can use Group object contents as the list of addresses.
The Rule Condition operations can refer to contents of those groups if:
- The condition operation is in or not in.
- The operation parameter is specified as a groupname.
- The operation parameter starts with the dollar sign ($) symbol.
For example, the Condition operations:
- Sender in $sales
checks if the sender's address of the Message or Signal is contained in a Group named sales. If the group name is specified without a domain part, the contents of the group with that name are used in the domain for which the User-Level Rule is applied or is Common to the Domain.
- From not in $group1,$group2
checks if the sender's address is not contained in one of the Groups group1 or group2.
- ReplyTo in user@domain,$group1,$group2
checks if the reply address is contained in Groups group1 or group2 or if it is the User user@domain. The following examples work similarly.
- To not in user@domain,$group1@alias,$group2@domain
- Cc in $group2@domain,user@domain,$group1@alias
Only "From" and "To" are available for the Signal.
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 fails with the specified error code.
If there are Signal Rules for the "Failure" condition, those Rules are applied, otherwise the the Signal is rejected immediately.
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:
-
- Send Push messageText
- A Push message with the specified text is sent.
- Sample:
-
- 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 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.
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.
|
