Incoming Rules

Message rules instruct the Axigen mail server to take certain actions on processed email messages based on pieces of information contained by the message headers.

Thus you can create rules like:

• messages from john@example.com copy to alex@localdomain;

• messages from jokes@domain.com move to folder Jokes;

• all messages reply with "Out-of-office" message;

Message rules are easily created using the provided Web Wizard by each individual user via the WebMail module of Axigen. For more details on Wizard usage, please see "Mail filtering" in WebMail.

You can create more complex message rules using a simple scripting language called SIEVE. The same language is used by the WebMail Wizard when defining message rules automatically.

Using message rules is safe since they do not operate on the mail content, but only extract information from the mail header and take actions according to the predefined rules. They work basically by comparing different keys using different comparators and comparison methods, against headers of a mail message. Based on the result of the comparison, you can apply different actions to the corresponding mail message (i.e. reject, discard, redirect etc.).

Message rules are static filters, where the filter itself is contained in a separate file. Different user-defined scripts can be included in any Axigen Filtering System. The supported language provides an extremely flexible filtering methodology, as users can define any number of script filters according to their needs.

Axigen also implements the vacation extension. This means that message rules can be created and applied for generating out-of-office type automatic replies. Thus, auto-generated messages can be sent when the user of the account for which the vacation applies, is on vacation, out of office or in general away for an extended period of time. The vacation extension is an extra functionality also available via script files.

AntiVirus / AntiSpam filters can also interact with message rules, via two headers appended to email messages. These headers contain a spam or virus level value which actually indicates the likelihood of that particular email message being virus or spam. Based on these levels, actions imposed by the message rules can be taken, for instance moving email messages above a certain level to a specified Quarantine folder.

Axigen supports creating customized filter chain. This means you can define and use as many anti-virus / anti-spam filters and message rules as required by their security policies.

For a complete description of this language, see RFC 3028.

SIEVE overview

SIEVE is a language created and used for mail filtering either on the server or on the client. The language is completely described in the RFC 3028. SIEVE is an interpreted language that can be described as relatively simple. It has no loop structures, no variables (in the basic form) it has only an if control structure.

SIEVE works basically by comparing different keys using different comparators and comparison methods, against headers of a mail message and based on the result applies actions to the message (such as reject, discard, redirect).

The structure of SIEVE as described in the RFC 3028 is:

SIEVE defines 5 actions: keep, fileinto, reject, discard, redirect - which are self-explanatory.

It also defines 3 control commands:

• <stop> - which stops the processing to that point

• <if elsif else> structure

• require command - which defines an extension of the language. It tells the interpreter that the respective extension will be used in the script

The if structure has the form: if <test> <block> elsif <test> <block> else <block>

A block is a block of commands (actions and control commands - including other ifs) and a test can be one of the following:

1. address - tests a set of the address headers against a set of keys using different comparison methods

2. envelope - optional test

3. header - tests a set of the headers against a set of keys using different comparison methods:

   1. true, false - constants

   2. allof <other tests> - logic and between several tests

   3. anyof <other tests> - logic or between several tests

   4. not <test> - negation of a test

   5. exists - test if a set of headers exist

   6. size - test against the size of a message

A test can take 2 values: true or false.

After parsing a script against a mail message, several actions can result which may interact. Several constrains are defined regarding action interaction which will be explained in the next paragraph. If no action is to be taken after a complete parse of the script, or an error occurs, an implicit keep will ensure delivery of the message to the Inbox.

The Axigen SIEVE interpreter

The interpreter uses the following restrictions and constrains in implementing the RFC 3028:

• it implements the extensions described in the RFCs: "fileinto", "reject", "envelope", "copy", "relational", "spamtest", "virustest", "subaddress".

• the relational test: "count" can only be used with the "i;ascii-numeric" comparator and when there are more then one strings in the second string list, only the first will be considered.

• it implements the "i;octet", "i;ascii-ccasemap" and "i;ascii-numeric" comparators for the "i;ascii-numeric" comparator, the ":matches" and ":contains" tags, cannot be used. Error otherwise.

• it allows only require with (fileinto, reject, envelope, copy, vacation) arguments, gives an error message otherwise.

• it allows address and envelope test with the second string list (the values list) not tested for valid addresses (i.e. it allows part of addresses put in the values list).

• it allows only the: "From", "To", "CC", "Bcc", "Sender", "Resent-From", "Resent-To" headers to appear in the address test and only "To", "From" headers in the envelope test. Error otherwise.

• the required group of commands must appear first and must contain only required commands. Error otherwise.

• elsif and else must appear only after an if or an elsif. Error otherwise.

• there is one type of warning and five types of error messages:

  1. "[Syntax Error]: given if there is a syntax error in the script"

  2. "[Parse Error]: if a semantic error appears"

  3. "[Semantic Error]: similar to parse error"

  4. "[Validation Error]: if the script is not compliant to this document"

  5. "[Run-time Error]: if something is wrong during a message parse"

• numbers in the size test cannot be negative and cannot exceed 2^32-1. Error otherwise.

• numbers when using the "i;ascii-numeric" comparator cannot exceed 2^32-1 and cannot be negative. If a string used with this comparator starts with something other than a digit, or it's null or negative, or it exceeds 2^32-1, it gets the value 2^32. Leading whitespace (SP,HTAB,CRLF) is ignored.

• it does not allow two or more comparator, address-part, match-type tags in the address, hearer and envelope tests. Error otherwise.

Action interaction

General action interaction - the following constrains apply (error otherwise):

• "reject" can only be by itself and only once (eventually with "stop");

• "keep" can appear with any action (except "reject") several times, and a move to inbox (or similar) will be executed once;

• "discard" can appear with any action (except "reject") several times and the result will be a discard only when solely discard actions are present or there is an implicit "keep" by using the ":copy" tag;

• "fileinto" can appear several times with any action (except "reject") and a move to the specified folder will be executed (if a move to the same folder is specified, it is treated as an error, but a duplicate move will not be performed - a warning will be issued);

• "redirect" can appear several times and with any action (except "reject"), the result consisting in redirecting to the specified address only once (without giving an error if a duplicate reject with the same address appears) - a warning will be issued;

• any action except "stop", "fileinto", "vacation" and "redirect" used with the ":copy" tag will cancel the implicit "keep".

Vacation interaction

• "vacation" can appear once per script and all other appearances will be disregarded;

• "vacation" used with "discard", "redirect", "fileinto" or explicit "keep" will not be an error and will not be considered to break the respective actions interaction rules.

Spamtest and Virustest extension

This implementation supports the spamtest and virustest extensions as described in the RFC 3685, but in each case, the following constrains appear:

1. Spamtest

• a separate tool will be implemented that will map vendor specific information from anti-spam tool

• a new header named "X-AxigenSpam-Level" will be added which can have the following values:

  • 1 - message was tested and is clear of spam

  • 2 - 9 - message was tested and has a varying likelihood of containing spam in increasing order

  • 10 - message was tested and definitely contains spam

2. Virustest

• a separate tool will be implemented that will map vendor specific information from anti-virus tool

• a new header named "X-AxigenVirus-Level" will be added which can have the following values:

  • 1 - message was tested and contains no known viruses

  • 2 - message was tested and contained a known virus which was replaced with harmless content

  • 3 - message was tested and contained a known virus which was "cured" such that it is now harmless

  • 4 - message was tested and possibly contains a known virus

  • 5 - message was tested and definitely contains a known virus

The possible values of the header SHOULD be only numbers and if so MUST be only the above numbers, but may also have leading and trailing spaces and may contain alphanumeric characters after the numbers. There may be maximum one header of each type at a given moment, and when the tool has a value to assign to the header, it will assign it only if it is greater than the value already contained in the header.

Vacation extension

The vacation extension is implemented using the draft: draft-ietf-sieve-vacation-04. The vacation extension is used to send auto-generated messages when the user of the account for which the vacation applies, is in vacation, out of office, in general away for an extended period of time.

For a description of the syntax of this extension, please consult the SIEVE related documents and the draft this implementation is based of.

Implementation specific issues like restrictions and constrains and general issues that appear in the draft with SHOULD or MAY, are defined below:

• The minimum value for the vacation: days argument is 1 and the maximum is 45. If the value given to the days argument is less that 1 it will be considered 1 and if greater that 45, it will be considered 45. The default value if the days parameter is omitted is 7.

• The "Previous Response Tracking" feature (section 4.2 of the draft) is implemented using a CRC32 hash and the date when the response was sent. This means that there may be cases when a second response will be generated even though it was not supposed to, but the chances of that is negligible compared to the speed gain.

• The "Limiting Replies to Personal Messages" feature (section 4.6 of the draft) was implemented considering the same cases as in the draft, but this will change in a way to allow you to define custom rules for recognizing auto-generated mails.

• The vacation response message is generated with all the features defined in the Section 5 of the draft except the "References" field that is not generated in this version of the implementation.

The interaction between vacation and other actions is described above, under "Action interaction".