Subject: sieve draft

From: Tim Showalter <[email-masked]>
Date: Mon, 14 Apr 1997 21:05:10 -0400 (EDT)

This is the latest draft of the SIEVE filtering language.  I've also dropped
a copy at http://www.club.cc.cmu.edu/~tjs/draft-showalter-sieve-00.txt.  I'm
in the process of submitting a copy as an internet-draft.

I plan to do some heavy editoral changes, but I think it's close to complete
in terms of content and features.  Rob has been bugging me to make a good
clean distinction between keywords and commands, and that should happen
before this becomes an RFC.

Any comments would be appreciated!

-- 
                                           Tim Showalter [email-masked]

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 "[email-masked]") 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: [email-masked]
   To: [email-masked]
   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: [email-masked]
   To: [email-masked]
   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: [email-masked]" is equivalent to
"From    :    [email-masked]".  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
[email-masked]; message B, to [email-masked]; any other mes-
sage is forwarded to [email-masked].

Example:    if header ("") contains ("") then
                 forward "[email-masked]";
            elsif header ("Subject") contains ("$$$") then
                 forward "[email-masked]";
            else
                 forward "[email-masked]";
            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 ("[email-masked]")
            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 "[email-masked]"

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
"[email-masked]" it is forwarded to "[email-masked]"; otherwise
the mail receives a reply, and is thrown out.

Example:    if (header ("from") matches ("[email-masked]"))
                 then forward "[email-masked]"; 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 "[email-masked]" is thrown out.

Example:    if header ("from") contains ("[email-masked]") 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 ("[email-masked]")
     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: [email-masked]

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]