Sieve override extension

Multiple sieves can be and often are evaluated for a given message recipient. When this happens some actions, such as,  , or  , are accumulated across all applicable sieves. But actions that determine the ultimate disposition of a message have to come from a single sieve.

The general rule is that the most specific sieve that sets a disposition wins. So if, say, a keep done by a system sieve would be overridden by a discard done by a user sieve.

A couple of nonstandard actions have previously been added to override this determination order. In particular, the most general sieve that performs a  or   action will determine the disposition of a message for a given recipient.

The use cases for  and   are obvious: If system policy has determined that a user cannot see a message, the user&#x27;s own preferences need to be overridden. The jettison and refuse actions also have the advantage that they are incompatible with other disposition actions, making them easy to use.

In contrast, the other disposition actions (keep, discard, fileinto, redirect, etc.) are all compatible with each other, and in practice are used in a wide variety of combinations and permutations. So separate "override" variants of these actions don&#x27;t make as much sense.

Even so, it may be useful for a system-level sieve to forcibly direct messages using redirect and possibly fileinto, while retaining their standard semantics in the context of the sieve where they are specified. For this to work correctly, such sieves need to be able to override disposition actions specified by more specific sieves. Accordingly, a nonstandard sieve override extension and corrresponding action has been added. A sieve that uses this action becomes the sieve determining the disposition of the message. If multiple sieves employ override, the most general one wins.

For example, suppose you have a system sieve: redirect "foo@bar"; And the recipient has a user sieve: keep; The  action wins and the message is filed into the recipient&#x27;s INBOX folder. Now suppose the system sieve is changed: require "override"; override; redirect "foo@bar": Now the redirect action wins and the message is redirected.

See also:
 * Sieve hierarchy
 * Sieve supported extensions