< 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
			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		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 4 ¶		skipping to change at page 31, line 37 ¶
	arbitrary octets and Unicode characters to be		arbitrary octets and Unicode characters to be
	represented using US-ASCII		represented using US-ASCII
	RFC number: this RFC (Sieve base spec)		RFC number: this RFC (Sieve base spec)
	Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>		Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
	Capability name: fileinto		Capability name: fileinto
	Description: adds the 'fileinto' action for delivering to a		Description: adds the 'fileinto' action for delivering to a
	mailbox other than the default		mailbox other than the default
	RFC number: this RFC (Sieve base spec)		RFC number: this RFC (Sieve base spec)
	Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>		Contact address: The Sieve discussion list <ietf-mta-filters@imc.org>
	Capability name: envelope		Capability name: envelope
	Description: adds the 'envelope' test for testing the message		Description: adds the 'envelope' test for testing the message
	transport sender and recipient address		transport sender and recipient address
	RFC number: this RFC (Sieve base spec)		RFC number: this RFC (Sieve base spec)
	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 12 ¶		skipping to change at page 33, line 47 ¶
	; 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 19 ¶		skipping to change at page 38, line 28 ¶
	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] 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.
	14. Informative References		14. Informative References
	[BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in		[BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in
	electrical technology - Part 2: Telecommunications and		electrical technology - Part 2: Telecommunications and
	electronics", January 1999.		electronics", January 1999.
	[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format		[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
	for Delivery Status Notifications", RFC 3464, January		for Delivery Status Notifications", RFC 3464, January
	2003.		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. 60 change blocks.
	108 lines changed or deleted		176 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/