rfc3028.txt

RFC 的详细文档！

   argument exist within the message.  All of the headers must exist or
   the test is false.

   The following example throws out mail that doesn't have a From header
   and a Date header.

   Example:  if not exists ["From","Date"] {
                discard;
             }

5.6.     Test false

   Syntax:   false

   The "false" test always evaluates to false.

5.7.     Test header

   Syntax:   header [COMPARATOR] [MATCH-TYPE]
             <header-names: string-list> <key-list: string-list>

   The "header" test evaluates to true if any header name matches any
   key.  The type of match is specified by the optional match argument,
   which defaults to ":is" if not specified, as specified in section
   2.6.

   Like address and envelope, this test returns true if any combination
   of the string-list and key-list arguments match.

   If a header listed in the header-names argument exists, it contains
   the null key ("").  However, if the named header is not present, it
   does not contain the null key.  So if a message contained the header

           X-Caffeine: C8H10N4O2







Showalter                   Standards Track                    [Page 25]

RFC 3028            Sieve: A Mail Filtering Language        January 2001


   these tests on that header evaluate as follows:

           header :is ["X-Caffeine"] [""]         => false
           header :contains ["X-Caffeine"] [""]   => true

5.8.     Test not

   Syntax:   not <test>

   The "not" test takes some other test as an argument, and yields the
   opposite result.  "not false" evaluates to "true" and "not true"
   evaluates to "false".

5.9.     Test size

   Syntax:   size <":over" / ":under"> <limit: number>

   The "size" test deals with the size of a message.  It takes either a
   tagged argument of ":over" or ":under", followed by a number
   representing the size of the message.

   If the argument is ":over", and the size of the message is greater
   than the number provided, the test is true; otherwise, it is false.

   If the argument is ":under", and the size of the message is less than
   the number provided, the test is true; otherwise, it is false.

   Exactly one of ":over" or ":under" must be specified, and anything
   else is an error.

   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.

   Note that for a message that is exactly 4,000 octets, the message is
   neither ":over" 4000 octets or ":under" 4000 octets.

5.10.    Test true

   Syntax:   true

   The "true" test always evaluates to true.

6.      Extensibility

   New control structures, actions, and tests can be added to the
   language.  Sites must make these features known to their users; this
   document does not define a way to discover the list of extensions
   supported by the server.



Showalter                   Standards Track                    [Page 26]

RFC 3028            Sieve: A Mail Filtering Language        January 2001


   Any extensions to this language MUST define a capability string that
   uniquely identifies that extension.  If a new version of an extension
   changes the functionality of a previously defined extension, it MUST
   use a different name.

   In a situation where there is a submission protocol and an extension
   advertisement mechanism aware of the details of this language,
   scripts submitted can be checked against the mail server to prevent
   use of an extension that the server does not support.

   Extensions MUST state how they interact with constraints defined in
   section 2.10, e.g., whether they cancel the implicit keep, and which
   actions they are compatible and incompatible with.

6.1.     Capability String

   Capability strings are typically short strings describing what
   capabilities are supported by the server.

   Capability strings beginning with "vnd." represent vendor-defined
   extensions.  Such extensions are not defined by Internet standards or
   RFCs, but are still registered with IANA in order to prevent
   conflicts.  Extensions starting with "vnd." SHOULD be followed by the
   name of the vendor and product, such as "vnd.acme.rocket-sled".

   The following capability strings are defined by this document:

   envelope    The string "envelope" indicates that the implementation
               supports the "envelope" command.

   fileinto    The string "fileinto" indicates that the implementation
               supports the "fileinto" command.

   reject      The string "reject" indicates that the implementation
               supports the "reject" command.

   comparator- The string "comparator-elbonia" is provided if the
               implementation supports the "elbonia" comparator.
               Therefore, all implementations have at least the
               "comparator-i;octet" and "comparator-i;ascii-casemap"
               capabilities.  However, these comparators may be used
               without being declared with require.









Showalter                   Standards Track                    [Page 27]

RFC 3028            Sieve: A Mail Filtering Language        January 2001


6.2.     IANA Considerations

   In order to provide a standard set of extensions, a registry is
   provided by IANA.  Capability names may be registered on a first-
   come, first-served basis.  Extensions designed for interoperable use
   SHOULD be defined as standards track or IESG approved experimental
   RFCs.

6.2.1.     Template for Capability Registrations

   The following template is to be used for registering new Sieve
   extensions with IANA.

   To: [e-mail]
   Subject: Registration of new Sieve extension

   Capability name:
   Capability keyword:
   Capability arguments:
   Standards Track/IESG-approved experimental RFC number:
   Person and email address to contact for further information:

6.2.2.     Initial Capability Registrations

   The following are to be added to the IANA registry for Sieve
   extensions as the initial contents of the capability registry.

   Capability name:        fileinto
   Capability keyword:     fileinto
   Capability arguments:   fileinto <folder: string>
   Standards Track/IESG-approved experimental RFC number:
           RFC 3028 (Sieve base spec)
   Person and email address to contact for further information:
           Tim Showalter
           [e-mail]

   Capability name:        reject
   Capability keyword:     reject
   Capability arguments:   reject <reason: string>
   Standards Track/IESG-approved experimental RFC number:
           RFC 3028 (Sieve base spec)
   Person and email address to contact for further information:
           Tim Showalter
           [e-mail]







Showalter                   Standards Track                    [Page 28]

RFC 3028            Sieve: A Mail Filtering Language        January 2001


   Capability name:        envelope
   Capability keyword:     envelope
   Capability arguments:
           envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
           <envelope-part: string-list> <key-list: string-list>
   Standards Track/IESG-approved experimental RFC number:
           RFC 3028 (Sieve base spec)
   Person and email address to contact for further information:
           Tim Showalter
           [e-mail]

   Capability name:        comparator-*
   Capability keyword:
           comparator-* (anything starting with "comparator-")
   Capability arguments:   (none)
   Standards Track/IESG-approved experimental RFC number:
           RFC 3028, Sieve, by reference of
           RFC 2244, Application Configuration Access Protocol
   Person and email address to contact for further information:
           Tim Showalter
           [e-mail]

6.3.     Capability Transport

   As the range of mail systems that this document is intended to apply
   to is quite varied, a method of advertising which capabilities an
   implementation supports is difficult due to the wide range of
   possible implementations.  Such a mechanism, however, should have
   property that the implementation can advertise the complete set of
   extensions that it supports.

7.      Transmission

   The MIME type for a Sieve script is "application/sieve".

   The registration of this type for RFC 2048 requirements is as
   follows:

    Subject: Registration of MIME media type application/sieve

    MIME media type name: application
    MIME subtype name: sieve
    Required parameters: none
    Optional parameters: none
    Encoding considerations: Most sieve scripts will be textual,
       written in UTF-8.  When non-7bit characters are used,
       quoted-printable is appropriate for transport systems
       that require 7bit encoding.



Showalter                   Standards Track                    [Page 29]

RFC 3028            Sieve: A Mail Filtering Language        January 2001


    Security considerations: Discussed in section 10 of RFC 3028.
    Interoperability considerations: Discussed in section 2.10.5
       of RFC 3028.
    Published specification: RFC 3028.
    Applications which use this media type: sieve-enabled mail servers
    Additional information:
      Magic number(s):
      File extension(s): .siv
      Macintosh File Type Code(s):
    Person & email address to contact for further information:
       See the discussion list at [e-mail].
    Intended usage:
       COMMON
    Author/Change controller:
       See Author information in RFC 3028.

8.      Parsing

   The Sieve grammar is separated into tokens and a separate grammar as
   most programming languages are.

8.1.     Lexical Tokens

   Sieve scripts are encoded in UTF-8.  The following assumes a valid
   UTF-8 encoding; special characters in Sieve scripts are all ASCII.

   The following are tokens in Sieve:

           - identifiers
           - tags
           - numbers
           - quoted strings
           - multi-line strings
           - other separators

   Blanks, horizontal tabs, CRLFs, and comments ("white space") are
   ignored except as they separate tokens.  Some white space is required
   to separate otherwise adjacent tokens and in specific places in the
   multi-line strings.

   The other separators are single individual characters, and are
   mentioned explicitly in the grammar.

   The lexical structure of sieve is defined in the following BNF (as
   described in [ABNF]):






Showalter                   Standards Track                    [Page 30]

RFC 3028            Sieve: A Mail Filtering Language        January 2001


   bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/"
           ;; No */ allowed inside a comment.
           ;; (No * is allowed unless it is the last character,
           ;; or unless it is followed by a character that isn't a
           ;; slash.)

   CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff)
           ;; no dots, no CRLFs

   CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff)

   CHAR-NOT-SLASH = (%x00-57 / %x58-ff)

   CHAR-NOT-STAR = (