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.
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.
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.ru 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.
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 the source where from the message was received:
trusted
from the Server itself as auto-generated message, via PIPE module, or via SMTP from a computer with the network address listed in the Client IP Addresses list
whitelisted
via SMTP from a computer with the network address listed in the White Hole Addresses list
authenticated
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:
Calendar Method [is | is not | in | not in] string
This condition checks if the message contains a calendar part of particular type (REQUEST, REPLY, CANCEL). This condition can be used in Domain-wide or Account-level rules only.
Sample:
The following conditions can be used in Server-Wide Rules only:
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.
Authenticated [is | is not | in | not in] string
This condition checks the Message authentication. If the Message has been
authenticated by this CommuniGate Pro Server, the authenticated Account name (account@domain)
is compared with the specified string.
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 [IGNOREFAILURES] prefix, the prefix is removed, and errors occurd while storing a message into a Mailbox are ignored.
Otherwise, if there was an error, the Rule processing fails.
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. Note: you may use only one of the above prefixes at a time.
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, Errors-To and DKIM-Signature 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:
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:
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:
The message text can start with the [charsetName] string (see above).
Sample:
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 a message contains only one non-multipart part, and the Content-Disposition for that part is "attachment", it is treated as an attachment, too.
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:
Sample:
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.
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 operating system.
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:
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:
Accept Request options
This action can be used to accept Calendaring Meeting Requests automatically.
See the Calendaring section for more details.
Accept Reply
This action can be used to accept Calendaring Meeting Replies automatically.
See the Calendaring section for more details.
Parameter strings for Execute URL, Send IM,
Send Push, Write To Log actions can include "macro" - symbol combinations that are substituted
with actual data before the parameter is used with the Queue 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.
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. Alternatively, the Notify option may be enabled,
so a copy of each incoming message is forwarded to the specified addresses.
This Rule conditions are:
Human Generated Current Date is greater specified time (optional)
Current Date is less specified time (optional)
From not in #RepliedAddresses (optional)
The Rule actions are:
Reply with Reply Text Forward to address list Remember 'From' in RepliedAddresses
Only the text of the Reply message can be modified:
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).
Starts
If this option is selected, the Vacation Message Rule starts working at the date specified with this setting.
Ends
If this option is selected, the Vacation Message Rule stops working at the date specified with this setting.
Notify
If this option is selected and a list of addresses is specified, a copy of incoming message is forwarded to specified addresses.
This option is available only when the account has rights to specify the redirecting Rule actions.
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.
An Account can use a simplified Rule to send copies 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
Forward to or Redirect to or Mirror to, and, optionally, Discard.
Only the list of redirection addresses can be modified:
Copy All Mail To
If this option is not selected the Copy All Mail Rule is disabled.
If this option is selected, the Copy All Mail Rule is enabled with
the lowest priority (the rule priority is set to 1).
Keep the Original
If this option is not selected, the action Discard is added to the
Rule and all copied messages are NOT stored in the account INBOX.
Do not Copy 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.
Send on behalf of this Account
If this option is selected, the Forward to action is used for this Rule. This option must be used if the Account has 'From' Address/Name restrictions enforced, or if the target host enforces DMARC or other checks of the sender address.
Keep the Original sender Address
If this option is selected, the Redirect to action is used for this Rule.
Send unchanged Copy
If this option is selected, the Mirror to action is used for this Rule.
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.
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.
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.