draft-ietf-sieve-3028bis-12.txt   draft-ietf-sieve-3028bis-13.txt 
Network Working Group P. Guenther Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Intended status: Standards Track T. Showalter Intended status: Standards Track T. Showalter
Expires: August 2007 Editors Expires: April 2008 Editors
Obsoletes: 3028 (if approved) February 2007 Obsoletes: 3028 (if approved) October 2007
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-12.txt draft-ietf-sieve-3028bis-13.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 26 skipping to change at page 2, line 26
2. Design ................................................. 6 2. Design ................................................. 6
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 .......................................... 7 2.4. Literal Data .......................................... 7
2.4.1. Numbers ............................................... 7 2.4.1. Numbers ............................................... 7
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 ............................................... 9 2.4.2.2. Headers ............................................... 9
2.4.2.3. Addresses ............................................. 9 2.4.2.3. Addresses ............................................. 9
2.4.2.4. Encoding characters using "encoded-character" ......... 9 2.4.2.4. Encoding characters using "encoded-character" ......... 10
2.5. Tests ................................................. 10 2.5. Tests ................................................. 11
2.5.1. Test Lists ............................................ 10 2.5.1. Test Lists ............................................ 11
2.6. Arguments ............................................. 11 2.6. Arguments ............................................. 11
2.6.1. Positional Arguments .................................. 11 2.6.1. Positional Arguments .................................. 11
2.6.2. Tagged Arguments ...................................... 11 2.6.2. Tagged Arguments ...................................... 12
2.6.3. Optional Arguments .................................... 12 2.6.3. Optional Arguments .................................... 12
2.6.4. Types of Arguments .................................... 12 2.6.4. Types of Arguments .................................... 12
2.7. String Comparison ..................................... 12 2.7. String Comparison ..................................... 13
2.7.1. Match Type ............................................ 12 2.7.1. Match Type ............................................ 13
2.7.2. Comparisons Across Character Sets ..................... 14 2.7.2. Comparisons Across Character Sets ..................... 14
2.7.3. Comparators ........................................... 14 2.7.3. Comparators ........................................... 15
2.7.4. Comparisons Against Addresses ......................... 15 2.7.4. Comparisons Against Addresses ......................... 16
2.8. Blocks ................................................ 16 2.8. Blocks ................................................ 16
2.9. Commands .............................................. 16 2.9. Commands .............................................. 16
2.10. Evaluation ............................................ 17 2.10. Evaluation ............................................ 17
2.10.1. Action Interaction .................................... 17 2.10.1. Action Interaction .................................... 17
2.10.2. Implicit Keep ......................................... 17 2.10.2. Implicit Keep ......................................... 17
2.10.3. Message Uniqueness in a Mailbox ....................... 17 2.10.3. Message Uniqueness in a Mailbox ....................... 18
2.10.4. Limits on Numbers of Actions .......................... 18 2.10.4. Limits on Numbers of Actions .......................... 18
2.10.5. Extensions and Optional Features ...................... 18 2.10.5. Extensions and Optional Features ...................... 18
2.10.6. Errors ................................................ 18 2.10.6. Errors ................................................ 19
2.10.7. Limits on Execution ................................... 19 2.10.7. Limits on Execution ................................... 19
3. Control Commands ....................................... 19 3. Control Commands ....................................... 20
3.1. Control if ............................................ 19 3.1. Control if ............................................ 20
3.2. Control require ....................................... 21 3.2. Control require ....................................... 21
3.3. Control stop .......................................... 21 3.3. Control stop .......................................... 21
4. Action Commands ........................................ 21 4. Action Commands ........................................ 21
4.1. Action fileinto ....................................... 21 4.1. Action fileinto ....................................... 22
4.2. Action redirect ....................................... 22 4.2. Action redirect ....................................... 22
4.3. Action keep ........................................... 23 4.3. Action keep ........................................... 23
4.4. Action discard ........................................ 23 4.4. Action discard ........................................ 24
5. Test Commands .......................................... 24 5. Test Commands .......................................... 24
5.1. Test address .......................................... 24 5.1. Test address .......................................... 25
5.2. Test allof ............................................ 25 5.2. Test allof ............................................ 25
5.3. Test anyof ............................................ 25 5.3. Test anyof ............................................ 26
5.4. Test envelope ......................................... 25 5.4. Test envelope ......................................... 26
5.5. Test exists ........................................... 26 5.5. Test exists ........................................... 27
5.6. Test false ............................................ 26 5.6. Test false ............................................ 27
5.7. Test header ........................................... 27 5.7. Test header ........................................... 27
5.8. Test not .............................................. 27 5.8. Test not .............................................. 28
5.9. Test size ............................................. 27 5.9. Test size ............................................. 28
5.10. Test true ............................................. 28 5.10. Test true ............................................. 29
6. Extensibility .......................................... 28 6. Extensibility .......................................... 29
6.1. Capability String ..................................... 29 6.1. Capability String ..................................... 29
6.2. IANA Considerations ................................... 29 6.2. IANA Considerations ................................... 30
6.2.1. Template for Capability Registrations ................. 30 6.2.1. Template for Capability Registrations ................. 30
6.2.2. Handling of Existing Capability Registrations ......... 30 6.2.2. Handling of Existing Capability Registrations ......... 31
6.2.3. Initial Capability Registrations ...................... 30 6.2.3. Initial Capability Registrations ...................... 31
6.3. Capability Transport .................................. 31 6.3. Capability Transport .................................. 32
7. Transmission ........................................... 31 7. Transmission ........................................... 32
8. Parsing ................................................ 32 8. Parsing ................................................ 32
8.1. Lexical Tokens ........................................ 32 8.1. Lexical Tokens ........................................ 33
8.2. Grammar ............................................... 34 8.2. Grammar ............................................... 35
9. Extended Example ....................................... 35 9. Extended Example ....................................... 35
10. Security Considerations ................................ 36 10. Security Considerations ................................ 36
11. Acknowledgments ........................................ 36 11. Acknowledgments ........................................ 38
12. Editors' Addresses ..................................... 37 12. Editors' Addresses ..................................... 38
13. Normative References ................................... 37 13. Normative References ................................... 38
14. Informative References ................................. 38 14. Informative References ................................. 39
15. Changes from RFC 3028 .................................. 39 15. Changes from RFC 3028 .................................. 39
16. Full Copyright Statement ............................... 40 16. Full Copyright Statement ............................... 40
1. Introduction 1. Introduction
This memo documents a language that can be used to create filters for This memo documents a language that can be used to create filters for
electronic mail. It is not tied to any particular operating system electronic mail. It is not tied to any particular operating system
or mail architecture. It requires the use of [IMAIL]-compliant or mail architecture. It requires the use of [IMAIL]-compliant
messages, but should otherwise generalize to many systems. messages, but should otherwise generalize to many systems.
The language is powerful enough to be useful but limited in order to The language is powerful enough to be useful but limited in order to
allow for a safe server-side filtering system. The intention is to allow for a safe server-side filtering system. The intention is to
make it impossible for users to do anything more complex (and make it impossible for users to do anything more complex (and
dangerous) than write simple mail filters, along with facilitating dangerous) than write simple mail filters, along with facilitating
the use of GUIs for filter creation and manipulation. The base the use of GUIs for filter creation and manipulation. The base
language is intentionally not Turing-complete: it provides no way to language was not designed to be Turing-complete: it does not have a
write a loop or a function and variables are not provided. loop control structure or functions.
Scripts written in Sieve are executed during final delivery, when the Scripts written in Sieve are executed during final delivery, when the
message is moved to the user-accessible mailbox. In systems where message is moved to the user-accessible mailbox. In systems where
the Mail Transfer Agent (MTA) does final delivery, such as the Mail Transfer Agent (MTA) does final delivery, such as
traditional Unix mail, it is reasonable to sort when the MTA deposits traditional Unix mail, it is reasonable to filter when the MTA
mail into the user's mailbox. deposits mail into the user's mailbox.
There are a number of reasons to use a filtering system. Mail There are a number of reasons to use a filtering system. Mail
traffic for most users has been increasing due to increased usage of traffic for most users has been increasing due to increased usage of
email, the emergence of unsolicited email as a form of advertising, email, the emergence of unsolicited email as a form of advertising,
and increased usage of mailing lists. and increased usage of mailing lists.
Experience at Carnegie Mellon has shown that if a filtering system is Experience at Carnegie Mellon has shown that if a filtering system is
made available to users, many will make use of it in order to file made available to users, many will make use of it in order to file
messages from specific users or mailing lists. However, many others messages from specific users or mailing lists. However, many others
did not make use of the Andrew system's FLAMES filtering language did not make use of the Andrew system's FLAMES filtering language
skipping to change at page 8, line 12 skipping to change at page 8, line 14
Scripts SHOULD NOT escape other characters with a backslash. Scripts SHOULD NOT escape other characters with a backslash.
An undefined escape sequence (such as "\a" in a context where "a" has An undefined escape sequence (such as "\a" in a context where "a" has
no special meaning) is interpreted as if there were no backslash (in no special meaning) is interpreted as if there were no backslash (in
this case, "\a" is just "a"), though that may be changed by this case, "\a" is just "a"), though that may be changed by
extensions. extensions.
Non-printing characters such as tabs, CRLF, and control characters Non-printing characters such as tabs, CRLF, and control characters
are permitted in quoted strings. Quoted strings MAY span multiple are permitted in quoted strings. Quoted strings MAY span multiple
lines. NUL (US-ASCII 0) is not allowed in strings. lines. An unencoded NUL (US-ASCII 0) is not allowed in strings, see
section 2.4.2.4 for how it can be encoded.
As message header data is converted to [UTF-8] for comparison (see As message header data is converted to [UTF-8] for comparison (see
section 2.7.2), most string values will use the UTF-8 encoding. section 2.7.2), most string values will use the UTF-8 encoding.
However, implementations MUST accept all strings that match the However, implementations MUST accept all strings that match the
grammar in section 8. The ability to use non-UTF-8 encoded strings grammar in section 8. The ability to use non-UTF-8 encoded strings
matches existing practice and has proven to be useful both in tests matches existing practice and has proven to be useful both in tests
for invalid data and in arguments containing raw MIME parts for for invalid data and in arguments containing raw MIME parts for
extension actions that generate outgoing messages. extension actions that generate outgoing messages.
For entering larger amounts of text, such as an email message, a For entering larger amounts of text, such as an email message, a
skipping to change at page 10, line 10 skipping to change at page 10, line 17
When the "encoded-character" extension is in effect, certain When the "encoded-character" extension is in effect, certain
character sequences in strings are replaced by their decoded value. character sequences in strings are replaced by their decoded value.
This happens after escape sequences are interpreted and dot- This happens after escape sequences are interpreted and dot-
unstuffing has been done. Implementations SHOULD support "encoded- unstuffing has been done. Implementations SHOULD support "encoded-
character". character".
Arbitrary octets can be embedded in strings by using the syntax Arbitrary octets can be embedded in strings by using the syntax
encoded-arb-octets. The sequence is replaced by the octets with the encoded-arb-octets. The sequence is replaced by the octets with the
hexadecimal values given by each hex-pair. hexadecimal values given by each hex-pair.
blank = WSP / CRLF
encoded-arb-octets = "${hex:" hex-pair-seq "}" encoded-arb-octets = "${hex:" hex-pair-seq "}"
hex-pair-seq = hex-pair *(WSP hex-pair) hex-pair-seq = *blank hex-pair *(1*blank hex-pair) *blank
hex-pair = 1*2HEXDIG hex-pair = 1*2HEXDIG
It may be inconvenient or undesirable to enter Unicode characters It may be inconvenient or undesirable to enter Unicode characters
verbatim and for these cases the syntax encoded-unicode-char can be verbatim and for these cases the syntax encoded-unicode-char can be
used. The sequence is replaced by the UTF-8 encoding of the used. The sequence is replaced by the UTF-8 encoding of the
specified Unicode characters, which are identified by the hexadecimal specified Unicode characters, which are identified by the hexadecimal
value of unicode-hex. value of unicode-hex.
encoded-unicode-char = "${unicode:" unicode-hex-seq "}" encoded-unicode-char = "${unicode:" unicode-hex-seq "}"
unicode-hex-seq = unicode-hex *(WSP unicode-hex) unicode-hex-seq = *blank unicode-hex
unicode-hex = 1*6HEXDIG *(1*blank unicode-hex) *blank
unicode-hex = 1*HEXDIG
It is an error for a script to use a hexadecimal value that isn't in It is an error for a script to use a hexadecimal value that isn't in
either the range 0 to D7FF or the range E000 to 10FFFF. (The range either the range 0 to D7FF or the range E000 to 10FFFF. (The range
D800 to DFFF is excluded as those character numbers are only used as D800 to DFFF is excluded as those character numbers are only used as
part of the UTF-16 encoding form and are not applicable to the UTF-8 part of the UTF-16 encoding form and are not applicable to the UTF-8
encoding that the syntax here represents.) encoding that the syntax here represents.)
Note: Implementations MUST NOT raise an error for an out of range
Unicode value unless the sequence containing it is well-formed
according to the grammar.
The capability string for use with the require command is "encoded- The capability string for use with the require command is "encoded-
character". character".
In the following script, message A is discarded, since the specified In the following script, message B is discarded, since the specified
test string is equivalent to "$$$". test string is equivalent to "$$$".
Example: require "encoded-character"; Example: require "encoded-character";
if header :contains "Subject" "$${hex:24 24}" { if header :contains "Subject" "$${hex:24 24}" {
discard; discard;
} }
The following examples demonstrate valid and invalid encodings and
how they are handled:
"$${hex:40}" -> "$@"
"${hex: 40 }" -> "@"
"${HEX: 40}" -> "@"
"${hex:40" -> "${hex:40"
"${hex:400}" -> "${hex:400}"
"${hex:4${hex:30}}" -> "${hex:40}"
"${unicode:40}" -> "@"
"${ unicode:40}" -> "${ unicode:40}"
"${UNICODE:40}" -> "@"
"${UnICoDE:0000040}" -> "@"
"${Unicode:40}" -> "@"
"${Unicode:Cool}" -> "${Unicode:Cool}"
"${unicode:200000}" -> error
"${Unicode:DF01} -> error
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 to decide
decide which block of code is run. 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
argument. The test-list syntax element provides a way of grouping argument. The test-list syntax element provides a way of grouping
tests as a comma separated list in parens. tests as a comma separated list in parens.
Example: if anyof (not exists ["From", "Date"], Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.com") { header :contains "from" "fool@example.com") {
skipping to change at page 11, line 49 skipping to change at page 12, line 30
instead of the meaning being derived from the command, it is derived instead of the meaning being derived from the command, it is derived
from the tag. from the tag.
Tagged arguments must appear before positional arguments, but they Tagged arguments must appear before positional arguments, but they
may appear in any order with other tagged arguments. For simplicity may appear in any order with other tagged arguments. For simplicity
of the specification, this is not expressed in the syntax definitions of the specification, this is not expressed in the syntax definitions
with commands, but they still may be reordered arbitrarily provided with commands, but they still may be reordered arbitrarily provided
they appear before positional arguments. Tagged arguments may be they appear before positional arguments. Tagged arguments may be
mixed with optional arguments. mixed with optional arguments.
To simplify this specification, tagged arguments SHOULD NOT take Tagged arguments SHOULD NOT take tagged arguments as arguments.
tagged arguments as arguments.
2.6.3. Optional Arguments 2.6.3. Optional Arguments
Optional arguments are exactly like tagged arguments except that they Optional arguments are exactly like tagged arguments except that they
may be left out, in which case a default value is implied. Because may be left out, in which case a default value is implied. Because
optional arguments tend to result in shorter scripts, they have been optional arguments tend to result in shorter scripts, they have been
used far more than tagged arguments. used far more than tagged arguments.
One particularly noteworthy case is the ":comparator" argument, which One particularly noteworthy case is the ":comparator" argument, which
allows the user to specify which comparator [COLLATION] will be used allows the user to specify which comparator [COLLATION] will be used
to compare two strings, since different languages may impose to compare two strings, since different languages may impose
different orderings on UTF-8 [UTF-8] characters. different orderings on UTF-8 [UTF-8] strings.
2.6.4. Types of Arguments 2.6.4. Types of Arguments
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 a block 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
skipping to change at page 12, line 51 skipping to change at page 13, line 31
Application Protocol Collation Registry [COLLATION]. Application Protocol Collation Registry [COLLATION].
However, when a string represents the name of a header, the However, when a string represents the name of a header, the
comparator is never user-specified. Header comparisons are always comparator is never user-specified. Header comparisons are always
done with the "i;ascii-casemap" operator, i.e., case-insensitive done with the "i;ascii-casemap" operator, i.e., case-insensitive
comparisons, because this is the way things are defined in the comparisons, because this is the way things are defined in the
message specification [IMAIL]. message specification [IMAIL].
2.7.1. Match Type 2.7.1. Match Type
There are three match types describing the matching used in this Commands which perform string comparisons may have an optional match
specification: ":is", ":contains", and ":matches". Match type type argument. The three match types in this specification are ":is",
arguments are supplied to those commands which allow them to specify ":contains", and ":matches".
what kind of match is to be performed.
These are used as optional arguments to tests that perform string
comparison.
The ":contains" match type describes a substring match. If the value The ":contains" match type describes a substring match. If the value
argument contains the key argument as a substring, the match is true. argument contains the key argument as a substring, the match is true.
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 in the value and "?" matches a single matches zero or more characters in the value and "?" matches a single
character in the value, where the comparator that is used (see 2.7.3) character in the value, where the comparator that is used (see 2.7.3)
defines what a character is. For example, the comparators "i;octet" defines what a character is. For example, the comparators "i;octet"
and "i;ascii-casemap" define a character to be a single octet so "?" and "i;ascii-casemap" define a character to be a single octet so "?"
will always match exactly one octet when one of those comparators is will always match exactly one octet when one of those comparators is
in use. In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2" in use. In contrast, a Unicode-based comparator would define a
defines a character to be any UTF-8 octet sequence encoding one character to be any UTF-8 octet sequence encoding one Unicode
Unicode character and thus "?" may match more than one octet. "?" character and thus "?" may match more than one octet. "?" and "*"
and "*" may be escaped as "\\?" and "\\*" in strings to match against may be escaped as "\\?" and "\\*" in strings to match against
themselves. The first backslash escapes the second backslash; themselves. The first backslash escapes the second backslash;
together, they escape the "*". This is awkward, but it is together, they escape the "*". This is awkward, but it is
commonplace in several programming languages that use globs and commonplace in several programming languages that use globs and
regular expressions. 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 arguments ":matches", commands that support matching take optional arguments ":matches",
":is", and ":contains". Commands default to using ":is" matching if ":is", and ":contains". Commands default to using ":is" matching if
no match type argument is supplied. Note that these modifiers no match type argument is supplied. Note that these modifiers
interact with comparators; in particular, only comparators that interact with comparators; in particular, only comparators that
skipping to change at page 14, line 33 skipping to change at page 15, line 10
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.
specification.
All implementations MUST support the "i;octet" comparator (simply All implementations MUST support the "i;octet" comparator (simply
compares octets) and the "i;ascii-casemap" comparator (which treats compares octets) and the "i;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). If left unspecified, the default is "i;ascii-casemap". the same). If left unspecified, the default is "i;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
it. it.
skipping to change at page 18, line 7 skipping to change at page 18, line 27
than once, even if a script explicitly asks for a message to be than once, even if a script explicitly asks for a message to be
written to a mailbox twice. written to a mailbox twice.
The test for equality of two messages is implementation-defined. The test for equality of two messages is implementation-defined.
If a script asks for a message to be written to a mailbox twice, it If a script asks for a message to be written to a mailbox twice, it
MUST NOT be treated as an error. MUST NOT be treated as an error.
2.10.4. Limits on Numbers of Actions 2.10.4. Limits on Numbers of Actions
Site policy MAY limit numbers of actions taken and MAY impose Site policy MAY limit the number of actions taken and MAY impose
restrictions on which actions can be used together. In the event restrictions on which actions can be used together. In the event
that a script hits a policy limit on the number of actions taken for that a script hits a policy limit on the number of actions taken for
a particular message, an error occurs. a particular message, an error occurs.
Implementations MUST allow at least one keep or one fileinto. If Implementations MUST allow at least one keep or one fileinto. If
fileinto is not implemented, implementations MUST allow at least one fileinto is not implemented, implementations MUST allow at least one
keep. keep.
2.10.5. Extensions and Optional Features 2.10.5. Extensions and Optional Features
Because of the differing capabilities of many mail systems, several Because of the differing capabilities of many mail systems, several
features of this specification are optional. Before any of these features of this specification are optional. Before any of these
extensions can be executed, they must be declared with the "require" extensions can be executed, they must be declared with the "require"
action. action.
If an extension is not enabled with "require", implementations MUST If an extension is not enabled with "require", implementations MUST
treat it as if they did not support it at all. This protects scripts treat it as if they did not support it at all. This protects scripts
from having their behavior altered by extensions which the script from having their behavior altered by extensions which the script
author might not have even been aware of. author might not have even been aware of.
Implementations MUST NOT execute at all any script which requires an Implementations MUST NOT execute any Sieve script test or command
unknown capability name. subsequent to "require" if one of the required extensions is
unavailable.
Note: The reason for this restriction is that prior experiences with Note: The reason for this restriction is that prior experiences with
languages such as LISP and Tcl suggest that this is a workable languages such as LISP and Tcl suggest that this is a workable
way of noting that a given script uses an extension. way of noting that a given script uses an extension.
Experience with PostScript suggests that mechanisms that allow
a script to work around missing extensions are not used in
practice.
Extensions which define actions MUST state how they interact with Extensions which define actions MUST state how they interact with
actions discussed in the base specification. actions discussed in the base specification.
2.10.6. Errors 2.10.6. Errors
In any programming language, there are compile-time and run-time In any programming language, there are compile-time and run-time
errors. errors.
Compile-time errors are ones in syntax that are detectable if a Compile-time errors are ones in syntax that are detectable if a
syntax check is done. syntax check is done.
skipping to change at page 22, line 36 skipping to change at page 22, line 52
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. In particular, existing headers, but it may add new headers. In particular, existing
Received headers MUST be preserved and the count of Received headers Received headers MUST be preserved and the count of Received headers
in the outgoing message MUST be larger than the same count on the in the outgoing message MUST be larger than the same count on the
message as received by the implementation. (An implementation that message as received by the implementation. (An implementation that
adds a Received header before processing the message does not need to adds a Received header before processing the message does not need to
add another when redirecting.) add another when redirecting.)
The message is send back out with the address from the redirect The message is sent back out with the address from the redirect
command as an envelope recipient. Implementations MAY combine command as an envelope recipient. Implementations MAY combine
separate redirects for a given message into a single submission with separate redirects for a given message into a single submission with
multiple envelope recipients. (This is not an MUA-style forward, multiple envelope recipients. (This is not an MUA-style forward,
which creates a new message with a different sender and message ID, which creates a new message with a different sender and message ID,
wrapping the old message in a new one.) wrapping the old message in a new one.)
The envelope sender address on the outgoing message is chosen by the The envelope sender address on the outgoing message is chosen by the
sieve implementation. It MAY be copied from the message being sieve implementation. It MAY be copied from the message being
processed. However, if the message being processed has an empty
envelope sender address the outgoing message MUST also have an empty
envelope sender address. This last requirement is imposed to prevent
loops in the case where a message is redirected to an invalid address
when then returns a delivery status notification that also ends up
being redirected to the same invalid address.
The envelope sender address on the outgoing message is chosen by the
sieve implementation. It MAY be copied from the message being
processed. processed.
A simple script can be used for redirecting all mail: A simple script can be used for redirecting all mail:
Example: redirect "bart@example.com"; Example: redirect "bart@example.com";
Implementations SHOULD take measures to implement loop control, Implementations MUST 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 as specified in section 6.2 of [SMTP]. If an implementation
detects a loop, it causes an error.
Implementations MUST provide means of limiting the number of
redirects a Sieve script can perform. See Section 10 for more
details.
Implementations MAY ignore a redirect action silently due to policy
reasons. For example, an implementation MAY choose not to redirect
to an address that is known to be undeliverable. Any ignored redirect
MUST NOT cancel the implicit keep.
4.3. Action keep 4.3. Action keep
Usage: 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
skipping to change at page 28, line 18 skipping to change at page 28, line 49
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.
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 in the The size of a message is defined to be the number of octets in the
[IMAIL] representation of the message. [IMAIL] representation of the message.
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" nor ":under" 4000 octets.
5.10. Test true 5.10. Test true
Usage: 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
skipping to change at page 29, line 44 skipping to change at page 30, line 29
implementation supports the "elbonia" comparator. implementation supports the "elbonia" comparator.
Therefore, all implementations have at least the Therefore, all implementations have at least the
"comparator-i;octet" "comparator-i;octet"
and "comparator-i;ascii-casemap" capabilities. However, and "comparator-i;ascii-casemap" capabilities. However,
these comparators may be used without being declared these comparators may be used without being declared
with require. with require.
6.2. IANA Considerations 6.2. IANA Considerations
In order to provide a standard set of extensions, a registry is In order to provide a standard set of extensions, a registry is
provided by IANA. Capability names may be registered on a first- maintained by IANA. Capability names may be registered on a first-
come, first-served basis. Extensions designed for interoperable use come, first-served basis. Extensions designed for interoperable use
SHOULD be defined as standards track or IESG approved experimental SHOULD be defined as standards track or IESG approved experimental
RFCs. Registration of capability prefixes that do not begin with RFCs. Registration of capability prefixes that do not begin with
"vnd." REQUIRES a standards track or IESG approved experimental RFC. "vnd." REQUIRES a standards track or IESG approved experimental RFC.
6.2.1. Template for Capability Registrations 6.2.1. Template for Capability Registrations
The following template is to be used for registering new Sieve The following template is to be used for registering new Sieve
extensions with IANA. extensions with IANA.
skipping to change at page 31, line 18 skipping to change at page 32, line 7
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org> Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
Capability name: comparator-* (anything starting with "comparator-") Capability name: comparator-* (anything starting with "comparator-")
Description: adds the indicated comparator for use with the Description: adds the indicated comparator for use with the
:comparator argument :comparator argument
RFC number: this RFC (Sieve base spec) and [COLLATION] RFC number: this RFC (Sieve base spec) and [COLLATION]
Contact address: The Sieve discussion list <ietf-mta-filters@imc.org> Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
6.3. Capability Transport 6.3. Capability Transport
As the range of mail systems that this document is intended to apply A method of advertising which capabilities an implementation supports
to is quite varied, a method of advertising which capabilities an is difficult due to the wide range of possible implementations. Such
implementation supports is difficult due to the wide range of a mechanism, however, should have the property that the
possible implementations. Such a mechanism, however, should have the implementation can advertise the complete set of extensions that it
property that the implementation can advertise the complete set of supports.
extensions that it supports.
7. Transmission 7. Transmission
The [MIME] type for a Sieve script is "application/sieve". The [MIME] type for a Sieve script is "application/sieve".
The registration of this type for RFC 2048 requirements is updated as The registration of this type for RFC 2048 requirements is updated as
follows: follows:
Subject: Registration of MIME media type application/sieve Subject: Registration of MIME media type application/sieve
skipping to change at page 33, line 4 skipping to change at page 33, line 39
The lexical structure of sieve is defined in the following grammar The lexical structure of sieve is defined in the following grammar
(as described in [ABNF]): (as described in [ABNF]):
bracket-comment = "/*" *not-star 1*STAR bracket-comment = "/*" *not-star 1*STAR
*(not-star-slash *not-star 1*STAR) "/" *(not-star-slash *not-star 1*STAR) "/"
; No */ allowed inside a comment. ; No */ allowed inside a comment.
; (No * is allowed unless it is the last ; (No * is allowed unless it is the last
; character, or unless it is followed by a ; character, or unless it is followed by a
; character that isn't a slash.) ; character that isn't a slash.)
comment = bracket-comment / hash-comment comment = bracket-comment / hash-comment
hash-comment = "#" *octet-not-crlf CRLF hash-comment = "#" *octet-not-crlf CRLF
identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_") identifier = (ALPHA / "_") *(ALPHA / DIGIT / "_")
multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF) multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF)
*(multiline-literal / multiline-dotstuff) *(multiline-literal / multiline-dotstart)
"." CRLF "." CRLF
multiline-literal = [ octet-not-period *octet-not-crlf ] CRLF multiline-literal = [ octet-not-period *octet-not-crlf ] CRLF
multiline-dotstuff = "." 1*octet-not-crlf CRLF multiline-dotstart = "." 1*octet-not-crlf CRLF
; 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 '.'.
not-star = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-FF not-star = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-FF
; either a CRLF pair, OR a single octet ; either a CRLF pair, OR a single octet
; other than NUL, CR, LF, or star ; other than NUL, CR, LF, or star
not-star-slash = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-2E / not-star-slash = CRLF / %x01-09 / %x0B-0C / %x0E-29 / %x2B-2E /
%x30-FF %x30-FF
skipping to change at page 36, line 11 skipping to change at page 36, line 42
# mailbox. # mailbox.
fileinto "personal"; fileinto "personal";
} }
10. Security Considerations 10. Security Considerations
Users must get their mail. It is imperative that whatever method Users must get their mail. It is imperative that whatever method
implementations use to store the user-defined filtering scripts be implementations use to store the user-defined filtering scripts be
secure. secure.
It is equally important that implementations sanity-check the user's
scripts, and not allow users to create on-demand mailbombs. For
instance, an implementation that allows a user to redirect a message
multiple times might also allow a user to create a mailbomb triggered
by mail from a specific user. Site- or implementation-defined limits
on actions are useful for this.
Several commands, such as "discard", "redirect", and "fileinto" allow Several commands, such as "discard", "redirect", and "fileinto" allow
for actions to be taken that are potentially very dangerous. for actions to be taken that are potentially very dangerous.
The "redirect" command has considerations regarding loop prevention;
see the command description for recommendations.
Use of the "redirect" command to generate notifications may easily Use of the "redirect" command to generate notifications may easily
overwhelm the target address, especially if it was not designed to overwhelm the target address, especially if it was not designed to
handle large messages. handle large messages.
Implementations SHOULD take measures to prevent scripts from looping. Allowing a single script to redirect to multiple destinations can be
used as a means of amplifying the number of messages in an attack.
Moreover, if loop detection is not properly implemented it may be
possible to set up exponentially growing message loops. According,
Sieve implementations:
(1) MUST implement facilities to detect and break message loops. See
section 6.2 of [SMTP] for additional information on basic loop
detection strategies.
(2) MUST provide the means for administrators to limit the ability of
users to abuse redirect. In particular, it MUST be possible to
limit the number of redirects a script can perform. Additionally,
if no use cases exist for using redirect to multiple
destinations, this limit SHOULD be set to 1. Additional limits,
such as the ability to restrict redirect to local users MAY also
be implemented.
(3) MUST provide facilities to log use of redirect in order to
facilitate tracking down abuse.
(4) MAY use script analysis to determine whether or not a given
script can be executed safely. While the Sieve language is
sufficiently complex that full analysis of all possible scripts
is computationally infeasible, the majority of real-world
scripts are amenable to analysis. For example, an
implementation might allow scripts that it has determined are
safe to run unhindered, block scripts that are potentially
problematic, and subject unclassifiable scripts to additional
auditing and logging.
Allowing redirects at all may not be appropriate in situations where
email accounts are freely-available and/or not trackable to a human
who can be held accountable for creating message bombs or other
abuse.
As with any filter on a message stream, if the sieve implementation As with any filter on a message stream, if the sieve implementation
and the mail agents 'behind' sieve in the message stream differ in and the mail agents 'behind' sieve in the message stream differ in
their interpretation of the messages, it may be possible for an their interpretation of the messages, it may be possible for an
attacker to subvert the filter. Of particular note are differences attacker to subvert the filter. Of particular note are differences
in the interpretation of malformed messages (e.g., missing or extra in the interpretation of malformed messages (e.g., missing or extra
syntax characters) or those that exhibit corner cases (e.g., NUL syntax characters) or those that exhibit corner cases (e.g., NUL
octets encoded via [MIME3]). octets encoded via [MIME3]).
11. Acknowledgments 11. Acknowledgments
skipping to change at page 37, line 21 skipping to change at page 38, line 30
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] D. Crocker, Ed., P. Overell "Augmented BNF for Syntax [ABNF] D. Crocker, Ed., P. Overell "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. 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", RFC 4790, March
newman-i18n-comparator-07.txt (work in progress), 2007.
March 2006.
[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
Message Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, November 1996. Text", RFC 2047, November 1996.
[SMTP] J. Klensin, Ed., "Simple Mail Transfer Protocol", RFC [SMTP] J. Klensin, Ed., "Simple Mail Transfer Protocol", RFC
2821, April 2001. 2821, April 2001.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003. 10646", RFC 3629, November 2003.
skipping to change at page 40, line 4 skipping to change at page 40, line 11
- invalid header field names in tests - invalid header field names in tests
- 'undefined' comparator result - 'undefined' comparator result
- unknown envelope parts - unknown envelope parts
- null return-path in "envelope" test - null return-path in "envelope" test
6. Capability strings are case-sensitive 6. Capability strings are case-sensitive
7. Clarified that fileinto should reencode non-ASCII mailbox 7. Clarified that fileinto should reencode non-ASCII mailbox
names to match the mailstore's conventions names to match the mailstore's conventions
8. Errors in the ABNF were corrected 8. Errors in the ABNF were corrected
9. The references were updated and split into normative and 9. The references were updated and split into normative and
informative informative
10. Added encoded-character capability and deprecated (but did not
remove) use of arbitrary binary octets in Sieve scripts.
11. Updated IANA registration template, and added IANA
considerations to permit capability prefix registrations.
12. Added .sieve as a valid extension for sieve scripts.
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 41, line 10 skipping to change at page 42, line 10
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the IETF Funding for the RFC Editor function is currently provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Appendix A. Change History Appendix A. Change History
This section will be removed when this document leaves the Internet- This section will be removed when this document leaves the Internet-
Draft stage. Draft stage.
Changes from draft-ietf-sieve-3028bis-12.txt
1. Merged in changes from original RFC Editor note
2. Added additional security considerations for redirect
Changes from draft-ietf-sieve-3028bis-11.txt Changes from draft-ietf-sieve-3028bis-11.txt
1. Correct typo in boilerplate 1. Correct typo in boilerplate
2. Update [DSN] reference to RFC 3464 2. Update [DSN] reference to RFC 3464
Changes from draft-ietf-sieve-3028bis-10.txt Changes from draft-ietf-sieve-3028bis-10.txt
1. Clarify how the "redirect" action uses the address argument 1. Clarify how the "redirect" action uses the address argument
2. Eliminate the phrase "original message" 2. Eliminate the phrase "original message"
3. If an outbound address doesn't match the syntax, it's an error 3. If an outbound address doesn't match the syntax, it's an error
Changes from draft-ietf-sieve-3028bis-09.txt Changes from draft-ietf-sieve-3028bis-09.txt
 End of changes. 54 change blocks. 
101 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/