Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_s_z/draft-showalter-sieve-00.txt

Text File | 1997-04-18 | 36KB | 1,065 lines

Network Working Group                                       T. Showalter
Internet Draft                                           Carnegie Mellon
Document: draft-showalter-sieve-00.txt                        April 1997
Expire in six months (10/97)

                    SIEVE: A Mail Filtering Language

Status of this Memo

   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
   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 1]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


   Table of Contents

   This document is content-free.
















































Showalter                                                       [Page 2]

draft-showalter-sieve-00.txt     SIEVE                        April 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 "[e-mail]") 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 3]

draft-showalter-sieve-00.txt     SIEVE                        April 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 4]

draft-showalter-sieve-00.txt     SIEVE                        April 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: [e-mail]
   To: [e-mail]
   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: [e-mail]
   To: [e-mail]
   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 5]

draft-showalter-sieve-00.txt     SIEVE                        April 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 6]

draft-showalter-sieve-00.txt     SIEVE                        April 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"),
                    header ("subject") contains ("URGENT")) then
                    fileinto "INBOX"
               else
                    reply message # multi-line message here:
               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.
               , <-- XXX should be a "."  \.
               endif


   2.5.1. Headers

   [OPEN ISSUE: Is this section necessary or useful?]

   Headers are a subset of strings.  In the Internet Message Specifica-
   tion [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: [e-mail]" is
   equivalent to "From    :    [e-mail]".  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 7]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


   [OPEN ISSUE: Is this section necessary or useful?]

   A number of commands call for email addresses, which are also a sub-
   set of strings.  These addresses must be compliant with [IMAIL].
   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 file the message into any mail-
   box, 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
   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) SHOULD do so.

3.   Conditionals and Control Structures

   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



Showalter                                                       [Page 8]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


   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, forwards the message to
   [e-mail]; message B, to [e-mail]; any other
   message is forwarded to [e-mail].

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

draft-showalter-sieve-00.txt     SIEVE                        April 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 ("[e-mail]")
               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 modifies the envelope.

   A simple script can be used for forwarding:

   Example:    forward "[e-mail]"




Showalter                                                      [Page 10]

draft-showalter-sieve-00.txt     SIEVE                        April 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
   independent 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
   original 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 exam-
   ple, 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
   "[e-mail]" it is forwarded to "[e-mail]"; other-
   wise the mail receives a reply, and is thrown out.

   Example:    if (header ("from") matches ("[e-mail]"))
                    then forward "[e-mail]"; 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 11]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


4.7. Action toss Toss drops the message.  In the following script, any
   mail from "[e-mail]" is thrown out.

   Example:    if header ("from") contains ("[e-mail]") 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 12]

draft-showalter-sieve-00.txt     SIEVE                        April 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
   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 requires
   an absolute 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 13]

draft-showalter-sieve-00.txt     SIEVE                        April 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.
   Otherwise, behavior is defined by the black-magic extension.


   Syntax:
        if support "black-magic" then



Showalter                                                      [Page 14]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


             black-magic ("[e-mail]")
        endif


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.  Imple-
   mentations 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.



Showalter                                                      [Page 15]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


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" and "sup-
   port" conditionals, which mandates that script requires the use of
   that extension.  Additionally, in a situation where there is a sub-
   mission 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 docu-
   ments.]

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




Showalter                                                      [Page 16]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


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 whitespace (that is, CR, LF, spaces, and tabs), as described by
   the "WSP" terminal, followed by a single comma, and additional whi-
   tespace.  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
   overlaps an earlier rule, the rule which is listed earlier MUST take
   priority.

   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 ...]]



Showalter                                                      [Page 17]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


           ;; [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"

   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



Showalter                                                      [Page 18]

draft-showalter-sieve-00.txt     SIEVE                        April 1997


   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: [e-mail]

   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
   Requirement 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
   Messages", 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 19]