Automated Mail Processing (Rules)

Specifying Rules Creating, Renaming and Removing Rules Rule Conditions String Lists Rule Actions Vacation Message Redirect All Simplified Rule Logging Rules Activity Domain-wide Rules Cluster-wide Rules The CommuniGate Pro server can automatically process messages using several sets of Automated Rules. The Server-Wide Rules are applied to all messages submitted to the server. These Rules are applied by the Enqueuer kernel component, before it enqueues a message into the transfer module queue(s). When a message is directed to an Account on the CommuniGate Pro Server, the Local Delivery module applies the Rules specified for the Domain the Account belongs to and then the Rules specified for that Account. Each Rule has a name, 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 meets all Rule conditions, the Rule actions are performed, and automated processing either stops, or proceeds checking other, lower-priority Rules.

Specifying Rules

The System administrator can specify Server-Wide Rules using the Rules Settings page.

The System administrator can specify Account Rules using a link on the Account Settings page.

Account users can specify their Rules themselves, using the WebUser Interface. The System or Domain administrator can limit the set of Rule actions a user is allowed to specify.

The System and Domain Administrators can specify Domain-Wide Rules using the Rules link 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 disabled12345678910 Edit disabled12345678910 Edit disabled12345678910 Edit

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 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 are implemented:

From  [is | is not | in | not in]  string

This condition checks that the message From address is (or is not) equal to the specified string.

Sample:

From is

This condition will be met for all messages coming from any account on any of stalker.com subdomains.

Sender    [is | is not | in | not in]  string

To        [is | is not | in | not in]  string

Cc        [is | is not | in | not in]  string

Reply-To  [is | is not | in | not in]  string

The same as above, but the message Sender, Reply-To, To, or Cc address is checked.

If a message has several addresses of the given type, the condition is met if it is true for at least one address. If a message has no addresses of the specified type, the condition is not met.

Any To or Cc  [is | is not | in | not in]  string

The same as above, but all message To AND Cc addresses are checked. If the message has no To/Cc addresses, the condition is not met.

Each To or Cc  [is | is not | in | not in]  string

All message To AND Cc addresses are checked. The condition is met if it is true for each To and Cc address of the message, or if the message has no To/Cc addresses.

Sample:

Each To or Cc in

This condition will be met for messages where all To and CC addresses are addresses in the mycompany.com domain or addresses in the mydept.mycompany.com domain.

Return-Path  [is | is not | in | not in]  string

This condition compares the message "Return-Path" (a.k.a. MAIL FROM) envelope address with the specified string.

'From' Name  [is | is not | in | not in]  string

The same as above, but the instead of the address, the "address comment" (the real name) included in the From address is checked.

Sample:

'From' Name is

This condition will be met for messages with the following From: addresses:

From: jsmith@company.com (John J. Smith)

From: "Bill J. Smith" b.smith@othercompany.com

From: Susan J. Smith <susan@thirdcompany.com>

Subject  [is | is not | in | not in]  string

This condition checks if the message subject is (or is not) equal to the specified string.

Sample:

Subject is

This condition will be met for messages with the following Subject fields:

Subject: we urgently need your assistance

Subject: Urgent!

Message-ID  [is | is not | in | not in]  string

This condition checks if the message ID is (or is not) equal to the specified string.

Sample:

Message-ID is not

This condition will be met for all messages without the Message-ID flag and for messages that have Message-ID without the @ sign.

Message Size  [is | is not | less than | greater than]  number

This condition checks if the message size is less than (or greater than) the specified number of bytes.

Sample:

Message Size greater than

This condition will be met for messages larger than 100 kilobytes.

Human Generated

This condition checks if the message is not generated by some automatic message generating software.
Note: this condition has no parameters, so the operation code and the parameter value (if any) are ignored.

It actually checks that the message header does not contain any of the following fields:

Precedence: bulk

Precedence: junk

Precedence: list

X-List*

X-Mirror*

X-Auto*

X-Mailing-List

This condition also checks that the message has a non-empty Return-Path.

Header Field  [is | is not | in | not in]  string

This condition checks if the message RFC822 header contains (or does not contain) the specified header field. The additional fields added using the Add Header operation (see below) are checked, too.

Sample:

Header Field is not

Any Recipient  [is | is not | in | not in]  string

This condition compares message "Envelope" addresses and the specified string. If this condition is used in an Account-Level Rule, only the addresses routed to that account are checked.

The addresses are processed in the form they had before the Router Table and other routing methods have modified them. If an account has several aliases, this condition allows you to check if a message was sent to a specific account alias.

Messages can be submitted to the server using the ESMTP ORCPT parameter. This parameter specifies how the address was composed on the sending server, before the relaying/forwarding server has converted it to a different address. In this (rare) case, that server can use the ESMTP ORCPT parameter to specify the original address.

Sample:

• a message was composed somewhere and sent to the address user1@domain1.com;
• the domain1.com server received the message and converted that envelope address to user2@domain2.com (mail forwarding);
• the domain1.com server relayed the message to your CommuniGate Pro server domain2.com;
• the domain2.com CommuniGate Pro server received a message;
• the domain2.com CommuniGate Pro server found that the user2 is an alias of the user3 account, and the server routed the message to that user3 account.

If the domain1.com server is an advanced server and informed the domain2.com CommuniGate Pro server that the original address was user1@domain1.com, the string <user1@domain1.com> is used when the Recipient condition is checked.

If the domain1.com server has not informed your server about the original address, the <user2@domain2.com> string is used when the Recipient condition is checked.

The condition is met if it is met for at least one envelope address.

Each Recipient  [is | is not | in | not in]  string

The same as above, but the condition is met only if it is met for all message envelope addresses (if used in an Account-Level Rule - for all message addresses routed to that account).

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.

Sample:

Time Of Day is greateris less Time Of Day is greateris less

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

where:

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.

Sample:

Current Date is greateris less Current Date is greateris less

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

Sample:

Current Day isin

Source [is | is not | in | not in]  string

This condition checks if the message was received from a "trusted" source (via SMTP from a computer with the network address listed in the Client IP Addresses list), or from an "authenticated" source (via SMTP, WebUser, MAPI, POP XMIT, Rules - when the originator of the message is verified and authenticated).

Sample:

Source isis notinnot in

Submit Address [is | is not | in | not in]  string

This condition checks the message submit address. If the message was generated within the Server (by a Rule, etc.), its submit address is empty. Otherwise it contains the name of the component that received or generated the message and (separated with a space symbol) the network (IP) address the message came from.

Sample:

Submit Address isis notinnot in

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 a mailbox with the specified name and 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 "does not exist" for this condition.

Sample:

Existing Mailbox isis not

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 following conditions can be used in Server-Wide Rules only:

Any Route  [is | is not | in | not in]  string

This condition checks a message "Envelope Recipient" address - the address actually telling the Server were to transfer the message to. The condition compares the routing information string for a recipient address and the specified string.

The condition is met if it is met for at least one envelope recipient address.

The message address routing information is presented in the following format:

module(queue)address

where module is the name of the module the address is routed to, queue is the name of the module queue the address is routed to, and address is the address in that queue.
For example, the envelope recipient user@domain address can be routed to:

SMTP(domain)user@domain		if domain is a remote domain
LOCAL(user)		if domain is the Main Domain
LOCAL(user@domain)		if domain is a secondary CommuniGate Pro Domain

If you plan to use this type of Rule condition, use the Test button on the WebAdmin Interface Router page to see how various addresses are routed.

Each Route  [is | is not | in | not in]  string

The same as above, but the condition is met only if it is met for all message envelope addresses.

String Lists

The CommuniGate Pro Server can store named lists of strings in the Account datasets. 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 (#) sign.

For example, the Condition operation

Sender    in    #BlockedSenders

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

Rule Actions

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

The following Rule actions are implemented:

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.
 

Discard

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 not stored in the INBOX, but the positive Delivery Notification is sent back to the message sender (if requested).

Sample:

IF From is *that_annoying_guy@*
THEN
Discard

 

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 for that message. 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.

Sample:

IF Subject is *UCE*
THEN
Reject   please do not send such messages here

 

Mark operation [, operation...]

This action sets or resets the specified flag(s) for the message. Initially, the set of message flags is empty.

• The Read operation adds the Read (Seen) flag to the message flag set, the Unread operation removes the Read (Seen) flag.
• The Flagged operation adds the Flagged flag to the message flag set, the Unflagged operation removes this flag.
• The Answered operation adds the Answered flag to the message flag set, the Unanswered operation removes this flag.
• The Deleted operation adds the Deleted flag to the message flag set, the Undeleted operation removes this flag.
• The Redirected operation adds the Redirected flag to the message flag set.
• The Draft operation adds the Draft flag to the message flag set.
• The Hidden operation adds the Hidden flag to the message flag set.

When a message is stored in a mailbox as a result of the Store in action, as well as when a message is stored in the INBOX after all Rules are applied, the message is stored with the specified flag set.

Sample:

IF Sender is *list*
THEN
Mark Flagged

 

Add Header header fields

This action adds RFC822 header fields to the message. Initially, the set of additional message header field contains the Return-Path field generated using the return-path in the message envelope.
When a message is stored in a mailbox as a result of the Store in action, as well as when a message is stored in the INBOX after all Rules are applied, the message is stored with the additional header fields.

Sample:

IF Subject is *purchase*order*
THEN
Add Header X-Special-Processing: order

The Add Header action can be used to add an X-Color field. This field is detected by the WebUser Interface and is used to highlight a message in the mailbox:

Sample:

IF Header Field is X-Spam: *
THEN
Add Header X-Color: red

Note: the following actions are not implicit "Discard" actions, and they do not prevent the original message from being stored in the INBOX. If you want, for example, to redirect a message without keeping a copy in your INBOX, specify the Redirect action followed with the Discard action.

Store in mailbox name

The message is copied to the specified mailbox in your account. The mailbox should already exist.
If the mailbox name is specified as ~user_name/mailbox_name, the message is stored in the mailbox_name mailbox in the user_name account.
You should have the Insert access right to that mailbox.

Sample:

IF Subject is *Make*$*
THEN
Store in ~postmaster/abuse
Discard

If the specified mailbox cannot be opened or the message cannot be stored in that mailbox, the Rules processing stops (as if the Stop Processing action was used).

Redirect to addresses

The message is redirected to one or several specified E-mail addresses. If several addresses are specified, they should be separated with the comma (,) sign.
The specified addresses replace the message To/Cc header fields, unless these specified addresses are prefixed with the [bcc] string;
The redirected message Return-Path is set to the E-mail address of the current Account, or to the MAILER-DAEMON address if the action is used in a Server-wide or a Cluster-wide Rule. The same address is added to the message header as the Sender field.
A Return-Path header field (if any) is changed to the X-Original-Return-Path field.
Return-Receipt-To and the Errors-To fields are removed.
Message-ID, Date, and Sender fields (if any) are renamed into X-Original-Message-ID, X-Original-Date, and X-Original-Sender.
New Date and Message-ID fields are created.

Forward to addresses

The message is forwarded to the specified addresses. Same as the Redirect operation, but the new Return-Path address is not stored as the Sender field. Instead it is used as a new From address.
The old From field is renamed into X-Original-From field.

Mirror to addresses

The message is mirrored (redirected) to the specified addresses (with minimal header changes).
The redirected message Return-Path is preserved.
A Resent-From header field is added. It contains the E-mail address of the current Account (without its Real Name), or the MAILER-DAEMON address if the action is used in a Server-wide or a Cluster-wide Rule.
A Return-Path header field (if any) is changed to the X-Original-Return-Path field.
Return-Receipt-To and the Errors-To fields are removed.

Reply with message text

The specified text is used to compose a reply message. The reply is sent to the address specified in the Reply-To address of the original message. If the Reply-To header is absent, the reply is sent to the original message From address.

The header fields Subject: Re: original message subject and In-Reply-To: original message-ID are added to the reply message.

The specified message text can contain macro symbols that are substituted with actual data when a reply message is composed:

^S is substituted with the Subject of the original message (in its original form)

^s is substituted with the Subject of the original message (in the MIME-decoded form)

^F is substituted with the From address of the original message (in its original form)

^f is substituted with the From address of the original message (in the MIME-decoded form)

^T is substituted with the Date field of the original message

^I is substituted with the Message-ID field of the original message

^R is substituted with the To field of the original message (in the MIME-decoded form)

Sample:

Reply with

Dear ^F! We got your message ^I on ^T. It will be processed shortly and you will be contacted within 1-2 days. Respectfully, Human Resources.

If the specified text starts with the '+' sign, the lines following this sign are added to the message header. The text should specify the Subject field, since the system will not automatically add the Subject: Re: original subject and In-Reply-To: original message-ID fields into the reply message.

The specified header portion can contain additional To, Cc, and Bcc fields and the reply message will be sent to those addresses (the Bcc fields will be removed from the message header).

If the specified header does not contain the From field, the account address is added as the From field. If the From field is specified, the account address is added as the Sender field.

The ^S and other macro symbols can be used in the additional header fields, too.

An empty line should separate the message body from the additional header fields:

Reply with

+Reply-To: special@mycompany.com Subject: your message about ^S X-URL-Ref: http://www.mycompany.com Bcc: statistics@mycompany.com Dear ^F! We got your message ^I on ^T. It will be processed shortly and you will be contacted within 1-2 days. Respectfully, Human Resources.

If the specified text starts with the [charsetName] string, the text is converted to the specified charset (all non-ASCII texts are stored in the UTF-8 charset).

If the text does not start with the '+' sign, the header fields

MIME-Version: 1.0
Content-Type: text/plain; charset=charsetName

are added to the message headers.

If the text starts with the '+' sign, the '+' sign must be specified after the [charsetName] string, and you should specify the MIME-Version and Content-type fields yourself.

Reply to All with message text

The same as above, but the reply is sent to all addresses listed in the original message To: and Cc: fields.

React with message text

The specified message text should contain a header, an empty line, and the message body. The header should contain any number of To, Cc, and Bcc fields, the Subject field, as well as any number of additional fields. The composed message is sent to the specified addresses. The system uses the account address to compose the From field for these reaction messages.

If the specified header already contains the From field, the account address is added as the Sender field.

The specified message header and the message body can contain macro symbols listed above.

Sample:

React with

To: 123456@pager.mycompany.com (my pager) Cc: myhome@provider.com (my Home Account) FYI: message ^I was received from ^F. Its Subject was: ^S

The message text can start with the [charsetName] string (see above), in this case you need to specify the MIME-Version and the Content-Type header fields:

Sample:

React with

[ISO-8859-1]To: myhome@provider.com (my Home Account) MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Nachricht ^I wurde empfangen von ^F Das Betreff war: ^S

Execute command line

The specified command is executed in a separate OS process (task).

The message text (the header and the body) is sent to the task as that task standard input (stdin).
Note: the task must read the entire stdin data stream, otherwise the Execute command fails.

A command text can be prefixed with the [FILE] tag:

[FILE] myprogram parm1

When this prefix is used, the task standard input will be empty (closed) or it will contain only the message header fields added by previous Rules. The string

-f Queue/fileid.msg

(the -f flag and the Message file name, relative to the base directory) will be appended to the end of the command text:

-f Queue/12002345.msg

Note: usually access to the base directory is not granted to regular users, so the [FILE] prefix can be used in the Server-Wide Rules only.

A command text can be prefixed with the [RETPATH] tag:

[RETPATH] myprogram parm1

When this prefix is specified, the string "-p" followed by the message return-path address is added to the end of the command text:

-p address@domain.com

A command text can be prefixed with the [RCPT] tag:

[RCPT] myprogram parm1

When this prefix is specified the string "-r" followed by the list of message recipient addresses is added to the end of the command text:

-r address1@domain1.com address2@domain2.com

In an Account-Level Rule, a command text can be prefixed with the [ACCNT] tag:

[ACCNT] myprogram parm1

When this prefix is specified the string "-u" followed by the Account name is added to the command text:

-u accountName@domainName

A command text can be prefixed with the [ORCPT] tag:

[ORCPT] myprogram parm1

When this prefix is specified the string "-r" followed by the list of message recipient addresses is added to the end of the command text. If a recipient address was submitted together with its "original recipient" parameter (the ESMTP ORCPT parameter), the original address is used.

-r origAddress1@domain1.com origAddress2@domain2.com

Note: the [RCPT] and [ORCPT] prefices cannot be used together.

A command text can be prefixed with the [STDERR] tag (see below).

A command text can have several prefix strings, and they can be specified in any order. If several of [FILE], [RETPATH], and [RCPT] prefix strings are specified, the -f flag and its parameter are added first, followed with the -p flag and its parameter, followed with the -r flag and its parameters.

When the task completes, the task exit code is checked. If the code is zero, the Rule action is considered as executed successfully, and the next Rule action is executed.

If the task exit code is non-zero, the message is rejected with the error code "automated processing failed", and the data from the task standard error channel is recorded in the Log along with the task exit code.
If the [STDERR] prefix was specified on the command line, the data written to the standard error channel (if any) is used to compose the error report text.

The data from the task standard output, if any, should not exceed 4Kbytes in size. It is recorded in the Log and discarded.

The CommuniGate Pro Server monitors the task during its execution, and it interrupts the task if it does not complete within 2 minutes.

When a task is to be executed as a part of Account-Level Rule processing, the OS User Name is composed using the Account OS User Name setting, and the task is executed in that OS User Environment.

When the CommuniGate Pro runs under control of a Unix system, the task is assigned the specified Unix User ID, group ID, and the set of groups; the task current directory is set to the Unix User home directory.

The Execute action cannot be used in Account-Level Rules if the CommuniGate Pro Server runs under MS Windows, AS/400, or BeOS operating systems.

When a task is to be executed as a part of a Server-Wide Rule, it is launched in the CommuniGate Pro Server own environment (with the base directory being the current directory).

Sample:

Execute

myscript --myoption -f requests/archive

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.

Sample:

FingerNotify

206.40.74.198

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.

ExternalFilter

This action tells the Server to pass the message to an External Filter program. This action can be specified only in the Server-Wide Rules. The parameter specifies the name of the External Filter program to use.

Sample:

ExternalFilter

McAfee

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.

Accept Request options

This action can be used to accept Calendaring Meeting Requests automatically. It can be used in Account-Level Rules only. See the Calendaring section for more details.

Vacation Message

Each Account has one built-in Rule to generate Vacation messages. When enabled, the Rule checks that the message is not an auto-generated one, and that the message author (the 'From' address) has not be placed into the RepliedAddresses string list. It then composes and sends an Vacation message and adds the message author address into the RepliedAddresses string list, so the Vacation message will be sent to each message author only once.

This Rule conditions are:

Human Generated
From             not in    #RepliedAddresses

The Rule actions are:

Reply with            Reply Text
Remember 'From' in    RepliedAddresses

Only the text of the Reply message can be modified:

Vacation Message
Dear ^F! I'm on vacation right now, please contact me after 10-Jul-2003. Sincerely, Me.

Vacation Message

If this option is not selected the Vacation Message Rule is disabled. If this option is selected, the Vacation Message Rule is enabled with a low priority (the rule priority is set to 2).

Even if the Administrator has not allowed the user to specify Automated Rules, the Vacation Message can be enabled by the user herself, and the user can always modify the Vacation Message text.

If "Clear 'Replied Addresses' List" button is clicked, the RepliedAddresses string list is removed from the Account dataset. Alternatively, the Enable Vacation Message button can be present. It enables the Vacation Rule and clears the Replied Addresses list at the same time.

Redirect All Simplified Rule

Each Account can have a simplified rule to redirect all incoming mail to a different address or addresses.

This Rule condition is either empty (the Rule action is applied to all messages) or, optionally, human generated, the Rule actions are Redirect To or Mirror To, and, optionally, Discard.

Only the list of redirection addresses can be modified:

Redirect All Mail to:
myothername@other.provider.com, thirdName@third.provider.net Keep a Copy Do not Redirect Automatic Messages Preserve To/Cc fields

Redirect All Mail to

If this option is not selected the Redirect All Rule is disabled. If this option is selected, the Redirect All Rule is enabled with the lowest priority (the rule priority is set to 1).

Keep a Copy

If this option is not selected, the action Discard is added to the Rule and all redirected messages are NOT stored in the account INBOX.

Do not Redirect Automatic Messages

If this option is selected, the condition Human Generated is added to the Rule and messages from non-human sources (mailing list messages, error messages, redirected and mirrored messages) are not processed with this Rule.

Preserve To/Cc fields

If this option is selected, the Mirror To action is used for this Rule. If this option is not selected, the Redirect To action is used.

The account user can set this Rule only if the Account is granted a right to specify the redirecting Rule actions. Otherwise only the Administrator can set this Rule for the user account.

Logging Rules Activity

The Enqueuer component records Server-Wide Rules activity in the Log. Set the Enqueuer Log Level to Low-Level or All Info to see the Rules checked and the actions executed.

The Local Delivery module records Domain-Wide and Account-Level Rules activity in the Log. Set the Local Delivery module Log Level to Low-Level or All Info to see the Rules checked and the actions executed.

Domain-Wide Rules

Domain Administrators can specify Domain-wide Rules. When a message is being delivered to any Account by the Local Delivery module, the module applies the "effective" set of Rules. 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 page in the Settings section of the WebAdmin Interface. This link allows them 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.