draft-ietf-sieve-3028bis-04.txt   draft-ietf-sieve-3028bis-05.txt 
Network Working Group P. Guenther Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: January 2006 T. Showalter Expires: May 2006 T. Showalter
Obsoletes: 3028 (if approved) Editors Obsoletes: 3028 (if approved) Editors
July 2005 November 2005
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-04.txt draft-ietf-sieve-3028bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 4, line 39 skipping to change at page 4, line 39
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
In the sections of this document that discuss the requirements of In the sections of this document that discuss the requirements of
various keywords and operators, the following conventions have been various keywords and operators, the following conventions have been
adopted. adopted.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS]. in this document are to be interpreted as defined in [KEYWORDS].
Each section on a command (test, action, or control) has a line Each section on a command (test, action, or control) has a line
labeled "Syntax:". This line describes the syntax of the command, labeled "Usage:". This line describes the usage of the command,
including its name and its arguments. Required arguments are listed including its name and its arguments. Required arguments are listed
inside angle brackets ("<" and ">"). Optional arguments are listed inside angle brackets ("<" and ">"). Optional arguments are listed
inside square brackets ("[" and "]"). Each argument is followed by inside square brackets ("[" and "]"). Each argument is followed by
its type, so "<key: string>" represents an argument called "key" that its type, so "<key: string>" represents an argument called "key" that
is a string. Literal strings are represented with double-quoted is a string. Literal strings are represented with double-quoted
strings. Alternatives are separated with slashes, and parenthesis strings. Alternatives are separated with slashes, and parenthesis
are used for grouping, similar to [ABNF]. are used for grouping, similar to [ABNF].
In the "Syntax" line, there are three special pieces of syntax that In the "Usage:" line, there are three special pieces of syntax that
are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART. are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART.
These are discussed in sections 2.7.1, 2.7.3, and 2.7.4, These are discussed in sections 2.7.1, 2.7.3, and 2.7.4,
respectively. respectively.
The formal grammar for these commands in section 10 and is the The formal grammar for these commands in section 10 and is the
authoritative reference on how to construct commands, but the formal authoritative reference on how to construct commands, but the formal
grammar does not specify the order, semantics, number or types of grammar does not specify the order, semantics, number or types of
arguments to commands, nor the legal command names. The intent is to arguments to commands, nor the legal command names. The intent is to
allow for extension without changing the grammar. allow for extension without changing the grammar.
skipping to change at page 11, line 46 skipping to change at page 11, line 46
For instance, the string "frobnitzm" contains "frob" and "nit", but For instance, the string "frobnitzm" contains "frob" and "nit", but
not "fbm". The empty key ("") is contained in all values. not "fbm". The empty key ("") is contained in all values.
The ":is" match type describes an absolute match; if the contents of The ":is" match type describes an absolute match; if the contents of
the first string are absolutely the same as the contents of the the first string are absolutely the same as the contents of the
second string, they match. Only the string "frobnitzm" is the string second string, they match. Only the string "frobnitzm" is the string
"frobnitzm". The empty key ":is" and only ":is" the empty value. "frobnitzm". The empty key ":is" and only ":is" the empty value.
The ":matches" match type specifies a wildcard match using the The ":matches" match type specifies a wildcard match using the
characters "*" and "?"; the entire value must be matched. "*" characters "*" and "?"; the entire value must be matched. "*"
matches zero or more characters, and "?" matches a single character. matches zero or more characters, and "?" matches a single character,
"?" and "*" may be escaped as "\\?" and "\\*" in strings to match using the definition of character appropriate for the comparator in
against themselves. The first backslash escapes the second use. That is, "?" will match exactly one octet when the "i;octet" or
backslash; together, they escape the "*". This is awkward, but it is "en;ascii-casemap" comparators are used, but will match the one or
commonplace in several programming languages that use globs and more octets that compose a character in UTF-8 when the
regular expressions. "i;basic;uca=3.1.1;uv=3.2" comparator is used. "?" and "*" may be
escaped as "\\?" and "\\*" in strings to match against themselves.
The first backslash escapes the second backslash; together, they
escape the "*". This is awkward, but it is commonplace in several
programming languages that use globs and regular expressions.
In order to specify what type of match is supposed to happen, In order to specify what type of match is supposed to happen,
commands that support matching take optional tagged arguments commands that support matching take optional tagged arguments
":matches", ":is", and ":contains". Commands default to using ":is" ":matches", ":is", and ":contains". Commands default to using ":is"
matching if no match type argument is supplied. Note that these matching if no match type argument is supplied. Note that these
modifiers may interact with comparators; in particular, some modifiers interact with comparators; in particular, only comparators
comparators are not suitable for matching with ":contains" or that supoprt the "substring match" operation are suitable for
":matches". It is an error to use a comparator with ":contains" or matching with ":contains" or ":matches". It is an error to use a
":matches" that is not compatible with it. comparator with ":contains" or ":matches" that is not compatible with
it.
It is an error to give more than one of these arguments to a given It is an error to give more than one of these arguments to a given
command. command.
For convenience, the "MATCH-TYPE" syntax element is defined here as For convenience, the "MATCH-TYPE" syntax element is defined here as
follows: follows:
Syntax: ":is" / ":contains" / ":matches" Syntax: ":is" / ":contains" / ":matches"
2.7.2. Comparisons Across Character Sets 2.7.2. Comparisons Across Character Sets
All Sieve scripts are represented in UTF-8, but messages may involve All Sieve scripts are represented in UTF-8, but messages may involve
a number of character sets. In order for comparisons to work across a number of character sets. In order for comparisons to work across
character sets, implementations SHOULD implement the following character sets, implementations SHOULD implement the following
behavior: behavior:
Comparisons are performed in Unicode. Implementations convert Comparisons are performed on octets. Implementations convert text
text from header fields in all charsets [MIME3] to Unicode as from header fields in all charsets [MIME3] to Unicode, encoded as
input to the comparator (see 2.7.3). Implementations MUST be UTF-8, as input to the comparator (see 2.7.3). Implementations
capable of converting US-ASCII, ISO-8859-1, the US-ASCII subset of MUST be capable of converting US-ASCII, ISO-8859-1, the US-ASCII
ISO-8859-* character sets, and UTF-8. Text that the subset of ISO-8859-* character sets, and UTF-8. Text that the
implementation cannot convert to Unicode for any reason MAY be implementation cannot convert to Unicode for any reason MAY be
treated as plain US-ASCII (including any [MIME3] syntax) or treated as plain US-ASCII (including any [MIME3] syntax) or
processed according to local conventions. An encoded NUL octet processed according to local conventions. An encoded NUL octet
(character zero) SHOULD NOT cause early termination of the header (character zero) SHOULD NOT cause early termination of the header
content being compared against. content being compared against.
If implementations fail to support the above behavior, they MUST If implementations fail to support the above behavior, they MUST
conform to the following: conform to the following:
No two strings can be considered equal if one contains octets No two strings can be considered equal if one contains octets
skipping to change at page 12, line 47 skipping to change at page 13, line 4
(character zero) SHOULD NOT cause early termination of the header (character zero) SHOULD NOT cause early termination of the header
content being compared against. content being compared against.
If implementations fail to support the above behavior, they MUST If implementations fail to support the above behavior, they MUST
conform to the following: conform to the following:
No two strings can be considered equal if one contains octets No two strings can be considered equal if one contains octets
greater than 127. greater than 127.
2.7.3. Comparators 2.7.3. Comparators
In order to allow for language-independent, case-independent matches, In order to allow for language-independent, case-independent matches,
the match type may be coupled with a comparator name. The Internet the match type may be coupled with a comparator name. The Internet
Application Protocol Collation Registry [COLLATION] provides the Application Protocol Collation Registry [COLLATION] provides the
framework for describing and naming comparators as used by this framework for describing and naming comparators as used by this
specification. specification.
While multiple comparator types are defined, only equality types are
used in this specification.
All implementations MUST support the "i;octet" comparator (simply All implementations MUST support the "i;octet" comparator (simply
compares octets), the "en;ascii-casemap" comparator (which treats compares octets), the "en;ascii-casemap" comparator (which treats
uppercase and lowercase characters in the US-ASCII subset of UTF-8 as uppercase and lowercase characters in the US-ASCII subset of UTF-8 as
the same), as well as the "i;ascii-casemap" comparator, which is a the same), as well as the "i;ascii-casemap" comparator, which is a
deprecated synonym for "en;ascii-casemap". If left unspecified, the deprecated synonym for "en;ascii-casemap". If left unspecified, the
default is "en;ascii-casemap". default is "en;ascii-casemap".
Some comparators may not be usable with substring matches; that is, Some comparators may not be usable with substring matches; that is,
they may only work with ":is". It is an error to try and use a they may only work with ":is". It is an error to try and use a
comparator with ":matches" or ":contains" that is not compatible with comparator with ":matches" or ":contains" that is not compatible with
skipping to change at page 18, line 8 skipping to change at page 18, line 13
Control structures are needed to allow for multiple and conditional Control structures are needed to allow for multiple and conditional
actions. actions.
3.1. Control If 3.1. Control If
There are three pieces to if: "if", "elsif", and "else". Each is There are three pieces to if: "if", "elsif", and "else". Each is
actually a separate command in terms of the grammar. However, an actually a separate command in terms of the grammar. However, an
elsif or else MUST only follow an if or elsif. An error occurs if elsif or else MUST only follow an if or elsif. An error occurs if
these conditions are not met. these conditions are not met.
Syntax: if <test1: test> <block1: block> Usage: if <test1: test> <block1: block>
Syntax: elsif <test2: test> <block2: block> Usage: elsif <test2: test> <block2: block>
Syntax: else <block3: block> Usage: else <block3: block>
The semantics are similar to those of any of the many other The semantics are similar to those of any of the many other
programming languages these control structures appear in. When the programming languages these control structures appear in. When the
interpreter sees an "if", it evaluates the test associated with it. interpreter sees an "if", it evaluates the test associated with it.
If the test is true, it executes the block associated with it. If the test is true, it executes the block associated with it.
If the test of the "if" is false, it evaluates the test of the first If the test of the "if" is false, it evaluates the test of the first
"elsif" (if any). If the test of "elsif" is true, it runs the "elsif" (if any). If the test of "elsif" is true, it runs the
elsif's block. An elsif may be followed by an elsif, in which case, elsif's block. An elsif may be followed by an elsif, in which case,
the interpreter repeats this process until it runs out of elsifs. the interpreter repeats this process until it runs out of elsifs.
skipping to change at page 19, line 13 skipping to change at page 19, line 19
} else { } else {
redirect "field@example.edu"; redirect "field@example.edu";
} }
Note that this definition prohibits the "... else if ..." sequence Note that this definition prohibits the "... else if ..." sequence
used by C. This is intentional, because this construct produces a used by C. This is intentional, because this construct produces a
shift-reduce conflict. shift-reduce conflict.
3.2. Control Require 3.2. Control Require
Syntax: require <capabilities: string-list> Usage: require <capabilities: string-list>
The require action notes that a script makes use of a certain The require action notes that a script makes use of a certain
extension. Such a declaration is required to use the extension, as extension. Such a declaration is required to use the extension, as
discussed in section 2.10.5. Multiple capabilities can be declared discussed in section 2.10.5. Multiple capabilities can be declared
with a single require. with a single require.
The require command, if present, MUST be used before anything other The require command, if present, MUST be used before anything other
than a require can be used. An error occurs if a require appears than a require can be used. An error occurs if a require appears
after a command other than require. after a command other than require.
Example: require ["fileinto", "reject"]; Example: require ["fileinto", "reject"];
Example: require "fileinto"; Example: require "fileinto";
require "vacation"; require "vacation";
3.3. Control Stop 3.3. Control Stop
Syntax: stop Usage: stop
The "stop" action ends all processing. If no actions have been The "stop" action ends all processing. If no actions have been
executed, then the keep action is taken. executed, then the keep action is taken.
4. Action Commands 4. Action Commands
This document supplies four actions that may be taken on a message: This document supplies four actions that may be taken on a message:
keep, fileinto, redirect, and discard. keep, fileinto, redirect, and discard.
Implementations MUST support the "keep", "discard", and "redirect" Implementations MUST support the "keep", "discard", and "redirect"
actions. actions.
Implementations SHOULD support "fileinto". Implementations SHOULD support "fileinto".
Implementations MAY limit the number of certain actions taken (see Implementations MAY limit the number of certain actions taken (see
section 2.10.4). section 2.10.4).
4.1. Action fileinto 4.1. Action fileinto
Syntax: fileinto <folder: string> Usage: fileinto <folder: string>
The "fileinto" action delivers the message into the specified folder. The "fileinto" action delivers the message into the specified folder.
Implementations SHOULD support fileinto, but in some environments Implementations SHOULD support fileinto, but in some environments
this may be impossible. this may be impossible.
The capability string for use with the require command is "fileinto". The capability string for use with the require command is "fileinto".
In the following script, message A is filed into folder In the following script, message A is filed into folder
"INBOX.harassment". "INBOX.harassment".
Example: require "fileinto"; Example: require "fileinto";
if header :contains ["from"] "coyote" { if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment"; fileinto "INBOX.harassment";
} }
4.2. Action redirect 4.2. Action redirect
Syntax: redirect <address: string> Usage: redirect <address: string>
The "redirect" action is used to send the message to another user at The "redirect" action is used to send the message to another user at
a supplied address, as a mail forwarding feature does. The a supplied address, as a mail forwarding feature does. The
"redirect" action makes no changes to the message body or existing "redirect" action makes no changes to the message body or existing
headers, but it may add new headers. The "redirect" modifies the headers, but it may add new headers. The "redirect" modifies the
envelope recipient. envelope recipient.
The redirect command performs an MTA-style "forward"--that is, what The redirect command performs an MTA-style "forward"--that is, what
you get from a .forward file using sendmail under UNIX. The address you get from a .forward file using sendmail under UNIX. The address
on the [SMTP] envelope is replaced with the one on the redirect on the [SMTP] envelope is replaced with the one on the redirect
skipping to change at page 20, line 45 skipping to change at page 20, line 51
A simple script can be used for redirecting all mail: A simple script can be used for redirecting all mail:
Example: redirect "bart@example.edu"; Example: redirect "bart@example.edu";
Implementations SHOULD take measures to implement loop control, Implementations SHOULD take measures to implement loop control,
possibly including adding headers to the message or counting received possibly including adding headers to the message or counting received
headers. If an implementation detects a loop, it causes an error. headers. If an implementation detects a loop, it causes an error.
4.3. Action keep 4.3. Action keep
Syntax: keep Usage: keep
The "keep" action is whatever action is taken in lieu of all other The "keep" action is whatever action is taken in lieu of all other
actions, if no filtering happens at all; generally, this simply means actions, if no filtering happens at all; generally, this simply means
to file the message into the user's main mailbox. This command to file the message into the user's main mailbox. This command
provides a way to execute this action without needing to know the provides a way to execute this action without needing to know the
name of the user's main mailbox, providing a way to call it without name of the user's main mailbox, providing a way to call it without
needing to understand the user's setup, or the underlying mail needing to understand the user's setup, or the underlying mail
system. system.
For instance, in an implementation where the Internet Message Access For instance, in an implementation where the Internet Message Access
Protocol (IMAP) server is running scripts on behalf of the user at Protocol (IMAP) server is running scripts on behalf of the user at
time of delivery, a keep command is equivalent to a fileinto "INBOX". time of delivery, a keep command is equivalent to a fileinto "INBOX".
Example: if size :under 1M { keep; } else { discard; } Example: if size :under 1M { keep; } else { discard; }
Note that the above script is identical to the one below. Note that the above script is identical to the one below.
Example: if not size :under 1M { discard; } Example: if not size :under 1M { discard; }
4.4. Action discard 4.4. Action discard
Syntax: discard Usage: discard
Discard is used to silently throw away the message. It does so by Discard is used to silently throw away the message. It does so by
simply canceling the implicit keep. If discard is used with other simply canceling the implicit keep. If discard is used with other
actions, the other actions still happen. Discard is compatible with actions, the other actions still happen. Discard is compatible with
all other actions. (For instance fileinto+discard is equivalent to all other actions. (For instance fileinto+discard is equivalent to
fileinto.) fileinto.)
Discard MUST be silent; that is, it MUST NOT return a non-delivery Discard MUST be silent; that is, it MUST NOT return a non-delivery
notification of any kind ([DSN], [MDN], or otherwise). notification of any kind ([DSN], [MDN], or otherwise).
skipping to change at page 22, line 9 skipping to change at page 22, line 14
Tests are used in conditionals to decide which part(s) of the Tests are used in conditionals to decide which part(s) of the
conditional to execute. conditional to execute.
Implementations MUST support these tests: "address", "allof", Implementations MUST support these tests: "address", "allof",
"anyof", "exists", "false", "header", "not", "size", and "true". "anyof", "exists", "false", "header", "not", "size", and "true".
Implementations SHOULD support the "envelope" test. Implementations SHOULD support the "envelope" test.
5.1. Test address 5.1. Test address
Syntax: address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] Usage: address [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<header-list: string-list> <key-list: string-list> <header-list: string-list> <key-list: string-list>
The address test matches Internet addresses in structured headers The address test matches Internet addresses in structured headers
that contain addresses. It returns true if any header contains any that contain addresses. It returns true if any header contains any
key in the specified part of the address, as modified by the key in the specified part of the address, as modified by the
comparator and the match keyword. Whether there are other addresses comparator and the match keyword. Whether there are other addresses
present in the header doesn't affect this test; this test does not present in the header doesn't affect this test; this test does not
provide any way to determine whether an address is the only address provide any way to determine whether an address is the only address
in a header. in a header.
skipping to change at page 22, line 46 skipping to change at page 22, line 51
contain addresses, but MUST include at least From, To, Cc, Bcc, contain addresses, but MUST include at least From, To, Cc, Bcc,
Sender, Resent-From, Resent-To, and SHOULD include any other header Sender, Resent-From, Resent-To, and SHOULD include any other header
that utilizes an "address-list" structured header body. that utilizes an "address-list" structured header body.
Example: if address :is :all "from" "tim@example.com" { Example: if address :is :all "from" "tim@example.com" {
discard; discard;
} }
5.2. Test allof 5.2. Test allof
Syntax: allof <tests: test-list> Usage: allof <tests: test-list>
The allof test performs a logical AND on the tests supplied to it. The allof test performs a logical AND on the tests supplied to it.
Example: allof (false, false) => false Example: allof (false, false) => false
allof (false, true) => false allof (false, true) => false
allof (true, true) => true allof (true, true) => true
The allof test takes as its argument a test-list. The allof test takes as its argument a test-list.
5.3. Test anyof 5.3. Test anyof
Syntax: anyof <tests: test-list> Usage: anyof <tests: test-list>
The anyof test performs a logical OR on the tests supplied to it. The anyof test performs a logical OR on the tests supplied to it.
Example: anyof (false, false) => false Example: anyof (false, false) => false
anyof (false, true) => true anyof (false, true) => true
anyof (true, true) => true anyof (true, true) => true
5.4. Test envelope 5.4. Test envelope
Syntax: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] Usage: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list> <envelope-part: string-list> <key-list: string-list>
The "envelope" test is true if the specified part of the SMTP (or The "envelope" test is true if the specified part of the SMTP (or
equivalent) envelope matches the specified key. This specification equivalent) envelope matches the specified key. This specification
defines the interpretation of the (case insensitive) "from" and "to" defines the interpretation of the (case insensitive) "from" and "to"
envelope-parts. Additional envelope-parts may be defined by other envelope-parts. Additional envelope-parts may be defined by other
extensions; implementations SHOULD consider unknown envelope parts an extensions; implementations SHOULD consider unknown envelope parts an
error. error.
If one of the envelope-part strings is (case insensitive) "from", If one of the envelope-part strings is (case insensitive) "from",
skipping to change at page 24, line 18 skipping to change at page 24, line 24
The envelope command is optional. Implementations SHOULD support it, The envelope command is optional. Implementations SHOULD support it,
but the necessary information may not be available in all cases. but the necessary information may not be available in all cases.
Example: require "envelope"; Example: require "envelope";
if envelope :all :is "from" "tim@example.com" { if envelope :all :is "from" "tim@example.com" {
discard; discard;
} }
5.5. Test exists 5.5. Test exists
Syntax: exists <header-names: string-list> Usage: exists <header-names: string-list>
The "exists" test is true if the headers listed in the header-names The "exists" test is true if the headers listed in the header-names
argument exist within the message. All of the headers must exist or argument exist within the message. All of the headers must exist or
the test is false. the test is false.
The following example throws out mail that doesn't have a From header The following example throws out mail that doesn't have a From header
and a Date header. and a Date header.
Example: if not exists ["From","Date"] { Example: if not exists ["From","Date"] {
discard; discard;
} }
5.6. Test false 5.6. Test false
Syntax: false Usage: false
The "false" test always evaluates to false. The "false" test always evaluates to false.
5.7. Test header 5.7. Test header
Syntax: header [COMPARATOR] [MATCH-TYPE] Usage: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list> <header-names: string-list> <key-list: string-list>
The "header" test evaluates to true if any header name matches any The "header" test evaluates to true if the value of any of the named
key. The type of match is specified by the optional match argument, headers, ignoring leading and trailing whitespace, matches any key.
which defaults to ":is" if not specified, as specified in section The type of match is specified by the optional match argument, which
2.6. defaults to ":is" if not specified, as specified in section 2.6.
Like address and envelope, this test returns true if any combination Like address and envelope, this test returns true if any combination
of the header-names list and key-list arguments match and false of the header-names list and key-list arguments match and false
otherwise. otherwise.
If a header listed in the header-names argument exists, it contains If a header listed in the header-names argument exists, it contains
the empty key (""). However, if the named header is not present, it the empty key (""). However, if the named header is not present, it
does not match any key, including the empty key. So if a message does not match any key, including the empty key. So if a message
contained the header contained the header
skipping to change at page 25, line 21 skipping to change at page 25, line 28
header :is ["X-Caffeine"] [""] => false header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true header :contains ["X-Caffeine"] [""] => true
The preferred way to test whether a given header is either empty or The preferred way to test whether a given header is either empty or
absent is to combine an "exists" test and a "header" test: absent is to combine an "exists" test and a "header" test:
anyof (header :is "Cc" "", not exists "Cc") anyof (header :is "Cc" "", not exists "Cc")
5.8. Test not 5.8. Test not
Syntax: not <test1: test> Usage: not <test1: test>
The "not" test takes some other test as an argument, and yields the The "not" test takes some other test as an argument, and yields the
opposite result. "not false" evaluates to "true" and "not true" opposite result. "not false" evaluates to "true" and "not true"
evaluates to "false". evaluates to "false".
5.9. Test size 5.9. Test size
Syntax: size <":over" / ":under"> <limit: number> Usage: size <":over" / ":under"> <limit: number>
The "size" test deals with the size of a message. It takes either a The "size" test deals with the size of a message. It takes either a
tagged argument of ":over" or ":under", followed by a number tagged argument of ":over" or ":under", followed by a number
representing the size of the message. representing the size of the message.
If the argument is ":over", and the size of the message is greater 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. 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 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. the number provided, the test is true; otherwise, it is false.
skipping to change at page 26, line 4 skipping to change at page 26, line 9
Exactly one of ":over" or ":under" must be specified, and anything Exactly one of ":over" or ":under" must be specified, and anything
else is an error. else is an error.
The size of a message is defined to be the number of octets from the 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. initial header until the last character in the message body.
Note that for a message that is exactly 4,000 octets, the message is Note that for a message that is exactly 4,000 octets, the message is
neither ":over" 4000 octets or ":under" 4000 octets. neither ":over" 4000 octets or ":under" 4000 octets.
5.10. Test true 5.10. Test true
Syntax: true
Usage: true
The "true" test always evaluates to true. The "true" test always evaluates to true.
6. Extensibility 6. Extensibility
New control commands, actions, and tests can be added to the New control commands, actions, and tests can be added to the
language. Sites must make these features known to their users; this language. Sites must make these features known to their users; this
document does not define a way to discover the list of extensions document does not define a way to discover the list of extensions
supported by the server. supported by the server.
skipping to change at page 31, line 27 skipping to change at page 31, line 32
; A line containing only "." ends the ; A line containing only "." ends the
; multi-line. Remove a leading '.' if ; multi-line. Remove a leading '.' if
; followed by another '.'. ; followed by another '.'.
white-space = 1*(SP / CRLF / HTAB) / comment white-space = 1*(SP / CRLF / HTAB) / comment
8.2. Grammar 8.2. Grammar
The following is the grammar of Sieve after it has been lexically The following is the grammar of Sieve after it has been lexically
interpreted. No white space or comments appear below. The start interpreted. No white space or comments appear below. The start
symbol is "start". symbol is "start". Non-terminals for MATCH-TYPE, COMPARATOR, and
ADDRESS-PART are provided for use by extensions.
argument = string-list / number / tag argument = string-list / number / tag
arguments = *argument [test / test-list] arguments = *argument [test / test-list]
block = "{" commands "}" block = "{" commands "}"
command = identifier arguments ( ";" / block ) command = identifier arguments ( ";" / block )
commands = *command commands = *command
skipping to change at page 31, line 46 skipping to change at page 32, line 4
commands = *command commands = *command
start = commands start = commands
string = quoted-string / multi-line string = quoted-string / multi-line
string-list = "[" string *("," string) "]" / string string-list = "[" string *("," string) "]" / string
; if there is only a single string, the brackets ; if there is only a single string, the brackets
; are optional ; are optional
test = identifier arguments test = identifier arguments
test-list = "(" test *("," test) ")" test-list = "(" test *("," test) ")"
ADDRESS-PART = ":localpart" / ":domain" / ":all"
COMPARATOR = ":comparator" string
MATCH-TYPE = ":is" / ":contains" / ":matches"
9. Extended Example 9. Extended Example
The following is an extended example of a Sieve script. Note that it The following is an extended example of a Sieve script. Note that it
does not make use of the implicit keep. does not make use of the implicit keep.
# #
# Example Sieve Filter # Example Sieve Filter
# Declare any optional features or extension used by the script # Declare any optional features or extension used by the script
# #
require ["fileinto"]; require ["fileinto"];
# #
skipping to change at page 33, line 40 skipping to change at page 34, line 4
This document has been revised in part based on comments and This document has been revised in part based on comments and
discussions that took place on and off the SIEVE mailing list. discussions that took place on and off the SIEVE mailing list.
Thanks to Cyrus Daboo, Ned Freed, Michael Haardt, Kjetil Torgrim Thanks to Cyrus Daboo, Ned Freed, Michael Haardt, Kjetil Torgrim
Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski, Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski,
and Nigel Swinson for reviews and suggestions. and Nigel Swinson for reviews and suggestions.
12. Editors' Addresses 12. Editors' Addresses
Philip Guenther Philip Guenther
Sendmail, Inc. Sendmail, Inc.
6425 Christie St. Ste 400 6425 Christie St. Ste 400
Emeryville, CA 94608 Emeryville, CA 94608
Email: guenther@sendmail.com Email: guenther@sendmail.com
Tim Showalter Tim Showalter
Email: tjs@psaux.com Email: tjs@psaux.com
13. Normative References 13. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] D. Crocker, Ed., P. Overell "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 4234, October 2005.
[COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet [COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet
Application Protocol Collation Registry" draft- Application Protocol Collation Registry" draft-
newman-i18n-comparator-04.txt (work in progress), newman-i18n-comparator-04.txt (work in progress),
July 2005. July 2005.
[IMAIL] P. Resnick, Ed., "Internet Message Format", RFC 2822, [IMAIL] P. Resnick, Ed., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 36, line 4 skipping to change at page 36, line 17
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Append A. Change History Append A. Change History
This section will be replaced with a summary of the changes since RFC This section will be replaced with a summary of the changes since RFC
3028 when this document leaves the Internet-Draft stage. 3028 when this document leaves the Internet-Draft stage.
Open Issues:
1. Compression of embedded whitespace
2. Merge reject back in with textual changes to permit MDNs and
protocol level rejection
Changes from draft-ietf-sieve-3028bis-05.txt
1. Add non-terminals for MATCH-TYPE, COMPARATOR, and ADDRESS-PART
2. Strip leading and trailing whitespace in the value being matched
by header
3. Collations operate on octets, not characters, and for character
data that is the UTF-8 encoding of the Unicode characters
4. :matches uses character definition of comparator
Changes from draft-ietf-sieve-3028bis-04.txt
1. Change "Syntax:" to "Usage:"
2. Update ABNF reference to RFC 4234
Changes from draft-ietf-sieve-3028bis-03.txt Changes from draft-ietf-sieve-3028bis-03.txt
1. Remove section 2.4.2.4., MIME Parts, as unreferenced. 1. Remove section 2.4.2.4., MIME Parts, as unreferenced
2. Update to draft-newman-i18n-comparator-04.txt 2. Update to draft-newman-i18n-comparator-04.txt
3. Various tweaks to examples and syntax lines 3. Various tweaks to examples and syntax lines
4. Define "control structure" as a control command with a block 4. Define "control structure" as a control command with a block
argument, then use it consistently. Reword description of argument, then use it consistently. Reword description of
blocks to match blocks to match
5. Clarify that "header" can never match an absent header and give 5. Clarify that "header" can never match an absent header and give
the preferred way to test for absent or empty the preferred way to test for absent or empty
6. Invalid header name syntax is not an error _in tests_ (but could 6. Invalid header name syntax is not an error _in tests_ (but could
be elsewhere) be elsewhere)
7. Implementation SHOULD consider unknown envelope parts an error 7. Implementation SHOULD consider unknown envelope parts an error
skipping to change at page 36, line 31 skipping to change at page 37, line 13
Changes from draft-ietf-sieve-3028bis-02.txt Changes from draft-ietf-sieve-3028bis-02.txt
1. Change "ASCII" to "US-ASCII" throughout 1. Change "ASCII" to "US-ASCII" throughout
2. Tweak section 2.7.2 to not require use of UTF-8 internally and 2. Tweak section 2.7.2 to not require use of UTF-8 internally and
to explicitly leave implementation-defined the handling of text to explicitly leave implementation-defined the handling of text
that can't be converted to Unicode that can't be converted to Unicode
3. Add reference to RFC 2047 3. Add reference to RFC 2047
4. Clarify that capability strings are case-sensitive 4. Clarify that capability strings are case-sensitive
5. Clarify that address, envelope, and header return false if no 5. Clarify that address, envelope, and header return false if no
combination of arguments match combination of arguments match
6. Directly state that code that isn't reached may still be checked 6. Directly state that code that isn't reached may still be checked
for errors. for errors
7. Invalid header name syntax is not an error 7. Invalid header name syntax is not an error
8. Remove description of header unfolding that conflicts with 8. Remove description of header unfolding that conflicts with
[IMAIL] [IMAIL]
9. Warn that filters may be subvertable if agents interpret messages 9. Warn that filters may be subvertable if agents interpret messages
differently differently
10. Encoded NUL octets SHOULD NOT cause truncation 10. Encoded NUL octets SHOULD NOT cause truncation
Changes from draft-ietf-sieve-3028bis-01.txt Changes from draft-ietf-sieve-3028bis-01.txt
1. Remove ban on side effects 1. Remove ban on side effects
2. Remove definition of the 'reject' action, as it is being moved 2. Remove definition of the 'reject' action, as it is being moved
skipping to change at page 37, line 8 skipping to change at page 37, line 38
"null" "null"
Changes from draft-ietf-sieve-3028bis-00.txt Changes from draft-ietf-sieve-3028bis-00.txt
1. More grammar corrections: 1. More grammar corrections:
- permit /***/, - permit /***/,
- remove ambiguity in finding end of bracket comment, - remove ambiguity in finding end of bracket comment,
- require valid UTF-8, - require valid UTF-8,
- express quoting in the grammar - express quoting in the grammar
- ban bare CR and LF in all locations - ban bare CR and LF in all locations
2. Correct a bunch of whitespace and linewrapping nits 2. Correct a bunch of whitespace and linewrapping nits
3. Update IMAIL and SMTP references RFC 2822 and RFC 2821 3. Update IMAIL and SMTP references to RFC 2822 and RFC 2821
4. Require support for en;ascii-casemap comparator as well as the 4. Require support for en;ascii-casemap comparator as well as the
old i;ascii-casemap. As with the old one, you do not need to old i;ascii-casemap. As with the old one, you do not need to
use 'require' to use the new comparator. use 'require' to use the new comparator
5. Update IANA considerations to update the existing registrations 5. Update IANA considerations to update the existing registrations
to point at this doc instead of 3028. to point at this doc instead of 3028
6. Scripts SHOULD NOT contain superfluous backslashes 6. Scripts SHOULD NOT contain superfluous backslashes
7. Update Acknowledgments 7. Update Acknowledgments
Changes from RFC 3028 Changes from RFC 3028
1. Split references into normative and informative 1. Split references into normative and informative
2. Update references to current versions of DSN, IMAP, MDN, and 2. Update references to current versions of DSN, IMAP, MDN, and
UTF-8 RFCs UTF-8 RFCs
3. Replace "e-mail" with "email" 3. Replace "e-mail" with "email"
4. Incorporate RFC 3028 errata 4. Incorporate RFC 3028 errata
5. The "reject" action cancels the implicit keep 5. The "reject" action cancels the implicit keep
6. Replace references to ACAP with references to the i18n-comparator 6. Replace references to ACAP with references to the i18n-comparator
draft. Further work is needed to completely sync with that draft. Further work is needed to completely sync with that
draft. draft
7. Start to update grammar to only permit legal UTF-8 (incomplete) 7. Start to update grammar to only permit legal UTF-8 (incomplete)
and correct various other errors and typos and correct various other errors and typos
8. Update IPR broilerplate to RFC 3978/3979 8. Update IPR broilerplate to RFC 3978/3979
 End of changes. 45 change blocks. 
59 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/