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, like 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:
   

• true, false - constants
• allof <other tests> - logic and between several tests
• anyof <other tests> - logic or between several tests
• not <test> - negation of a test
• exists - test if a set of headers exist
• 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
• 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 require 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 is null, or is 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:
Spamtest

• a separate tool will be implemented that will map vendor specific information from antispam tool and
• 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
Virustest

• a separate tool will be implemented that will map vendor specific information from antivirus tool and
• 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 in 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 the administrator 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.