draft-ietf-sieve-3028bis-03.txt   draft-ietf-sieve-3028bis-04.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: January 2006 T. Showalter
Obsoletes: 3028 (if approved) Editors Obsoletes: 3028 (if approved) Editors
July 2005 July 2005
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-03.txt draft-ietf-sieve-3028bis-04.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 2, line 25 skipping to change at page 2, line 25
2. Design ................................................. 5 2. Design ................................................. 5
2.1. Form of the Language .................................. 6 2.1. Form of the Language .................................. 6
2.2. Whitespace ............................................ 6 2.2. Whitespace ............................................ 6
2.3. Comments .............................................. 6 2.3. Comments .............................................. 6
2.4. Literal Data .......................................... 6 2.4. Literal Data .......................................... 6
2.4.1. Numbers ............................................... 6 2.4.1. Numbers ............................................... 6
2.4.2. Strings ............................................... 7 2.4.2. Strings ............................................... 7
2.4.2.1. String Lists .......................................... 8 2.4.2.1. String Lists .......................................... 8
2.4.2.2. Headers ............................................... 8 2.4.2.2. Headers ............................................... 8
2.4.2.3. Addresses ............................................. 8 2.4.2.3. Addresses ............................................. 8
2.4.2.4. MIME Parts ............................................ 9
2.5. Tests ................................................. 9 2.5. Tests ................................................. 9
2.5.1. Test Lists ............................................ 9 2.5.1. Test Lists ............................................ 9
2.6. Arguments ............................................. 9 2.6. Arguments ............................................. 9
2.6.1. Positional Arguments .................................. 9 2.6.1. Positional Arguments .................................. 9
2.6.2. Tagged Arguments ...................................... 10 2.6.2. Tagged Arguments ...................................... 10
2.6.3. Optional Arguments .................................... 10 2.6.3. Optional Arguments .................................... 10
2.6.4. Types of Arguments .................................... 10 2.6.4. Types of Arguments .................................... 10
2.7. String Comparison ..................................... 11 2.7. String Comparison ..................................... 11
2.7.1. Match Type ............................................ 11 2.7.1. Match Type ............................................ 11
2.7.2. Comparisons Across Character Sets ..................... 12 2.7.2. Comparisons Across Character Sets ..................... 12
skipping to change at page 2, line 49 skipping to change at page 2, line 48
2.9. Commands .............................................. 14 2.9. Commands .............................................. 14
2.10. Evaluation ............................................ 15 2.10. Evaluation ............................................ 15
2.10.1. Action Interaction .................................... 15 2.10.1. Action Interaction .................................... 15
2.10.2. Implicit Keep ......................................... 15 2.10.2. Implicit Keep ......................................... 15
2.10.3. Message Uniqueness in a Mailbox ....................... 16 2.10.3. Message Uniqueness in a Mailbox ....................... 16
2.10.4. Limits on Numbers of Actions .......................... 16 2.10.4. Limits on Numbers of Actions .......................... 16
2.10.5. Extensions and Optional Features ...................... 16 2.10.5. Extensions and Optional Features ...................... 16
2.10.6. Errors ................................................ 17 2.10.6. Errors ................................................ 17
2.10.7. Limits on Execution ................................... 17 2.10.7. Limits on Execution ................................... 17
3. Control Commands ....................................... 17 3. Control Commands ....................................... 17
3.1. Control Structure If .................................. 18 3.1. Control If ............................................ 18
3.2. Control Structure Require ............................. 19 3.2. Control Require ....................................... 19
3.3. Control Structure Stop ................................ 19 3.3. Control Stop .......................................... 19
4. Action Commands ........................................ 19 4. Action Commands ........................................ 19
4.1. Action fileinto ....................................... 20 4.1. Action fileinto ....................................... 20
4.2. Action redirect ....................................... 20 4.2. Action redirect ....................................... 20
4.3. Action keep ........................................... 20 4.3. Action keep ........................................... 20
4.4. Action discard ........................................ 21 4.4. Action discard ........................................ 21
5. Test Commands .......................................... 21 5. Test Commands .......................................... 21
5.1. Test address .......................................... 22 5.1. Test address .......................................... 22
5.2. Test allof ............................................ 22 5.2. Test allof ............................................ 22
5.3. Test anyof ............................................ 23 5.3. Test anyof ............................................ 23
5.4. Test envelope ......................................... 23 5.4. Test envelope ......................................... 23
skipping to change at page 4, line 38 skipping to change at page 4, line 38
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 structure) has a Each section on a command (test, action, or control) has a line
line labeled "Syntax:". This line describes the syntax of the labeled "Syntax:". This line describes the syntax of the command,
command, including its name and its arguments. Required arguments including its name and its arguments. Required arguments are listed
are listed inside angle brackets ("<" and ">"). Optional arguments inside angle brackets ("<" and ">"). Optional arguments are listed
are listed inside square brackets ("[" and "]"). Each argument is inside square brackets ("[" and "]"). Each argument is followed by
followed by its type, so "<key: string>" represents an argument its type, so "<key: string>" represents an argument called "key" that
called "key" that is a string. Literal strings are represented with is a string. Literal strings are represented with double-quoted
double-quoted strings. Alternatives are separated with slashes, and strings. Alternatives are separated with slashes, and parenthesis
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 "Syntax" 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
skipping to change at page 8, line 45 skipping to change at page 8, line 45
before the subsequent colon. Extra spaces between the header name before the subsequent colon. Extra spaces between the header name
and the ":" in a header field are ignored. and the ":" in a header field are ignored.
A header name never contains a colon. The "From" header refers to a A header name never contains a colon. The "From" header refers to a
line beginning "From:" (or "From :", etc.). No header will match line beginning "From:" (or "From :", etc.). No header will match
the string "From:" due to the trailing colon. the string "From:" due to the trailing colon.
Similarly, synactically invalid header names cause the same result as Similarly, synactically invalid header names cause the same result as
syntactically valid header names that are not present in the message. syntactically valid header names that are not present in the message.
In particular, an implementation MUST NOT cause an error for In particular, an implementation MUST NOT cause an error for
synactically invalid header names. synactically invalid header names in tests.
Header lines are unfolded as described in [IMAIL] section 2.2.3. Header lines are unfolded as described in [IMAIL] section 2.2.3.
Interpretation of header data SHOULD be done according to [MIME3] Interpretation of header data SHOULD be done according to [MIME3]
section 6.2 (see 2.7.2 below for details). section 6.2 (see 2.7.2 below for details).
2.4.2.3. Addresses 2.4.2.3. Addresses
A number of commands call for email addresses, which are also a A number of commands call for email addresses, which are also a
subset of strings. When these addresses are used in outbound subset of strings. When these addresses are used in outbound
contexts, addresses must be compliant with [IMAIL], but are further contexts, addresses must be compliant with [IMAIL], but are further
constrained. Using the symbols defined in [IMAIL], section 3, the constrained. Using the symbols defined in [IMAIL], section 3, the
skipping to change at page 9, line 21 skipping to change at page 9, line 21
/ phrase "<" addr-spec ">" ; name & addr-spec / phrase "<" addr-spec ">" ; name & addr-spec
That is, routes and group syntax are not permitted. If multiple That is, routes and group syntax are not permitted. If multiple
addresses are required, use a string list. Named groups are not used addresses are required, use a string list. Named groups are not used
here. here.
Implementations MUST ensure that the addresses are syntactically Implementations MUST ensure that the addresses are syntactically
valid, but need not ensure that they actually identify an email valid, but need not ensure that they actually identify an email
recipient. recipient.
2.4.2.4. MIME Parts
In a few places, [MIME] body parts are represented as strings. These
parts include MIME headers and the body. This provides a way of
embedding typed data within a Sieve script so that, among other
things, character sets other than UTF-8 can be used for output
messages.
2.5. Tests 2.5. Tests
Tests are given as arguments to commands in order to control their Tests are given as arguments to commands in order to control their
actions. In this document, tests are given to if/elsif/else to actions. In this document, tests are given to if/elsif/else to
decide which block of code is run. decide which block of code is run.
2.5.1. Test Lists 2.5.1. Test Lists
Some tests ("allof" and "anyof", which implement logical "and" and Some tests ("allof" and "anyof", which implement logical "and" and
logical "or", respectively) may require more than a single test as an logical "or", respectively) may require more than a single test as an
skipping to change at page 11, line 13 skipping to change at page 11, line 4
Abstractly, arguments may be literal data, tests, or blocks of Abstractly, arguments may be literal data, tests, or blocks of
commands. In this way, an "if" control structure is merely a command commands. In this way, an "if" control structure is merely a command
that happens to take a test and a block as arguments and may execute that happens to take a test and a block as arguments and may execute
the block of code. the block of code.
However, this abstraction is ambiguous from a parsing standpoint. However, this abstraction is ambiguous from a parsing standpoint.
The grammar in section 9.2 presents a parsable version of this: The grammar in section 9.2 presents a parsable version of this:
Arguments are string-lists, numbers, and tags, which may be followed Arguments are string-lists, numbers, and tags, which may be followed
by a test or a test-list, which may be followed by a block of by a test or a test-list, which may be followed by a block of
commands. No more than one test or test list, nor more than one commands. No more than one test or test list, nor more than one
block of commands, may be used, and commands that end with blocks of block of commands, may be used, and commands that end with a block of
commands do not end with semicolons. commands do not end with semicolons.
2.7. String Comparison 2.7. String Comparison
When matching one string against another, there are a number of ways When matching one string against another, there are a number of ways
of performing the match operation. These are accomplished with three of performing the match operation. These are accomplished with three
types of matches: an exact match, a substring match, and a wildcard types of matches: an exact match, a substring match, and a wildcard
glob-style match. These are described below. glob-style match. These are described below.
In order to provide for matches between character sets and case In order to provide for matches between character sets and case
skipping to change at page 12, line 44 skipping to change at page 12, line 35
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 in Unicode. Implementations convert
text from header fields in all charsets [MIME3] to Unicode as text from header fields in all charsets [MIME3] to Unicode as
input to the comparator (see 2.7.3). Implementations MUST be input to the comparator (see 2.7.3). Implementations MUST be
capable of converting US-ASCII, ISO-8859-1, the US-ASCII subset of capable of converting US-ASCII, ISO-8859-1, the US-ASCII subset of
ISO-8859-* character sets, and UTF-8. Text that the 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), omitted, treated as plain US-ASCII (including any [MIME3] syntax) or
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
greater than 127. greater than 127.
2.7.3. Comparators 2.7.3. Comparators
skipping to change at page 14, line 40 skipping to change at page 14, line 29
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 "ADDRESS-PART" syntax element is defined here as For convenience, the "ADDRESS-PART" syntax element is defined here as
follows: follows:
Syntax: ":localpart" / ":domain" / ":all" Syntax: ":localpart" / ":domain" / ":all"
2.8. Blocks 2.8. Blocks
Blocks are sets of commands enclosed within curly braces. Blocks are Blocks are sets of commands enclosed within curly braces and supplied
supplied to commands so that the commands can implement control as the final argument to a command. Such a command is a control
commands. structure: when executed it has control over the number of times the
commands in the block are executed. and how
A control structure is a command that happens to take a test and a
block as one of its arguments; depending on the result of the test
supplied as another argument, it runs the code in the block some
number of times.
With the commands supplied in this memo, there are no loops. The With the commands supplied in this memo, there are no loops. The
control structures supplied--if, elsif, and else--run a block either control structures supplied--if, elsif, and else--run a block either
once or not at all. So there are two arguments, the test and the once or not at all.
block.
2.9. Commands 2.9. Commands
Sieve scripts are sequences of commands. Commands can take any of Sieve scripts are sequences of commands. Commands can take any of
the tokens above as arguments, and arguments may be either tagged or the tokens above as arguments, and arguments may be either tagged or
positional arguments. Not all commands take all arguments. positional arguments. Not all commands take all arguments.
There are three kinds of commands: test commands, action commands, There are three kinds of commands: test commands, action commands,
and control commands. and control commands.
The simplest is an action command. An action command is an The simplest is an action command. An action command is an
identifier followed by zero or more arguments, terminated by a identifier followed by zero or more arguments, terminated by a
semicolon. Action commands do not take tests or blocks as arguments. semicolon. Action commands do not take tests or blocks as arguments.
A control command is similar, but it takes a test as an argument, and A control command is a command that affects the parsing or the flow
ends with a block instead of a semicolon. of execution of the Sieve script in some way. A control structure is
a control command which ends with a block instead of a semicolon.
A test command is used as part of a control command. It is used to A test command is used as part of a control command. It is used to
specify whether or not the block of code given to the control command specify whether or not the block of code given to the control command
is executed. is executed.
2.10. Evaluation 2.10. Evaluation
2.10.1. Action Interaction 2.10.1. Action Interaction
Some actions cannot be used with other actions because the result Some actions cannot be used with other actions because the result
skipping to change at page 18, line 19 skipping to change at page 17, line 50
Implementations MUST support fifteen levels of nested blocks. Implementations MUST support fifteen levels of nested blocks.
Implementations MUST support fifteen levels of nested test lists. Implementations MUST support fifteen levels of nested test lists.
3. Control Commands 3. Control Commands
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 Structure 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> Syntax: if <test1: test> <block1: block>
Syntax: elsif <test2: test> <block2: block> Syntax: elsif <test2: test> <block2: block>
Syntax: else <block> Syntax: 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 commands 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.
When the interpreter runs out of elsifs, there may be an "else" case. When the interpreter runs out of elsifs, there may be an "else" case.
If there is, and none of the if or elsif tests were true, the If there is, and none of the if or elsif tests were true, the
skipping to change at page 19, line 27 skipping to change at page 19, line 11
} elsif header :contains "Subject" "$$$" { } elsif header :contains "Subject" "$$$" {
redirect "postmaster@example.edu"; redirect "postmaster@example.edu";
} 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 Structure Require 3.2. Control Require
Syntax: require <capabilities: string-list> Syntax: 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 Structure Stop 3.3. Control Stop
Syntax: stop Syntax: 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.
skipping to change at page 23, line 12 skipping to change at page 22, line 42
group names, although it does act on the addresses within the group group names, although it does act on the addresses within the group
construct. construct.
Implementations MUST restrict the address test to headers that Implementations MUST restrict the address test to headers that
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> Syntax: 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
skipping to change at page 23, line 41 skipping to change at page 23, line 22
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] Syntax: 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. equivalent) envelope matches the specified key. This specification
defines the interpretation of the (case insensitive) "from" and "to"
envelope-parts. Additional envelope-parts may be defined by other
extensions; implementations SHOULD consider unknown envelope parts an
error.
If one of the envelope-part strings is (case insensitive) "from", If one of the envelope-part strings is (case insensitive) "from",
then matching occurs against the FROM address used in the SMTP MAIL then matching occurs against the FROM address used in the SMTP MAIL
command. command.
If one of the envelope-part strings is (case insensitive) "to", then If one of the envelope-part strings is (case insensitive) "to", then
matching occurs against the TO address used in the SMTP RCPT command matching occurs against the TO address used in the SMTP RCPT command
that resulted in this message getting delivered to this user. Note that resulted in this message getting delivered to this user. Note
that only the most recent TO is available, and only the one relevant that only the most recent TO is available, and only the one relevant
to this user. to this user.
skipping to change at page 25, line 18 skipping to change at page 25, line 4
key. The type of match is specified by the optional match argument, key. The type of match is specified by the optional match argument,
which defaults to ":is" if not specified, as specified in section which defaults to ":is" if not specified, as specified in section
2.6. 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 contain the empty key. So if a message contained the header does not match any key, including the empty key. So if a message
contained the header
X-Caffeine: C8H10N4O2 X-Caffeine: C8H10N4O2
these tests on that header evaluate as follows: these tests on that header evaluate as follows:
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
absent is to combine an "exists" test and a "header" test:
anyof (header :is "Cc" "", not exists "Cc")
5.8. Test not 5.8. Test not
Syntax: not <test> Syntax: 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> Syntax: 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
skipping to change at page 26, line 12 skipping to change at page 26, line 4
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 Syntax: true
The "true" test always evaluates to true. The "true" test always evaluates to true.
6. Extensibility 6. Extensibility
New control structures, 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.
Any extensions to this language MUST define a capability string that Any extensions to this language MUST define a capability string that
uniquely identifies that extension. Capability string are case- uniquely identifies that extension. Capability string are case-
sensitive; for example, "foo" and "FOO" are different capabilities. sensitive; for example, "foo" and "FOO" are different capabilities.
If a new version of an extension changes the functionality of a If a new version of an extension changes the functionality of a
previously defined extension, it MUST use a different name. previously defined extension, it MUST use a different name.
skipping to change at page 34, line 4 skipping to change at page 33, line 43
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] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[COLLATION] Newman, C. and M. Duerst, "Internet Application Protocol [COLLATION] Newman, C., Duerst, M., and A. Gulbrandsen "Internet
Collation Registry" draft-newman-i18n- Application Protocol Collation Registry" draft-
comparator-03.txt (work in progress), October 2004. newman-i18n-comparator-04.txt (work in progress),
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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
skipping to change at page 36, line 11 skipping to change at page 36, line 4
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
3028 when this document leaves the Internet-Draft stage.
This section will be removed when this document leaves the Internet- Changes from draft-ietf-sieve-3028bis-03.txt
Draft stage. 1. Remove section 2.4.2.4., MIME Parts, as unreferenced.
2. Update to draft-newman-i18n-comparator-04.txt
Open Issues: 3. Various tweaks to examples and syntax lines
- should it be an error to give 'envelope' an envelope-part name 4. Define "control structure" as a control command with a block
other than "from" or "to"? argument, then use it consistently. Reword description of
blocks to match
5. Clarify that "header" can never match an absent header and give
the preferred way to test for absent or empty
6. Invalid header name syntax is not an error _in tests_ (but could
be elsewhere)
7. Implementation SHOULD consider unknown envelope parts an error
8. Remove explicit "omitted" option from 2.7.2p2
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
 End of changes. 

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