Sieve (mail filtering language)
Original author(s) | University of Washington and Carnegie Mellon University[1] and standardized by Tim Showalter |
---|---|
Initial release | 1999[1] |
Operating system | Cross-platform |
Type | Email filtering |
Website | sieve |
Sieve is a programming language that can be used for email filtering. It owes its creation to the CMU Cyrus Project, creators of Cyrus IMAP server.
The language is not tied to any particular operating system or mail architecture. It requires the use of RFC-2822–compliant messages, but otherwise should generalize to other systems that meet these criteria. The current version of Sieve's base specification is outlined in RFC 5228, published in January 2008.
Language[]
Sieve is a data-driven programming language, similar to earlier email filtering languages such as procmail and maildrop, and earlier line-oriented languages such as sed and AWK: it specifies conditions to match and actions to take on matching.
This differs from general-purpose programming languages in that it is highly limited – the base standard has no variables, and no loops (but does allow conditional branching), preventing runaway programs and limiting the language to simple filtering operations. Although extensions have been devised to extend the language to include variables and, to a limited degree, loops, the language is still highly restricted, and thus suitable for running user-devised programs as part of the mail system.
There are also a significant number of restrictions on the grammar of the language, in order to reduce the complexity of parsing the language, but the language also supports the use of multiple methods for comparing localized strings, and is fully Unicode-aware.
While Sieve was originally conceived as tool external to SMTP,[2][3] RFC 5429 serendipitously extends it in order to allow rejection at the SMTP protocol level.[4]
Use[]
The Sieve scripts may be generated by a GUI-based rules editor or they may be entered directly using a text editor.
The scripts are transferred to the mail server in a server-dependent way. The ManageSieve protocol (defined in RFC 5804) allows users to manage their Sieve scripts on a remote server. Mail servers with local users may allow the scripts to be stored in e.g. a .sieve file in the users' home directories.
History[]
The language was standardized in the (now-obsolete) RFC 3028 of January 2001, by Tim Showalter.
Extensions[]
The IETF Sieve working group[5] has updated the base specification in 2008 (RFC 5228), and has brought the following extensions to Proposed Standard status:
- RFC 5173 – Body; allows a script to test the body of a message, not just its header.
- RFC 5229 – Variables; allows the script to save and retrieve values in variables.
- RFC 5230 – Vacation; specifies an action to send a response informing the sender that the recipient may be away.
- RFC 5231 – Relational tests; defines numeric tests, so that a script may test a field for a numeric value, and may test against the number of occurrences of a field.
- RFC 5232 – IMAP4flags; allows a script to test and set a message's IMAP flags.
- RFC 5233 – Subaddress; allows a script to test subaddresses of the form "user+detail@domain.example".
- RFC 5235 – Spamtest and Virustest; allows a script to interface with implementation-dependent message filtering.
- RFC 5260 – Date and Index Extensions.
- RFC 5293 – Editheader; allows a script to add and delete message header fields.
- RFC 5429 – Reject; allows messages to be rejected at either the LMTP/SMTP level or with an MDN or DSN.
- RFC 5435 – Notifications; allows a script to trigger external notifications of email.
- RFC 5436 – E-mail notifications; specifies notifications via e-mail.
- RFC 5437 – XMPP notifications; specifies notifications via XMPP.
- RFC 5490 – Checking; Mailbox status and accessing mailbox metadata.
- RFC 5703 – MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure
- RFC 5804 - A Protocol for Remotely Managing Sieve Scripts
A number of other extensions are still being developed by the Sieve working group.[citation needed]
Example[]
This is an example sieve script:
# Sieve filter
# Declare the extensions used by this script.
#
require ["fileinto", "reject"];
# Messages bigger than 100K will be rejected with an error message
#
if size :over 100K {
reject "I'm sorry, I do not accept mail over 100kb in size.
Please upload larger files to a server and send me a link.
Thanks.";
}
# Mails from a mailing list will be put into the folder "mailinglist"
#
elsif address :is ["From", "To"] "mailinglist@blafasel.invalid" {
fileinto "INBOX.mailinglist";
}
# Spam Rule: Message does not contain my address in To, CC or BCC
# header, or subject is something with "money" or "Viagra".
#
elsif anyof (not address :all :contains ["To", "Cc", "Bcc"] "me@blafasel.invalid",
header :matches "Subject" ["*money*","*Viagra*"]) {
fileinto "INBOX.spam";
}
# Keep the rest.
# This is not necessary because there is an "implicit keep" rule
#
else {
keep;
}
See also[]
References[]
- ^ Jump up to: a b http://sieve.info/history
- ^ That Sieve operates after message acceptance is in its defining document: P. Guenther; T. Showalter (January 2008). Sieve: An Email Filtering Language. IETF. doi:10.17487/RFC5228. RFC 5228.
it is reasonable to filter when the MTA deposits mail into the user's mailbox
- ^ That final delivery is outside SMTP is in its defining document: John Klensin (October 2008). "Trace Information". Simple Mail Transfer Protocol. IETF. sec. 4.4. doi:10.17487/RFC5321. RFC 5321.
final delivery means the message has left the SMTP environment
- ^ Aaron Stone (March 2009). "Rejecting a Message at the SMTP/LMTP Protocol Level". Sieve Email Filtering: Reject and Extended Reject Extensions. IETF. sec. 2.1.1. doi:10.17487/RFC5429. RFC 5429.
- ^ Sieve working group charter Archived 2005-12-31 at the Wayback Machine
External links[]
- Sieve.Info, a Wiki Site about Sieve
- The old Sieve Home Page on web.archive.org
- RFC 5228 (Base Specification about Sieve)
- Sieve IETF Working Group Charter
- Sieve tutorial with many examples
- Spam filtering