Note: This page was original hosted at the Cyrusoft/ISAMET, Inc. site. As Cyrusoft has gone bankrupt, a copy of this page was made from the Internet Archive from the latest available on Nov 26, 2004. Some links on this page may not work any more.


Sieve

A Mail Filtering Language

This page is provided as an informal coordination point for activities related to the Sieve mail filtering language. Sieve is a proposed internet-standard language for filtering mail at the time of final delivery.

This page last updated November 4, 2004.

Sieve: RFC3028!

Our beloved base document is now RFC3028 and the clock is officially ticking for Sieve as a proposed internet standard, as of January 2001.

SIEVE in Network World article.

Contents

An Overview of Sieve

The following description of Sieve is from the Internet Draft describing the Sieve language (linked below), by Tim Showalter, adapted and expanded by Matt Wall:

Sieve is a language that can be used to create filters for electronic mail. It is not tied to any particular operating system or mail architecture. It requires the use of RFC822-compliant messages, but otherwise should generalize to other systems that meet these criteria.

Sieve is designed as a proposed Internet Standard, and design and development to date has followed Internet Engineering Task Force (IETF) procedures as described in RFC 2026. It is not at this time the product of an official IETF Working Group, although advice and direction from the Applications Area directors as well as IETF procedures guide the work in progress. It is the current intention of the participants of the Sieve mailing list (information on this is listed below) to move Sieve to Proposed Standard in a timely manner (bypassing a formal Working Group if at all possible).

Sieve is a multi-vendor effort that has been discussed in various technical and standards-oriented public and private meetings since at least 1994.

The language is powerful enough to be useful, but limited in power in order to allow for a safe server-side filtering system. The intention is to make it impossible for users to do anything more complex (and dangerous) than write simple mail filters, along with facilitating GUI-based editors. The language is not Turing-complete, and provides no way to write a loop or a function. Variables are not provided.

Implementations of the language are expected to take place at time of final delivery, when the message is moved to the user-accessible mailbox. In systems where the Mail Transport Agent (MTA) does final delivery (such as with traditional UNIX mail systems) it is reasonable to sort when the MTA deposits mail into the user's mailbox. However, Sieve filters might be used at a number of "final delivery" points in a mail system: by an SMTP server, by an IMAP or POP server filing into one or more mailboxes, or by a Mail User Agent (MUA or mail client) acting as a delivery agent (for instance, a POP or offline IMAP client.)

Because of the expectation that users will make use of filtering if it is offered and easy to use, this language has been made simple enough to allow many users to make use of it, but rich enough that it can be used productively. However, it is expected that GUI-based editors will be the preferred way of editing filters for most users.

Why a standard syntax for mail filtering?

There are a number of reasons to use a filtering system. Mail traffic for most users has been increasing due both to increased usage of e-mail, the emergence of unsolicited email as a form of advertising, and increased usage of mailing lists. Filtering is among the most common tools available for end users and system managers alike to provide sorting and disposition mechanisms for email.

There are many filtering schemes in place at present, using widely variant underlying syntaxes and representing different levels of sophistication, functionality, and detail. Virtually no two different filtering schemes interoperate with one another, forcing users and system administrators alike to re-create filters for each individual piece of software.

A standard would allow both software authors and vendors to write tools that would use common scripts. The applications for this standard are many.

What Sieve is not

Sieve is simply a specialized standard filtering syntax/language.

Sieve is not intended to be the latest, greatest instantiation of a complete programming language.

Sieve is not particularly intended to be useful with filtering or processing anything other than RFC822 messages.

Sieve is not intended as a replacement for the basis of any particular existing tool per se, although its design is informed by the experience with many existing tools.

While Sieve certainly doesn't provide the most sophisticated filtering syntax possible, it does provide fundamental basics common to all RFC822 messages to establish a basic standard syntax for interoperation. It also provides an extension mechanism to allow individual implementations to provide extended functionality within an open standards framework. As such, Sieve is intended as a first-stage building block for mail filters, although one that in and of itself provides significant functionality for a large number of possible uses.

Sieve purposely makes no comment on or discussion of the transport mechanism used by end users over which Sieve scripts might be moved. Possibilities are many, and include file transfer, direct editing on a file system, http, acap, ldap, and a number of other application-level transport methods. Sieve scripts are simply data for Sieve engines to execute.

Sieve is not a once-and-for-all solution for pressing problems addressed by filtering, such as anti-Spam efforts, although it certainly is intended to facilitate construction of such solutions.

Sieve Documents

(now on a separate page)

Sieve Implementations

This space is intended to be a single-stop listing of all announced available Sieve implementations, or pre-announcements of any work in progress as made by any individual, organization, or company.

Sieve Extension Support

A list of supported extensions by product is available here.

Sieve Scripts Archive

This space is intended to provide a public repository for Sieve scripts. The purpose of this is twofold: to provide samples for interoperation testing during Sieve development, and as time progresses, to provide for the interchange of useful scripts by vendors and Sieve end-users.

Script Name Function Author Sieve Version Dependencies Description
hillen-sieve-script-001.txt A working personal mailbox filter list Rolf Hillen CMU-Sieve-1.3+ "fileinto" Some selected expressions from my sieve script which I currently use only for sorting mails into different imap folders.
maro-sieve-script-001.txt Sample script that rejects some nasty unwanted mail Tony Maro CMU-Sieve-1.3+ "fileinto", "reject" Working personal script. Note the use of a reject statement to control a particular mail virus!
Fastmail SIEVE Example Web page with example script Fastmail Sieve "fileinto", "reject", "vacation", "regex", "relational", "comparator-i;ascii-numeric" Detailed example showing white-listing, black-listsing, SMS notifications, spam score testing.

Sieve Mailing List, Discussion, and Archives

Internet drafts on Sieve are discussed on the MTA Filters mailing list at ietf-mta-filters@imc.org.

Subscription requests can be sent to ietf-mta-filters-request@imc.org (send an email message with the word "subscribe" in the body).

More information on the mailing list along with a WWW archive of back messages is available at http://www.imc.org/ietf-mta-filters.

At present, there is no mailing list or newsgroup for end users of Sieve.

Sieve History and Milestones

1994-95 informal meetings between the University of Washington and Carnegie Mellon University on IMAP issues touch upon mail filtering architecture. An initial architectural proposal is made for how server-side filtering of mail might work.
December 7, 1995 At IMSP BOF at 34th IETF Meeting at Dallas, Texas, discussion of Sieve-like architecture.
January 8, 1996 MTA Filtering special interest group meeting held at First International IMAP conference, University of Washington, Seattle. Significant discussion is belayed at this time in favor of more pressing internet mail issues.
June 24, 1996 36th IETF, Montreal, Canada - informal interest polled at the meeting of DRUMS (the working group resposible for revision of the RFC822 message standard and RFC821 SMTP standard).
November 7, 1996 MTA Filtering BOF meeting held at Second International IMAP conference, University of Washington, Seattle. This BOF was attended by over 40 persons from a variety of vendors, and was the first significant public discussion of the architecture by a fairly large number of internet mail server and client vendors.
December 12, 1996 37th IETF meeting in San Jose - informal BOF on mail filtering and SPAM [raw minutes]. This meeting started out as an informal discussion of anti-spamming techniques, and the need for a distinct, standardized language for server-side filtering was discussed. The conclusion was that this should be pursued as a separate activity. Participants of the November IMAP meeting not also at this meeting were notified of this by private mail.
January 11, 1997 mta-filters mailing list established at Internet Mail Consortium; first posting.
January 15, 1997 Strawman taken on mta-filters mailing list to establish continued interest in standardization.
March 24, 1997 First International ACAP Meeting held in Pittsburgh, PA. First draft of Sieve specification reviewed in informal working group.
October 24, 1997 Second version of Sieve specification issued.
January 28, 1998 Third version of Sieve specification issued.
January 28, 1998 First version of Vacation Sieve extension specification issued.
Feburary 26, 1998 Second International ACAP Meeting held in San Diego, CA, hosted by Qualcomm, Inc. Sieve requirements for ACAP storage and transport were discussed.
March 31, 1998 First formal Sieve BOF meeting at 41st IETF, Los Angeles, California. [Official Minutes] The results of this meeting were that there was strong consensus that the general work should proceed as official standards-track work, while there was a mixture of opinion with respect to scope issues. It was decided here that a formal Working Group was probably not necessary, pending implementation of a revised specification. The slides for a presentation on the syntax of Sieve at the time (now obsolete) are available here (in PostScript format).
August 7, 1998 Fourth version of Sieve specification issued.
November 17, 1998 First version of IMAP Flags Sieve extension specification issued.
November 18, 1998 Fifth version of Sieve specification issued.
December 7, 1998 informal design meeting at 43rd IETF, Orlando, Florida. [Informal minutes are here.]
January 11, 1999 First open source sample implementation publically issued by Carnegie Mellon University.
February 24, 1999 Draft 007 of the Sieve spec posted to Internet Draft archive.
March 16, 1999 Second official Sieve BOF, 44th IETF, Minneapolis [Official Minutes]
June, 1999 Version 1.1 of CMU Sieve Release
July, 1999 Version 1.2 of CMU Sieve Release
July 14, 1999 Draft 008 of Sieve spec posted
September, 1999 Draft 009 of Sieve spec posted; "release candidate"
April, 2000 Draft 010 of Sieve spec: last call to mailing list
June, 2000 CMU Sieve release updated.
August, 2000 12th (last call) version of Sieve spec and 4th version of Vacation spec released. Other extension documents updated.
November 2000 IESG approves SIEVE as a Proposed Standard. Document sent to RFC editor for publication.
January, 2001 RFC 3028 issued; Sieve officially a standards-track document.
December 2002 RFC 3431 - Relational Tests extension published
September 2003 RFC 3598 - Subaddress extension published
February 2004 RFC 3685 - Spamtest/virustest extension published
October 2004 RFC 3894 - Copy without side effects extension published

About this Website

These pages are sponsored and maintained by ISAMET, Inc., as a general service to the community, to try to support development, standardization, and implementation of Sieve and related tools and standards. Copyright and ownership of any linked document, script, or other contributed piece remains the sole property of its original owner/author. ISAMET in no way makes any ownership claims, except as specifically listed for any items it may have contributed. In all cases, users of this website are asked to carefully look for the specific copyright language and restrictions of each individual document.