Subject: pre-draft for language

From: Tim Showalter <[email-masked]>
Date: Tue, 1 Apr 1997 22:50:43 -0500 (EST)

This is a draft for the filtering language.  I managed to fill in a few
examples, but there are still a lot of consistancy errors that arose from
making a lot of changes in the grammar.  I'm posting it anyway because I
believe it'll be better to actually let people see it.

If you find obvious errors, let me know.  I'm SURE there are places that are
not internally consistant.  I'll work on it more tomorrow.

Thanks ...

-- 
                                           Tim Showalter [email-masked]

Network Working Group                                       T. Showalter
Internet Draft                                           Carnegie Mellon
Document: draft-showalter-sieve-XX.txt                        March 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.

   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 deliver.  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 architechture, 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 lists), and

Showalter                                                       [Page 1]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   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.

Showalter                                                       [Page 2]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   Table of Contents

   This document is content-free.

Showalter                                                       [Page 3]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

0.   Known Weaknesses

   The following weaknesses will be addressed, probably by extensions to
   be issued with this draft.

   Several people want regular expressions.  It is my feeling that
   mostly only advanced users (mostly UNIX types) want regular
   expression support instead of globs.  I really want this in my
   filtering language, and will code it.  However, regexp support is
   gross and frequently creatively incompatible, so I have removed it
   from this draft.  I will write up an extension if I can find a
   reasonable way of documenting regular expressions (will probably
   borrow something from POSIX).

   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 architechture that dumps envelopes,
   or stores them in weird ways.

   "Detailed" addressing is not handled, and will likely be moved to an
   extension as it is not supported by all systems.  Detailed addressing
   is where, in address like [email-masked], the delivery system
   ignores the "+fmh" in the address, but leaves it to the filtering
   system to interpret.  A "detail" command will be added to match this;
   it can be handled in the draft as-is with suitable pattern matching
   on the to/cc field, but it requires env-to matching to get it really
   right.  This is a common practice on CMU's mail system, and the Cyrus
   IMAPD offers some support of it as it is, and it's a must for us.

   I had a section on a "support" test, but removed it.  The idea of
   support is that if a given extension is supported, the test is true,
   and you can call on the extension.  It is a neat idea, but introduces
   mystery grammatical constructs that cannot be reasonably resolved.  A
   "require" keyword is still useful, and has been added.

   Whitespace is for readability, and as such, should be reasonably easy
   to edit.  (Whitespace in computer-generated scripts will probably be
   single spaces and occasional newlines.)  But thanks to creative
   obscufation from modern operating systems in their definitions of
   ASCII, there is no platform-independant newline in a text editor,
   which will be useful for users editing source.  Proposed solution:
   since we generally don't care what the newline character is anyway,
   allow any newline character (or, in the case of real ASCII, the CRLF
   sequence) to be whitespace.  This has been the decision used in this
   document regarding whitespace.

   Commands can optionally end with a ";", and tests can optionally end
   with a ",".  This is a feature intended to allow for humans to mark

Showalter                                                       [Page 4]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   ends of commands, as I expect missing arguments for some commands
   will be a frequent source of error.  They are unnecessary and would
   be easily removed, but I'm partial to them.  Comments would be
   appreciated.

   I'm not sure if I have most of the technichal terms right.  I suspect
   they're IMAP-biased, and need to reflect mail more generally.  Any
   comments would be appreciated.

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 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 architechture.  It
   requires the use of [RFC822]-complant messages and support of
   multiple folders, but should work with a wide variety of systems.

   The language is powerful enough to be useful, but delibrately very
   limited in order to allow for a reasonably secure server-side
   filtering system.  The language is not Turing-complete, and provides
   no way to write a loop or a function.  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 seperate
   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 availible 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.

Showalter                                                       [Page 5]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   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.

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "CAN", and
   "MAY" in this document are to be interpreted as defined in [XXX].

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!!! JUST
   SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW!
   -----------------------------------------------------------

Showalter                                                       [Page 6]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

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
   control structure is taken.

2.2. Whitespace

   Whitespace seperates commands.  The amount of whitespace used in
   seperating commands is not important.  Whitespace includes tabs,
   newlines, and the space character.

2.3. Comments

   Comments begin with a "#" character that is not containted within a
   string and continue until the next newline.

2.4. Numbers

   Numbers are normally given in the form of decimal numbers.  However,
   those numbers that have a tendancy 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 base-two-based versions of SI units that
   computers frequently use, K specifies kilo, or 1,024 times the value
   of the number; M specifies mega, or 1,048,576 times the value of the
   number; and G specifies giga, or1,073,741,824 times the value of the
   number.

2.5. Strings

   Scripts involve large numbers of strings.  Typically, short quoted
   strings suffice for most uses, but a more conveinent form is provided
   for longer strings.

   A quoted string starts and ends with a single double quote (the ").
   A backslash (" backslash or a double quote.  This two-character
   sequence represents a single backslash or double-quote within the
   string.

   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 considered to begin with ".".

Showalter                                                       [Page 7]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   Example:    if any-of (header ("from") contains
                  ("bart" "homer" "smithers" "burns" "lisa")
               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.6. Addresses

   A number of commands call for email addresses.  These addresses must
   be compliant with [RFC822].  Implementations 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 produce any actions, as in the
   following script with message A above:

   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" on many
   implementations).

   Implementations define the specific meanings of actions.  Implementa-
   tions may impose restrictions on the actions taken, such as only
   honoring one "reply", "bounce", or "forward" per message.

   Precedence is not important in any of the commands in this base
   specification.  However, as an extension might make it more impor-
   tant, 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, respectively) MAY do so.

3.   Conditionals and Control Structures

Showalter                                                       [Page 8]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   In order for a script to do more than one set of actions, control
   structures 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 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, sends mail to
   [email-masked]; message B, to [email-masked]; and message
   C, to [email-masked].

   Example:    XXX
               XXX

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, supplied as a string, MUST be present in order to
   allow further processing.  If the string specifies an extension that
   the evaluating mechanism supports, then processing continues.  Other-
   wise, an error has been encountered, and the script should not be

Showalter                                                       [Page 9]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   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.

   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, resend, 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 endif

   4.2.   Action fileinto

   Syntax:     fileinto <folder>

   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 modifies the envelope.

   A simple script can be used for forwarding:

Showalter                                                      [Page 10]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   Example:    forward "[email-masked]"

4.4. Action normal

   Syntax:     normal

   The "normal" action is whatever action is taken in leiu 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 explicitally, providing a way to use it
   independant of system.

   Syntax:     if size under 1MB then normal else toss

4.5. Action reply

   Syntax:     reply <message>

   The "reply" action is used to generate a form letter reply to the
   original sender.  Message is XXXXXXXXX

   Example:    if size over 500K reply message
               Your message was unnecessarily large.
               I reject all large messages; you will need to contact me
               directly.
               else normal endif

   OPEN: Specify headers transmitted?  Specify number of days before
   considered valid/invalid?
4.6. Action resend

   Syntax:     resend <address>

   The "resend" action resends a message to the supplied address, adding
   the appropriate Resent-From: and Resent-To: headers.  Other than a
   few added headers, the "resend" function is expected to make no
   changes to the message body or headers, leaving the message mostly
   untouched.

   Example
        if subject "cyrus" then resend "[email-masked]" endif

4.7. Action stop The "stop" action ends all processing.  If no actions
   have been executed, then the normal action is taken.

   Example:    if (header "from" matches "[email-masked]")
                    then forward "[email-masked]"; endif stop
               endif reply "I'm on vacation and not taking any messages;

Showalter                                                      [Page 11]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

               try again in a week."

4.8. Action toss Toss drops the message.

   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.X. 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.X. 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. . false

   Syntax:     false

5.X. header

   Syntax:     header <header-name-list>
               <"contains"/"is"/"matches"/"contains-nocase" / "is-

Showalter                                                      [Page 12]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

               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
   matching 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 insensi-
   tive 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 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 heard-
   ers 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

   "" matches all strings that exist.

5.B. not

   Syntax:
        not <test>

   The "not" test takes some other test, and returns the opposite
   result.

5.Q. 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

Showalter                                                      [Page 13]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   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.X. true

   Syntax:
        true

   The "true" test is always true.

5.X. valid

   Syntax:
        valid

   The "valid" test is true if the message satisfies the basic criteria
   for an [RFC822] compliant message.  At a minimum, the message must
   have valid a valid "To" header, a valid "From" or "Sender" header,
   where the field in the address contains an email address of the form
   "user@host", and host is a valid domain record.

   The intention of the "valid" test is to drop messages that do not fit
   the basic requirements of an [RFC822] compliant message, but made it
   to final delivery none the less.

   [I'm not sure exactly what requirements should be imposed, but this
   one might be very useful for weeding out joke messages from
   [email-masked] that happen whenever the freshman class fig-
   ures out how to forge mail, or spams that don't bother having valid
   return addresses.]

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 try to make
   forward process.

Showalter                                                      [Page 14]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   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 preferrable alterna-
   tive cannot be found

   Implentations 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 oversending error messages to the user's mailbox.

   Implementations that allow client-based filtering (i.e., use this
   language to implement filtering from a POP server into local mail
   folders) must notify the user of syntax errors, and should allow the
   user to file mail into their main mailbox on request.  If mail is
   processed without user intervention (as part of a background test,
   with long periods of time in between user intervention) the implenta-
   tion MUST file mail into the main mailbox.

7.   Extensibility

   New control structures, actions, and tests can be added to the
   language.  Sites must make these features known to their users; an
   extension negotiation 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" condi-
   tional, which mandates that script requires the use of that exten-
   sion.  Additionally, in a situation where there is a submission pro-
   tocol and an extsension advertisement mechanism, so that scripts sub-
   mitted can be checked against the mail server for valid extensions.

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

Showalter                                                      [Page 15]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   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, 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 pri-
   mary mailbox.

9.   Acknowledgements

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 whitespace (that is, CR, LF, spaces, and tabs), as described by
   the "WSP" terminal, and not a single comma.

   In the case of alternative or optional rules in which a later rule
   overlaps an earlier rule, the rule which is listed earlier MUST take
   priority.

   action ::= toss / fileinto / forward / bounce / reply / resend /
       stop / extension-action

   address ::= string
           ;; any legal RFC822 address

   any-of ::= "any-of" WSP "(" [WSP] condition *([","] condition) [WSP] ")"

   all-of ::= "all-of" WSP "(" [WSP] condition *([","] condition) [WSP] ")"

   big-number ::= number [ UNIT ]

   bounce ::= "bounce"

   control-structure ::= if / extension-control-structure

   command ::= action [WSP] [";"] / control-structure

   commands ::= #(command)

   comment ::= "#" *CHAR CRLF

   CHAR ::= <any ASCII/UTF-8 character>

Showalter                                                      [Page 16]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   CR ::= <ASCII CR, carriage return, 0x0D>

   CRLF ::= CR LF

   DIGIT ::= "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

   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

   include ::= "include" WSP url

   header ::=

   LF ::= <ASCII LF, line feed, 0x0A>

   newline ::= CR[LF] / LF
           ;; A CRLF is ALWAYS one newline.
           ;; XXX there's a better way to specify this!

   number ::= 1*DIGIT

   or ::= condition WSP "or" WSP condition

   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 .

   resend ::= "resend" WSP string

   size ::= "size" WSP ( "over" / "under" ) WSP big-number

   stop ::= "stop"

   string ::= ( "
           ;;
           ;; \ inside a string maps to
   string-list ::= "(" [WSP] *string [WSP] ")"

Showalter                                                      [Page 17]

draft-showalter-sieve-XX.txt     SIEVE                       20 Mar 1997

   test ::= [WSP] any-of / all-of / false / header / not /
       size / extension-test [WSP]

   UNIT ::= "K" / "M" / "G"
           ;; kilobytes, megabytes, or gigabytes; the B is optional

   url ::= string

   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

   Tim Showalter
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   E-Mail: [email-masked]

   Appendix A.   References

   [ABNF]

   [ACAP]

   [IMAP]

   [RFC822]

   [XXX]

Showalter                                                      [Page 18]