Mail Rules

Mail Rules

With rules you can filter emails containing certain words or strings in the body or the subject, you can move emails automatically to certain folders, reject emails from specific recipients or have them deleted automatically.

You can specify as many rules as you like.

In Preferences / Mail / Rules you can create, edit and delete rules and arrange the order in which they are executed.

Always remember to click Save All Settings after you have finished changing settings.

Rules will be executed for all incoming emails. The execution will take place sequentially in the order you have specified.

Creating a Rule

To create a new rule:

  1. Click +
  2. Enter a name for the rule.
  3. In the section Applies To select one or more conditions each incoming mail will be checked for. Only the emails that meet these conditions will be processed by the rule. To add more conditions, click +.
  4. A condition can apply to these elements of an email:
    • Subject
    • From
    • Sender
    • To
    • CC
    • Reply-To
  5. Enter the content that should be matched. You can match using these operators:
    • is
    • is not
    • in
    • is not in
  6. Define the Action that should be performed on emails that match the conditions set up in the Applies To section. You can combine different actions performed on an email choosing from:
    • Store in
    • Stop processing
    • Discard
    • Reject with
    • Mark
    • Add Header

For some actions you have to specify a target, e.g. the action Store In needs a folder where to store the matching messages in.

  1. Optionally enter a descriptive text in Description.
  2. Confirm your settings by clicking Save Rule or discard the rule with Cancel.

For additional email rules, we suggest configuring such rules within your desktop email client. If connected via IMAP, Activesync or MAPI the result of those desktop mail rules will also be reflected in webmail and all other similarly connected mail clients, such as mobile devices.

Rule Conditions

Each Rule can use universal conditions.

Checking the "From" or "Sender Address" fields

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.

Example:

The above condition will be met for all messages coming from any account in any of the webnames.ca domain or subdomains.

Checking the "Sender", "Reply-To" "To" or "CC" fields

In this next example, in a similar manner as the above, 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.

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.

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.

Example:

This condition will be met for messages where any To and CC addresses are addresses in the webnames.ca domain or addresses in the gmail.com domain.

Checking the "Return-Path", or "From" fields

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

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

Example:

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

Checking the "Subject" field

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

Example:

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

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

Example:

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

Checking the Message Size

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

Example:

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

Checking if the message is 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.

Checking "Message Header" Field

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.

Example:

Checking the "Recipient" Field

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.

Example:

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.

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

This condition checks the source where from the message was received:

Sample:

Checking if an Message has been Encrypted

This condition checks if the message is an encrypted or a signed one. It compares the following string with the condition operand:

Example:

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.

As a result of this action, the message is no longer stored in the INBOX, however a positive Delivery Notification message is sent back to the message sender (if requested).

Example:

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.

Example:

Mark flagName [, flagName...]

This action sets or resets the specified message flag(s):

Name Description IMAP Name Negative Name
Seen This flag is set when the message was read by a client. It can be set automatically as a result of certain Mailbox access operations, and it can be set and reset explicitly with mail client applications. \Seen Unseen
Read same as Seen   Unread
Answered This flag is set when a reply was sent for this message. This flag is explicitly set and reset with mail client applications. \Answered Unanswered
Flagged This flag is set to attach a "flag" to the message (for example, a mail client can show this message to the user as an important one). This flag is explicitly set and reset with mail client applications. \Flagged Unflagged
Draft This flag is set for messages that have not been sent yet. It tells a mail client that it can open and edit this message. This flag is explicitly set and reset with mail client applications. \Draft Undraft
Deleted This flag is set for messages that were marked for deletion. Some mail clients allow users to mark some Mailbox messages first, and then delete ("expunge") all marked messages from the Mailbox. This flag is explicitly set and reset with mail client applications. \Deleted Undeleted
Redirected This flag is set when a copy of the message was sent (redirected) to someone. This flag is explicitly set and reset with mail client applications. $Forwarded NotRedirected
MDNSent This flag is set when an MDN ("read report") for the message has been sent. This flag helps mail clients to send only one MDN report for each message. This flag is explicitly set and reset with mail client applications. $MDNSent NoMDNSent
Hidden Messages with this flag set are visible only to the Mailbox Account owner and to those users who have the Admin Access Right for this Mailbox.This flag allows users to grant access to their Mailboxes to others while keeping certain messages private (hidden). $Hidden NotHidden
Service Messages with this flag set are not visible toIMAPorPOPclients.MAPIclients can use this flag to create service items invisible to users (such as Mailbox forms). $Service NotService
Media If this flag is set, the message is treated as containing some "media" (audio/video) data. $Media NotMedia
Junk If this flag is set, the message is treated as "junk" (spam). Junk NotJunk

Initially the set of message flags contains:

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.

Example:

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

Example:

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:

Example:

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.

Example:

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.

Example:

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.

You should have the Insert access right to the destination Mailbox.

Example:

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:

Example:

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.

Example:

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.

Example:

Example:

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.

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: