Domain-wide Mail Rules

With domain-wide rules, you can take action on emails across all email accounts for your domain. Rules can be based on a wide number of conditions, and can in turn perform a number of actions.

Overview

Managing email rules across all accounts within a domain is a crucial aspect of maintaining organizational efficiency, security, and compliance. This article provides a comprehensive guide to creating and managing these rules, ensuring that email traffic is appropriately filtered, categorized, and handled according to your organization's policies.

Email rules, also known as filters or policies, can automate various tasks such as sorting incoming emails, blocking spam, forwarding messages, and applying specific actions based on predefined criteria. By implementing domain-wide email rules, administrators can enforce consistent policies across all users, reducing the risk of security breaches and ensuring compliance with regulatory requirements.

Accessing Domain-wide Email Rules

To access the Domain-wide Email Rules for your domain:

You can specify as many rules as you like.

Always remember to click Apply after you have finished changing settings.

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

NOTE: These Domain-wide Mail Rules work in conjunction with Account Mail Rules, which can be configured by each mail user via our webmail interface.

Rules are processed in the following order:

  1. Domain-wide Mail Rules with priorities above 5.
  2. All Account Mail Rules.
  3. Domain-wide Mail Rules with priorities equal to or less than 5.

This method guarantees that all Domain-Wide Rules with priorities higher than 5 are applied before any Account Rule. If such a Domain-Wide Rule uses the Stop Processing action, no Account Rules are applied.

Creating a Rule

To create a new rule:

  1. Click + New Rule
  2. Enter a Name for the rule
  3. Assign a Priority for the rule

CREATE Conditions

  1. 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 New Condition.
  2. Rules can be based on one or more of the following conditions:
From Return-Path Security
To Subject Calendar Method
From' Name Message-ID Current Date
Authenticated Message Size Submit Address
Sender Human Generated Time Of Day
Cc Header Field Current Day
Reply-To Any Recipient Preference
Any To or Cc Each Recipient FreeBusy
Each To or Cc Source Existing Mailbox

For further detail on these conditions and their use, please see Rule Conditions.

CREATE Actions

  1. Enter the Parameter that should be matched. You can match using these Operators:
    • is
    • is not
    • in
    • is not in
  2. Define the Action that should be performed on emails that match the conditions set up in the Conditions section. You can combine different actions performed on an email choosing from:
Stop Processing Reply with
Redirect to Reply to All with
Forward to React with
Discard Store Encrypted in
Reject with CopyAttachments
Mark Accept Request
Add Header Accept Reply
Tag Subject SendURL
Store in SendIM
Mirror to  

For further detail on these actions and their use, please see Rule Actions.

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

  1. Confirm your settings by clicking Apply or discard the rule with the trash can icon.

Available Rule Conditions

Each Rule can utilize one or more conditions. The majority of these conditions are based on values present in an email's header. View an email in it's raw/original format to gain access to the header information, and then tailor the conditions of your mail rule to match the values found in the email in question. Balance the quantity and specificity of your mail rules to ensure accuracy while minimizing false-positives.

Checking the "From" or "Sender Address" fields

This condition checks the message From or Sender address.

Example:

The above condition will be met for all messages where the sender email address contains "webnames.ca"

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.

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

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.

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 Operator and the Parameter value (if any) are ignored.

This condition 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 if the message has a non-empty Return-Path.

Checking "Message Header" Field

This condition checks if the message header contains (or does not contain) a specified header field. Checking email for the presence of a specific header field is an extremely powerful and flexible way to match specific emails. To help identify spam, spoofed and other undesirable email, when Webnames receives suspect email addressed to you, we insert one or more customer values into the email's headers. These headers values can then be used as parameters for subsequent action, such as moving email to a Spam folder, prepending the word SPAM to the subject, or even discarding the email entirely.

The table below itemizes the header values that Webnames.ca inserts into inbound email when the corresponding criteria is met:

Criteria Inserted Header Value
If SPF check fails: X-Webnames: spf-fail
If SPF check soft fails: X-Webnames: spf-softfail
If SPF check finds an invalid record: X-Webnames: spf-invalid
If SPF check find no SPF record: X-Webnames: no-spf-record
If DKIM record is found but check fails: X-Webnames: dkim-fail
If DKIM record is not found: X-Webnames: no-dkim-record
If SPF records are invalid: X-Webnames: spf-permanent-error
If SPF processing error: X-Webnames: spf-temp-error
If SPF records exits, but there is no definitive assertion: X-Webnames: spf-neutral
SPF records check passed: X-Webnames: spf-pass
If email is determined to be a newsletter

(via fuzzy heuristics, not 100% accurate)

 X-Webnames: newsletter
If an email contains a blacklisted URL: X-Webnames: suspicious-url

Example:

Checking the "Recipient" Field

This condition compares message "Envelope" addresses and the specified parameter. 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 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 from where 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:

Available 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]

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: