Sieve Documents and Specifications
Standards Track Documents (RFCs)
Sieve Base Spec
This document describes a language for filtering email messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box Internet Message Access Protocol (IMAP) servers, as the base language has no variables, loops, or ability to shell out to external programs.
ManageSieve Protocol
Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol “ManageSieve” for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts and also alerts a user to syntactically flawed scripts.
Alternative Representations
This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.
Sieve Language Extensions
This document defines a new command that tests for the occurrence of one or more strings in the body of an email message.
In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables. The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined.
This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix “vacation” command for replying to messages. Various safety features are included to prevent problems such as message loops.
This extension extends existing conditional tests in Sieve to allow relational operators. In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.
This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords.
On email systems that allow for 'subaddressing' or 'detailed addressing' (e.g., “ken+sieve@example.org”), it is sometimes desirable to make comparisons against these sub-parts of addresses. This document defines an extension to the Sieve Email Filtering Language that allows users to compare against the user and detail sub-parts of an address.
The Sieve email filtering language “spamtest”, “spamtestplus”, and “virustest” extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric “scores”. It is the responsibility of the underlying Sieve implementation to do the actual checks that result in proper input to the tests.
By default, an e-mail message that is processed by a Sieve script is saved in the owner's “inbox”. Actions such as “fileinto” and “redirect” cancel this default behavior. This document defines a new keyword parameter, ”:copy”, to be used with the Sieve “fileinto” and “redirect” actions. Adding ”:copy” to an action suppresses cancellation of the default “inbox” save.
The “environment” extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message.
The “date” extension gives Sieve the ability to test date and time values in various ways. The “index” extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated.
Email header fields are a flexible and easy-to-understand means of communication between email processors. This extension enables Sieve scripts to interact with other components that consume or produce header fields by allowing the script to delete and add header fields.
The “reject” and “ereject” actions shall discard a message by refusing delivery during the SMTP transaction, if possible, or by sending a Message Disposition Notification [MDN] to the envelope sender along with an explanatory message.
The “ihave” extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script.
This is an extension for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on “fileinto” action.
Extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message.
This extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts.
This document describes how the “CONVERT” IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery.
Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications).
The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.
Sieve Extension for Notifications and Notification Mechanisms
This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent.
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail.
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the Extensible Messaging and Presence Protocol (XMPP), also known as Jabber.
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE.
Internet Drafts
The Sieve base specification defines so-called match types for tests: is, contains, and matches. An “is” test requires an exact match, a “contains” test provides a substring match, and “matches” provides glob-style wildcards. This document describes an extension to the Sieve language that provides a new match type for regular expression comparisons.
Sieve scripting language can be used for implementing of whitelisting, blacklisting and personal distribution lists. Currently this requires that all members of such lists be hardcoded in the script itself. Whenever a member of such list is added or deleted, the script needs to be updated and possibly uploaded to a mail server. This document defines a Sieve extension for accessing externally stored mailing lists, i.e. list whose members are stored externally to the script, for example in LDAP (RFC 4510), ACAP (RFC 2244) or a relational database.
Additional Links
Obsoleted RFCs:
- RFC 3028: Sieve: A Mail Filtering Language, obsoleted by RFC 5228
- RFC 3431: Relational Extension, obsoleted by RFC 5231
- RFC 3598: Subaddress Extension, obsoleted by RFC 5233
- RFC 3685: Spamtest and VirusTest Extensions, obsoleted by RFC 5235
Other related pages and documents:
and