Folks, there is work ongoing within the IETF to define a general
purpose filtering scheme for email. Rather than inventing some adhoc
system we should be following their work. If you're interested in this
you want to get onto the MTA-FILTERS mailing list:
echo subscribe ietf-mta-filters | mail majordomo@imc.org.
I've appended a copy of the current filtering language draft.
--lyndon
Network Working Group T. Showalter
Internet Draft Carnegie Mellon
Document: draft-showalter-sieve-00.txt April 1997
Expire sometime after it's released
SIEVE: A Mail Filtering Language
Status of this Memo
This draft has no standing and is for limited distribution. Please
do not implement anything within without contacting the author, and
even then, use extreme caution; everything in this draft is carved in
warm butter. Please use discretion in distribution.
The following is here for when we actually publish this:
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
The protocol discussed in this document is experimental and subject
to change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before
embarking on such a project.
Abstract
This document describes a mail filtering language for filtering
messages at time of final delivery. It is designed to be independent
of protocol, and implementable on either a mail client or mail server
which uses multiple folders. It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
systems used to implement it.
Mail filtering systems are widely used for a variety of reasons,
including organization of messages (filtering out mailing list
Showalter [Page 1]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
messages for separate reading). They are becoming increasingly
useful in avoiding unsolicited mail. Existing languages are not
consistant across client, server, or operating system, and are
frequently difficult for users to use. This language is not tied to
any particular system or mail architecture and is suitable for
running on a mail server where users may not be allowed to execute
arbitrary programs, such as on black box IMAP servers.
Showalter [Page 2]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
Table of Contents
This document is content-free.
Showalter [Page 3]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
0. Unfinished
0.1. Known Weaknesses
The following suggestions have been made, and will probably be
addressed by extensions.
An extension for regular expressions will be written. While regular
expressions are of questionable usefulness for users, the programmers
writing implementations desperately want regular expressions.
Envelope-matching commands are not readily supported by all mail
systems, and putting them in the draft will result in a system that
cannot be implemented by a mail architecture that does not adequately
store envelopes.
"Detailed" addressing or "subaddressing" (i.e., the "fmh" in an
address "tjs+fmh@andrew.cmu.edu") is not handled, and will be moved
to an extension for those systems that offer it.
The newline problem is relatively, but not completely, solved. We'll
be arguing this until the end of time.
A previous version included a "valid" test. I have tentatively
removed it because Randy had noted it was too fuzzy to implement, and
that's probably true.
The formal grammar is not complete, and needs to be revised to make
the best use of ABNF, whatever its final state is.
My knowledge of email is not comprehensive, and as a result, there
might be a better way to express some of the concepts in here.
An "include" command is not included, but has been suggested for an
extension.
I need to run a spelling checker on this document.
I hate nroff.
0.2. Open Issues
Do "fileinto" commands need to be moved to a separate document?
1. Introduction
There are a number of reasons to use a filtering system. Mail
traffic for most users has been increasing due both to increased
Showalter [Page 4]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
usage of e-mail, the emergence of unsolicited email as a form of
advertising, and increased usage of mailing lists.
This language is offered in order to try and provide a standard
language that can be used to create filters for e-mail. It is not
tied to any particular operating system or mail architecture. It
requires the use of [IMAIL]-compliant messages and support of
multiple folders, but should work with a wide variety of systems that
support these criteria.
The language is powerful enough to be useful, but limited in power in
order to allow for a reasonably bulletproof server-side filtering
system. The language is not Turing-complete, and provides no way to
write a loop or a function, nor are variables are provided. The
intention is to make it impossible for users to do anything more
complex than write simple mail filters.
Implementations of the language are expected to take place at time of
final delivery. In systems where the MTA does final delivery --
IMAP4 and traditional UNIX mail, for instance, it is reasonable to
sort when the MTA deposits mail into the user's mailbox. If the MTA
does not do final delivery, or lacks the power to sort into separate
mailboxes (as is the case under POP3), the MUA must do filtering into
local filters.
Experience at Carnegie Mellon has shown that if a filtering system is
made available to users, many will make use of it in order to file
messages from specific users or mailing lists. However, many users
did not make use of the Andrew system's FLAMES filtering language due
to difficulty in programming it. Due to this expectation, this
language has been made simple enough to allow many users to make use
of it.
1.1. Conventions used in this document
Line breaks have been inserted for readability.
In the sections of this document that discuss the requirements of
various keywords and operators, the following conventions have been
adopted.
Each section on an test, action, or conditional has a line labeled
"Syntax:". This line describes the arguments each command requires.
Required arguments are listed inside angle brackets ("<" and ">").
Optional arguments are listed inside square brackets ("[" and "]").
The formal grammar for these commands is described in section 10 and
is the authoritative reference on how to construct these commands.
Showalter [Page 5]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
"MAY" in this document are to be interpreted as defined in
[KEYWORDS].
1.2. Example mail messages
The following mail messages will be used throughout this document in
examples.
Message A
-----------------------------------------------------------
Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
From: coyote@anvil.dementia.org
To: roadrunner@birdseed.thekeep.org
Subject: I have a present for you
Look, I'm sorry about the whole anvil thing, but I can make
it up to you. I've got some great birdseed over here at
my place -- top of the line stuff -- and if you come by,
I'll have it all wrapped up for you. I'm really sorry for
all the problems I've caused for you over the years, and
I know we can work this out.
-----------------------------------------------------------
Message B
-----------------------------------------------------------
From: youcouldberich!@reply-by-postal-mail
Sender: b1ff@znic.net
To: rube@znic.net
Date: Mon, 31 Mar 1997 18:26:10 -0800 (PST)
Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$
YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT
IT! SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS! IT WILL
GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY!
MONEY! MONEY! COLD HARD CASH! YOU WILL RECEIVE OVER
$20,000 IN LESS THAN TWO MONTHS! AND IT'S LEGAL!!!!!!!!!
!!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 JUST
SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
-----------------------------------------------------------
2. Design
2.1. Form of the language
This language is made up as a set of commands. Each command is
either an action or a conditional. Each conditional contains a test;
depending on the results of the test, one set of commands in a
Showalter [Page 6]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
control structure is taken.
2.2. Whitespace
Whitespace is used to separate commands. Whitespace is made up of
tabs, newlines (which can be CR, LF, or both), and the space
character. The amount of whitespace used is not significant.
2.3. Comments
Comments begin with a "#" character that is not contained within a
string and continue until the next newline.
Example: if size over 100K then # this is a comment
toss
endif
2.4. Numbers
Numbers are normally given as ordinary decimal numbers.
However, those numbers that have a tendency to be fairly
large, such as message sizes, such as message sizes, may
have a "K", "M", or "G" appended to indicate a multiple
of a base-two number. To be comparable with the power-
of-two-based versions of SI units that computers fre-
quently use, K specifies kilo, or 1,024 (2^10) times the
value of the number; M specifies mega, or 1,048,576
(2^20) times the value of the number; and G specifies
giga, or 1,073,741,824 (2^30) times the value of the
number.
Numbers are limited to 32 bits by this specification.
[OPEN: If numbers are limited to 32 bits, gigabit-sized
numbers probably aren't very useful. Should I remove
them?]
2.5. Strings
Scripts involve large numbers of strings. Typically,
short quoted strings suffice for most uses, but a more
convenient form is provided for longer strings.
A quoted string starts and ends with a single double
quote (the " character). A backslash ("\") inside of a
quoted string is followed by either another backslash or
a double quote. This two-character sequence represents a
Showalter [Page 7]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
single backslash or double-quote within the string. [If
there are missing words in the paragraph, I had problems
with nroff; please point it out to me.]
For entering larger amounts of text, such as an email
message, a longer form is allowed, known as a "user-
message". It starts with the keyword "message" and ends
with the sequence of a newline, a single period, and
another newline. Any line that begins with ".." is con-
sidered to begin with ".".
XXX this example needs formatting work
Example: if any-of (header ("from") contains
("bart" "homer" "smithers" "burns" "lisa") then
header ("subject") contains ("URGENT")) then
fileinto "INBOX"
else
reply message
You are not one of the people I regularly correspond with.
I have deleted your message due to the large volume of
email I regularly receive. If you feel that you need to
speak with me directly, and cannot find your answer in my
web pages, please send mail with the word "URGENT" in the
subject line. Thank you for your time.
[ONE SINGLE DOT, which I can't get nroff to produce
...]
endif
2.5.1. Headers
[OPEN ISSUE: Is this section necessary or useful?]
Headers are a subset of strings. In the Internet Message Specification
[IMAIL], each header line is allowed to have whitespace nearly anywhere
in the line, including after the field name and before the subsequent
colon. Thus, the lines "From: acm@andrew.cmu.edu" is equivalent to
"From : acm@andrew.cmu.edu". Within a SIEVE script, header names
are never considered to have spaces. Only the "From" in the above
headers is considered to be there. While a header can be listed as
"From " within a header list (say, for the "header" command) such
usage is absurd. The following colon is never specified; a header
"From:", as well as a header ":From", is guaranteed never to happen
within a valid header.
2.5.2. Addresses
Showalter [Page 8]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
[OPEN ISSUE: Is this section necessary or useful?]
A number of commands call for email addresses, which are also a subset
of strings. These addresses must be compliant with [IMAIL]. Implemen-
tations MUST insure the addresses are syntactically valid, and need not
insure that they are actually deliverable.
2.7. Evaluation
If evaluation of the script fails to file the message into any mailbox,
as in the following script, the message is filed into INBOX. With any
of the short messages offered above, the following script produces no
actions.
Example: if size over 500K then toss endif
then the "normal" action is taken. The "normal" action is defined to be
the action that is taken normally, such as in a situation where the user
does no filtering. Under most situations, the normal action is to file
into the user's main mailbox (such as "INBOX" under IMAP).
Implementations define the specific meanings of actions. Implementa-
tions may impose restrictions on the actions taken, such as only honor-
ing one "reply", "bounce", or "forward" per message.
Precedence is not important in any of the commands in this base specifi-
cation. However, as an extension might make it more important, all
rules MUST be evaluated in left-to-right order. Those operations that
may implement short-circuit evaluation (such as the "all-of" and "any-
of" operators, which preform logical "and" and "or" operations, respec-
tively) SHOULD do so.
3. Conditionals and Control Structures
In order for a script to do more than one set of actions, control struc-
tures are needed.
3.1. If
Syntax: if <test> then <commands>
[elsif <elsif-test> then <elsif-commands> [elsif ...]]
[else <else-commands>]
endif
The "if" control structure is borrowed from any number of programming
languages. It is evaluated in the usual way, as follows: if <test> is
true, then <commands> are evaluated. If an elsif keyword exists, and
<next-test> is true, then <elsif-commands> are evaluated. Any number of
Showalter [Page 9]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
elsif cases may be included, and are evaluated serially. If <test> is
false and the <elsif-test>s are false as well, then the <else-commands>
are evaluated. The "if" block is terminated with an "endif" keyword,
which is required.
In the following example, both Message A and B are dropped.
Example: if header ("from") contains ("coyote") then
toss
elsif header ("subject") contains ("$$$")
then toss
else fileinto "INBOX"
endif
Only one set of commands in an if ... elsif ... elsif ... else ...
endif block is executed.
In the script below, when run over message A, forwards the message to
acm@andrew.cmu.edu; message B, to service@andrew.cmu.edu; any other mes-
sage is forwarded to postman@andrew.cmu.edu.
Example: if header ("") contains ("") then
forward "acm@andrew.cmu.edu";
elsif header ("Subject") contains ("$$$") then
forward "service@andrew.cmu.edu";
else
forward "postman@andrew.cmu.edu";
endif
3.2. Require
Syntax: require <extension-name>
Require SHOULD be declared in a user script before an extension is used.
It instructs the evaluator that the extension named extension-name, sup-
plied as a string, MUST be present in order to allow further processing.
If the string specifies an extension that the evaluating mechanism sup-
ports, then processing continues. Otherwise, an error has been encoun-
tered, and the script should not be evaluated.
Require is intended to demand the use of an extension not present in
this document.
The following example will fail on any server that does not implement
the extension known as DWIM.
Showalter [Page 10]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
Example: require "dwim"; if header ("subject") contains-nocase ("the
secret message") then
dwim blurdybloop body;
endif stop
4. Actions This document supplies six actions that may be taken on a
message: normal, fileinto, forward, bounce, toss, and stop.
4.1. Action bounce
Syntax: bounce
The "bounce" action resends the message to the sender, wrapping it in a
"bounce" form, noting that it was rejected by the recipient. In the
following script, message A is bounced to the sender.
Example: if header ("from") contains ("coyote@anvil.dementia.org")
then
bounce "I am not taking mail from you, you killer!"
endif
4.2. Action fileinto
Syntax: fileinto <folder>
[OPEN ISSUE: I could be talked into making fileinto optional for POP3
server agents that wanted to simply throw mail out and then do user
filtering on the client.]
The "fileinto" action drops the message into a named folder. In the
following script, message A is filed into folder "INBOX.harassment".
Example: if header ("to") contains
4.3. Action forward
Syntax: forward <address>
The "forward" action is used to forward the message to another user at
the supplied address, as a mail forwarding feature does. The "forward"
action makes no changes to the message body or headers, and only modi-
fies the envelope.
A simple script can be used for forwarding:
Example: forward "tjs@andrew.cmu.edu"
Showalter [Page 11]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
4.4. Action normal
Syntax: normal
The "normal" action is whatever action is taken in lieu of all other
actions; generally, this simply means to drop the message into the
user's normal mailbox. This command provides a way to execute this
action without naming it explicitly, providing a way to use it indepen-
dent of system.
Syntax: if size under 1M then normal else toss
4.5. Action reply
Syntax: reply <message>
The "reply" action is used to generate a form letter reply to the origi-
nal sender. Message is a string to be sent as a reply message. The
multi-line <user-message> production described in the Formal Grammar
section is intended for this purpose. In the following example, any
message over 500K (or 512,000 octets) would be thrown out; otherwise,
the message would be filed into INBOX.
Example: if size over 500K reply message
Your message was unnecessarily large.
I reject all large messages; you will need to contact me
directly.
toss
endif
OPEN: Specify headers transmitted?
OPEN: Specify way to do vacation? A previous version of this had a
-days switch to specify number of days to do a new reply.
4.6. Action stop The "stop" action ends all processing. If no actions
have been executed, then the normal action is taken.
In the following script, if the mail is from the address
"wall@andrew.cmu.edu" it is forwarded to "tjs@xanadu.wv.us"; otherwise
the mail receives a reply, and is thrown out.
Example: if (header ("from") matches ("wall@andrew.cmu.edu"))
then forward "tjs@xanadu.wv.us"; stop
endif reply "I'm on vacation and not taking any messages;
try after Sunday. I have thrown your message out. Please
resend it later." ; toss
Showalter [Page 12]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
4.7. Action toss Toss drops the message. In the following script, any
mail from "wall@andrew.cmu.edu" is thrown out.
Example: if header ("from") contains ("wall@andrew.cmu.edu") then
toss endif
5. Tests
Tests are used in conditionals to decide which part(s) of the condi-
tional to execute.
5.1. all-of
Syntax: all-of ( <test> [,] <test> [,] ... <test> )
The all-of test preforms a logical AND on the tests supplied to it.
The comma in between tests is optional.
Example: all-of (false false) => false
all-of (false true) => false
all-of (true, true) => true
5.2. any-of
Syntax: all-of ( <test> [,] <test> [,] ... <test> )
The any-of test preforms a logical OR on the tests supplied to it.
The comma in between tests is optional.
Example: all-of (false false) => false
all-of (false true) => true
all-of (true, true) => true
5.3. exists
Syntax: exists <header-name-list>
The "exists" test is true if the headers listed in the <header-name-
list> argument exist within the message. All of the headers must exist
or the test is false.
Showalter [Page 13]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
Example: if not exists ("From" "Date" "Subject" "To" "Message-ID")
then
toss
endif
5.4. false
Syntax: false
The "false" test always evaluates to false.
5.5. header
Syntax: header <header-name-list>
<"contains"/"is"/"matches"/"contains-nocase" / "is-
nocase"/"matches-nocase"> <key-list>
The "header" test evaluates to true if the header name matches key. How
the match is done is described by the second argument. The basic match-
ing forms are case sensitive. Each matching form has a corresponding
form ending in "-nocase"; these are not case sensitive.
All matchings on header field names MUST be done in a case insensitive
manner.
The "is" argument demands that one of the fields of the headers listed
in header-name-list can be found in the key-list. It requires an abso-
lute match. It is true if there are repeated arguments in the header-
name-list or the key-list.
The "contains" argument demands that one of the values of the headers
named in header-name-list partially matches one of the values in key-
list. It is true if there are repeated arguments in the header-name-
list or the key-list. The string "" is contained in any header that
exists.
The "matches" argument demands that one of the fields of the headers
listed in header-name-list matches a "glob" pattern described by one of
the members of key-list. A glob pattern is a UNIX-style filename glob,
which has the following special characters:
* Match zero or more characters
? Match any single character
Escape next character
The string "" matches all strings that exist. That is, if a message
Showalter [Page 14]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
contains the line [XXX formatted improperly]
X-Blurdybloop: death to the heathens
the tests on that header evaluate as follows:
header ("X-Blurdyblop") is ("") => false
header ("X-Blurdyblop") matches ("") => true
header ("X-Blurdyblop") contains ("") => true
5.6. not
Syntax:
not <test>
The "not" test takes some other test, and returns the opposite result.
5.7. size
Syntax:
size <"over" / "under"> <limit [quantifier]>
The "size" test deals with the size of a message. The test is true only
if the second argument is "over" and the size of the message is strictly
greater than the number of octets specified as limit. If the second
argument is "under", then the test is true only if the message size is
strictly less than the number of octets specified as limit. In either
case, if the message size is exactly the limit, the test is false.
The size of a message is defined to be the number of octets from the
initial header until the last character in the message body.
5.8. support
Syntax:
support <extension-name>
The "support" test evaluates to true if the extension named by
<extension-name> is supported. In the following script, all mail is
filed into INBOX unless the "black-magic" extension is supported. Oth-
erwise, behavior is defined by the black-magic extension.
Syntax:
if support "black-magic" then
black-magic ("kgb@andrew.cmu.edu")
endif
Showalter [Page 15]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
5.9. true
Syntax:
true
The "true" test is always true.
6. Errors in Processing a Script
In any sort of programming language, even a very simple one, errors are
inevitable. In this case, users are expected to make errors -- even if
the actual script is machine-generated, mailbox rights might change to
disallow users from writing to a mailbox, a mailbox may no longer exist,
or a variety of other problems. It is imperative that mail be allowed
to get through in any case.
If an error is found in a script, an implementation MUST make an attempt
to resolve the condition. Implementations SHOULD check a script before
it is run in order to insure that it is valid. Implementations SHOULD
NOT try and recover from a script with errors, and should file mail into
the user's primary mailbox.
Users MUST be notified of errors in processing a script. The method by
which users are notified is implementation defined, but a mail message
describing the error is suggested if a preferable alternative cannot be
found
Implementations that allow for the script to be checked for syntax
errors in advance of mail receipt (i.e., client-based filtering, or
server-based filtering with a submission protocol aware of this
language) SHOULD notify the user of the error and refuse to accept a
syntactically invalid script, or one that makes use of extensions that
the server does not report.
Implementations that allow server-based filtering (i.e., as part of an
IMAP server) MUST allow mail to be filed normally (i.e., for IMAP, into
the user's INBOX) in case of a syntax error in the script, and MUST
notify the user of an error in some form (such as sending the user a
mail message notifying them of the error). Implementations SHOULD avoid
over-sending error messages to the user's mailbox.
Implementations are REQUIRED to notify users of errors in filtering
scripts. If there are errors in the script being used, mail SHOULD be
filed into INBOX. Implementations MUST NOT discard mail.
7. Extensibility
New control structures, actions, and tests can be added to the language.
Showalter [Page 16]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
Sites must make these features known to their users; an extension nego-
tiation mechanism is not defined by this document.
For the formal grammar, an extension SHOULD define one of the symbols
beginning with "extension-".
Any extensions to this language MUST define a unique string that
describes that extension. Such strings SHOULD include a version number.
The purpose of such a string is for the "require" and "support" condi-
tionals, which mandates that script requires the use of that extension.
Additionally, in a situation where there is a submission protocol and an
extension advertisement mechanism, so that scripts submitted can be
checked against the mail server for valid extensions.
7.1. Capability Mechanism
[A brief description of the capability string will be included here.]
7.2. Registry
[A registration mechanism will be included here.]
7.3. Capability Transport
[A brief description of what is required for a capability transport will
be defined here. Transports will be defined in separate documents.]
8. Transmission
This document does not define a method for accessing stored scripts at
run-time or as they are written, nor does it define a character set
encoding for scripts.
If the method of handing a script off to the server allows for MIME-
typing of data as described in [MIME] and the data is encoded in UTF-8
as described in [UTF-8], the MIME type for a SIEVE script is XXX/XXX.
Implementations SHOULD check a script before it is run in order to
insure that it is valid. Implementations SHOULD NOT try and recover
from a script with errors, and should file mail into the user's primary
mailbox.
9. Acknowledgments
10. Formal Grammar
The grammar used in this section is the same as the ABNF described in
[ABNF] with one exception: the delimiter used with "#" is any amount of
Showalter [Page 17]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
whitespace (that is, CR, LF, spaces, and tabs), as described by the
"WSP" terminal, followed by a single comma, and additional whitespace.
Two commas without something in between them is a protocol error, and is
prohibited.
In the case of alternative or optional rules in which a later rule over-
laps an earlier rule, the rule which is listed earlier MUST take prior-
ity.
action = toss / fileinto / forward / bounce / reply / stop /
extension-action
address = string
;; any legal IMAIL address
any-of = "any-of" WSP "(" [WSP] #(condition) [WSP] ")"
all-of = "all-of" WSP "(" [WSP] #(condition) [WSP] ")"
big-number = number [ UNIT ]
bounce = "bounce" WSP string
;; string is a text message to be sent with the bounce as the
;; reason
control-structure = if / extension-control-structure
command = action [WSP] ";" [WSP] / control-structure
commands = #(command)
comment = "#" *CHAR newline
fileinto = "fileinto" WSP string
forward = "forward" WSP address
if = "if" WSP test WSP "then" WSP commands WSP #("elsif" WSP
test WSP "then" WSP commands) [ "else" WSP commands WSP ]
"endif"
;; if <cond> then <commands>
;; [elsif <cond> then <commands> [elsif ...]]
;; [else <commands>] endif
header = "header" WSP string-list WSP match-keyword WSP string-list
match-keyword = "contains" / "matches" / "is" / "contains-nocase" /
"contains-nocase" / "is-nocase"
Showalter [Page 18]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
newline = CRLF / CR / LF
;; A CRLF is ALWAYS one newline.
number = 1*DIGIT
or = condition WSP "or" WSP condition
quoted-string = "
;;
;; \ inside a string maps to ;; Note that newlines and other weird characters
;; are all strings.
size = "size" WSP ( "over" / "under" ) WSP big-number
stop = "stop"
string = quoted-string / user-message
string-list = "(" [WSP] #(string) [WSP] ")"
test = [WSP] any-of / all-of / exists / false / header /
not / size / extension-test [WSP]
UNIT = "K" / "M" / "G"
;; kilobytes, megabytes, or gigabytes
user-message = "message" [WSP] newline "." newline
;; note when used,
;; a CR that is not followed by an LF becomes a CRLF;
;; an LF that is not followed by a CR becomes a CRLF.
;; a leading .. on a line is mapped to .
WSP = " " / CR / LF / tab
;; just whitespace
10. Security Considerations Users must get their mail. It is impera-
tive that whatever method implementations use to store the user-defined
filtering scripts be reasonably secure.
It is equally important that implementations sanity-check the user's
scripts, and not allow users to create on-demand mailbombs. For
instance, an implementation that allows a user to bounce, forward, or
reply multiple times to a single message might also allow a user to
create a mailbomb triggered by mail from a specific user.
11. Author's Address
Showalter [Page 19]
draft-showalter-sieve-PRE.txt SIEVE 8 Apr 1997
Tim Showalter
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213
E-Mail: tjs@andrew.cmu.edu
Appendix A. References
[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
Internet Mail Consortium, Work in Progress.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Require-
ment Levels", RFC 2119, Harvard University, March 1997.
[IMAP] Crispin, M., "Internet Mail Access Protocol - version 4rev1", RFC
2060, University of Washington, December 1996.
[IMAIL] Crocker, D., "Standard for the Format of ARPA Internet Text Mes-
sages", STD 11, RFC 822, University of Delaware, August 1982.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[UTF-8] Yergeau, F. "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, Alis Technologies, October 1996.
Showalter [Page 20]