Automated E-mail Processing 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.

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:

From is

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:

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 @ 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:

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

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:

Source isis notinnot in

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:

Security isis notinnot in

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.

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 descibes 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 begining 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.

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.