| Version 5.4
Introduction
Installation
SysAdmin
Network
Objects
Storage
E-mail
Real-Time
Access
Services
Directory
Clusters
Applications
Miscellaneous
Licensing
WebMail
Pronto!
PBX
Overview | Rules | Filters | SMTP | Local | RPOP | LIST | PIPE
# Automated E-mail Processing Rules Specifying Message Rules Rule Conditions Rule Actions Macro Substitution Vacation Message Redirect All Simplified Rule Junk Processing Simplified Rules Logging Rules Activity The CommuniGate Pro Server can automatically process messages using sets of Automated Rules. This section describes the Automated Processing Rules for E-mail messages, also called the Queue Rules. The Server-Wide and Cluster-wide Rules are applied to all messages submitted to the Server and to the Cluster. These Rules are applied by the Enqueuer component, before it enqueues a message into the transfer module queues. When a message is directed to an Account on this CommuniGate Pro Server, the Local Delivery module applies the Account-level Rules. The Account-level Rules are the Rules specified for the particular Account along with the Rules specified for the Account Domain.

## Specifying Message Rules

System administrators can specify Server-Wide and Cluster-wide Message Rules. Use the WebAdmin Interface to open the Mail pages in the Settings realm, 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.

See the Automated Rules section to learn how to set the Rules.

## Rule Conditions

Each Rule can use universal conditions specified in the Generic Rules section.
This section describes the additional Rule conditions you can use in E-mail (Queue) Rules.

`From [is | is not | in | not in] string
Sender [is | is not | in | not in] string`
  This condition checks the message `From` or `Sender` address.
  If a message has no From/Sender address, the condition is met if its operation is `is not` or `not in`.

  Sample:

    This condition will be met for all messages coming from any account in any of the communigate.com subdomains.
  The same as above, but the message Sender, Reply-To, To, or Cc address is checked.
`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 message 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:

    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:

    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:

    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:

    This condition will be met for all messages without the Message-ID flag and for messages that have Message-ID without the `@` symbol.
`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:

    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* (except for `X-Auto-Response-Suppress`), X-Mailing-List, Auto-*
  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 fields added using the `Add Header` operation (see below) are checked, too.

  Sample:

`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).
`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 has been authenticated).

  Sample:

`Security [is | is not | in | not in] string`
  This condition checks if the message is an encrypted or a signed one. It compares the following string with the condition operand:

  `SMIME:encrypted` | if the message is encrypted using the S/MIME standard
  `SMIME:signed` | if the message is digitally signed using the binary S/MIME standard (PKCS7)
  `signed` | if the message is digitally signed
  | (empty string) in all other cases

  Sample:

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.

## Rule Actions

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

You can use all universal actions described in the Generic Rules section. This section describes the additional Rule actions you can use in E-mail (Queue) 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.
`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 a positive Delivery Notification message is sent back to the message sender (if requested).
  Sample:
    `IF From is *that_annoying_guy@*
    THEN
    Discard`
`Reject With [error message text]`
  See the Rules section.
  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 flagName [, flagName...]`
  This action sets or resets the specified message flag(s).
  Initially the set of message flags contains:
  - the `Media` flag - if the message contains a voicemail or videomail (if the message has the `audio/*`, `video/*`, or `multipart/voice-message` Content-Type).
  - the `Hidden` flag - if the message header contains the Sensitivity field with the `private` value.
  Flag Names can be used to add flags to the set, while Flag Negative Names can be used to remove flags from the set.
  When the message is stored in a Mailbox as a result of the `Store in` action, as well as when the 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,Read`
`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, sent, copied, or sent to an external program, the additional header fields are added to the message.
  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`
`Tag Subject tag`
  This action specifies a string to be added to the Subject header field.
  When a message is stored, sent, copied, or sent to an external program, the specified subject tags are inserted into the beginning of the Subject header field.

  Sample:
    `IF From is ceo@mycompany.dom
    THEN
    Tag Subject [CEO]`
  If several Tag Subject actions have been used with one message, the latest tag is added first, followed with the other tags, followed with the original message Subject.

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 mailboxName`
  The message is copied to the specified Mailbox in your Account.

  Sample:
    `IF From is developer@partner.com
    THEN
    Store in DeveloperBox
    Discard`
  If the mailbox name starts with the `[MUSTEXIST]` prefix, the prefix is removed, and the Rule processing fails if the Mailbox does not exist. Otherwise, if the Mailbox does not exist, an attempt to create it is made.
  If the mailbox name starts with the `[IFEXISTS]` prefix, the prefix is removed, and the action completes immediately if the Mailbox does not exist.

  If the mailbox name is specified as `~accountName/mailboxName`, or as `~accountName@domainName/mailboxName` the message is stored in the mailboxName Mailbox in the accountName Account in the same Domain or in the accountName@domainName Account.

  When this action is used in a Server-wide or Cluster-wide Rule, the mailbox name must be specified in this form, as there is no default Account for those Rules.

  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 (`,`) symbol.
  The specified addresses replace the message To/Cc header fields, unless these specified addresses are prefixed with the `[bcc]` string;
  The "new sender" address is constructed as 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 redirected message Return-path address is set to the "new sender" address, or to the empty address if the Return-path address of the original message was empty.
  The redirected message Sender address is set to the "new sender" address.
  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 sender" address is not stored as the Sender field. Instead it is used to compose a new From field.
  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 From address of the original message.

  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)
    `^r` is substituted with the E-mail address of the current Account.

  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 plus (`+`) symbol, the lines following this symbol 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).

  Unless the specified header contains the `From` field, the From field is composed using the From Address from the Account WebUser Settings. If that address is not set the From Address is composed using the full Account Name and the Account Real Name setting.

  If the full Account name is not stored as the `From` field, it is stored 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), otherwise it is converted into the charset used in the incoming message. If the incoming message did not have a charset specified, and the Rule is an Account-Level one, the Preferred Charset specified in the Account WebUser Preferences is used.

  If the text starts with the plus symbol, the plus symbol must be specified after the `[charsetName]` string.

  Unless the specified header contains the `MIME-Version` and `Content-Type` fields, these fields are added to the composed message.

`Reply to All with message text`
  The same as above, but the reply is sent to all addresses listed in the `To` and `Cc` fields of the original message.
`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 specified message header and the message body can contain macro symbols listed above.

  The `From`, `Sender`,`MIME-Version`, and `Content-Type` fields are composed in the same way as for the Reply With operation.

  Sample:

    `React with` | To: 123456@pager.mycompany.com (my pager) Cc: "My Home Account" <myhome@provider.com> FYI: message ^I was received from ^F. Its Subject was: ^S

  The message text can start with the `[charsetName]` string (see above).

  Sample:

    `React with` | [ISO-8859-1]To: myhome@provider.com (my Home Account) MIME-Version: 1.0 Content-type: text/html; charset=ISO-8859-1 <HTML><BODY> Nachricht <B>^I</B> wurde empfangen von ^F <P>Das Betreff war: <I>^S</I> </BODY></HTML>

`Store Encrypted in mailbox name`
  This action works in the same way as the `Store in` action, but a message is converted into S/MIME encrypted form before being stored.
`Copy Attachments into file directory name`
  This action copies the message attachments to the specified File Storage directory.
  Attachments are detected as parts of the topmost `multipart/mixed` or `multipart/related` MIME structure.
  If the directory name has the `[replace]` prefix, an existing file with the same name is replaced, otherwise an error is generated if the file already exists.
  If the directory name is empty, then files are stored to the topmost level of the Account File Storage.
  If the directory name ends with the star (`*`) symbol, the symbol is replaced with a unique string, the file extension from the attachment name (if any) is added and the resulting name is used as the File Storage file name for the attachment.

  Sample:

    `Copy Attachments into` | [replace]pic-archive

  Sample:

    `Copy Attachments into` | videolib/video-*

`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 `-p` string 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 `-r` string followed by the list of message recipient addresses is added to the end of the command text:
  -r "address1@domain1.com" "address2@domain2.com"

  A command text can be prefixed with the `[ORCPT]` tag:
  [ORCPT] myprogram parm1
  When this prefix is specified the `-r` string 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]` prefixes cannot be used together.

  A command text in an Account-Level Rule can be prefixed with the `[ACCNT]` tag:
  [ACCNT] myprogram parm1
  When this prefix is specified the `-u` string followed by the Account name is added to the command text:
  -u "accountName@domainName"

  A command text in a Server-Wide Rule can be prefixed with the `[ROUTE]` tag:
  [ROUTE] myprogram parm1
  When this prefix is specified the string `-R` followed by the Routed recipient addresses is added to the command text:
  -R "LOCAL(accountName@domainName)" "SMTP(example.com)user@example.com"
  See the conditions section for the Route data format information.

  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, IBM OS/2, 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

`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 action parameter specifies the name of the External Filter program to use.

  Sample:

    `ExternalFilter` | McAfee

`Accept Request options`
  This action can be used to accept Calendaring Meeting Requests automatically. See the Calendaring section for more details.

## Macro Substitution

Parameter strings for some actions can include "macro" - symbol combinations that are substituted with actual data before the parameter is used with the Rule action.

The following symbol combinations are available:

  `^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, converted to UTF-8)
  `^F` is substituted with the From address of the original message (decoded, converted to UTF-8, including the "Real name" part)
  `^E` is substituted with the From address of the original message (the E-mail address only)
  `^T` is substituted with the RFC822-formatted timestamp taken from the Date field of the original message.
  `^t` is substituted with the RFC822-formatted current-time.
  `^I` is substituted with the Message-ID field of the original message
  `^R` is substituted with the To E-mail addresses of the original message (a comma-separated list)
  `^r` is substituted with the recipient E-mail addresses (a comma-separated list).
  `^^` is substituted with a single `^` symbol.

## Vacation Message

Each Account can have a "simplified" 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`
  `Current Date is less specified time` (optional)
  `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
Ends:
Dear ^F! I'm on vacation right now, please contact me after 06-Aug-2008. 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).
`Ends`
  If this option is selected, the Vacation Message Rule stops working at the date specified with this setting.

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

An Account can use a simplified Rule to redirect all incoming E-mail messages 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.

## Junk Processing Simplified Rules

An Account can have simplified Rules to handle junk E-mail messages.

These Rules rely on other Rules, usually employing External Filter programs, to add a special message headers field with the "junk probability" level.

Each Junk Control Rule has a condition checking contents on the `X-Junk-Score` message header field. The other condition checks if the message From address is not included into the AddressBook dataset ("whitelisting").

If the conditions are met, a Junk Control Rule can either discard the E-mail message, store it in the Junk Mailbox (the Junk Mailbox name as specified using the Account Preferences), or mark the stored E-mail Message with the `Junk` flag.

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

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