RFC 5228 (Sieve)(originally RFC 3028 (Sieve)), later updated by various extensions and proposed extensions, defined a language for specifying processing of messages appropriate for performing upon message delivery. Such processing might include: filing those messages meeting specified criteria into special folders rather than simply delivering into the INBOX, redirecting (so-called "forwarding") messages meeting specified criteria to additional recipients, setting IMAP flags for messages meeting specified criteria, generating new notification messages when certain sorts of messages are delivered, returning "vacation" messages, discarding messages matching specified criteria, etc.
The MTA supports a hierarchy of Sieve filters applicable to messages. At the user level and domain level, this includes user personal Sieve filters, so-called "head of household" or "parental" Sieve filters, and domain level (domain wide) Sieve filters. And certain user LDAP attributes are interpreted by the MTA as specifying a Sieve "
vacation" action---so essentially converted on-the-fly into a Sieve pseudo-script---and then merged with whatever other, explicit, user Sieve actions apply. The MTA also supports system (MTA) level Sieve filters, including channel level Sieve filters (for either or both of destination channels and source channels) and an MTA-wide Sieve filter.
The MTA's spam/virus filter package integration also takes the form of Sieve filter scriptlets, where the MTA is configured to interpret possible spam/virus filter package verdicts as requests to apply specified Sieve filter actions.
An important (and rather complex) topic is the interaction and hierarchy of how the MTA merges these multiple "levels" of Sieve scripts (and pseudo-scripts), and which Sieve filter actions take precedence, when multiple levels of Sieve script apply to a message. See the Sieve hierarchy topic for further discussion.
The MTA evaluates and applies applicable Sieve scripts (per its Sieve hierarchy rules) during message enqueue processing. While system-level Sieve scripts are often applicable (depending upon type and configuration) early in a message's lifetime, such as upon initial message submission to an MTA, user-level Sieve scripts for local recipients tend to be applicable instead at the time of enqueue to a delivery channel (enqueue to an
ims-ms channel or
A separate and different use of Sieve filters is available to the Message Store, for message expiration purposes. If enabled with the
expiresieve Message Store option, the Message Store can use Sieve filter tests to determine which messages to expire. Besides using Sieve filter tests in normal expiration rules (expiration rules defined via either Message Store expirerule options or for greater flexibility and performance
store.expirerule files), new in MS 7.0.5 the
imexpire utility also supports invoking spam/virus filter packages to scan messages post-delivery for spam or virueses, integrating application of the verdicts from such spam/virus filter package via Sieve filter scriptlets.
- Sieve language
- systemfilter MTA Option
- destinationfilter Option
- Sieve supported extensions
- The MTA
- Sieve hierarchy
- ldap_filter MTA Option
- ldap_domain_attr_filter MTA Option
- Sieve external lists
- Sieve filter manipulation of conversion tags
- Mail filtering and access control
- expiresieve Store Option
- Sieve filters and delivery flags channel options
- Sieve filter MTA options
- Head of household Sieve filters
- Spamfilter MTA options
- ims-ms channels
- LMTP client TCPIP channels
- The Message Store
- Message expiration
- expiresieve Store Option
- imexpire invoking spamfilter packages
- Spam and virus filtering
- Sieve filters: implementation internals