draft-ietf-sieve-3028bis-02.txt   draft-ietf-sieve-3028bis-03.txt 
Network Working Group P. Guenther Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: December 2005 T. Showalter Expires: January 2006 T. Showalter
Obsoletes: 3028 (if approved) Editors Obsoletes: 3028 (if approved) Editors
June 2005 July 2005
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-02.txt draft-ietf-sieve-3028bis-03.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 6, line 15 skipping to change at page 6, line 15
2.1. Form of the Language 2.1. Form of the Language
The language consists of a set of commands. Each command consists of The language consists of a set of commands. Each command consists of
a set of tokens delimited by whitespace. The command identifier is a set of tokens delimited by whitespace. The command identifier is
the first token and it is followed by zero or more argument tokens. the first token and it is followed by zero or more argument tokens.
Arguments may be literal data, tags, blocks of commands, or test Arguments may be literal data, tags, blocks of commands, or test
commands. commands.
The language is represented in UTF-8, as specified in [UTF-8]. The language is represented in UTF-8, as specified in [UTF-8].
Tokens in the ASCII range are considered case-insensitive. Tokens in the US-ASCII range are considered case-insensitive.
2.2. Whitespace 2.2. Whitespace
Whitespace is used to separate tokens. Whitespace is made up of Whitespace is used to separate tokens. Whitespace is made up of
tabs, newlines (CRLF, never just CR or LF), and the space character. tabs, newlines (CRLF, never just CR or LF), and the space character.
The amount of whitespace used is not significant. The amount of whitespace used is not significant.
2.3. Comments 2.3. Comments
Two types of comments are offered. Comments are semantically Two types of comments are offered. Comments are semantically
skipping to change at page 7, line 27 skipping to change at page 7, line 27
Only positive integers are permitted by this specification. Only positive integers are permitted by this specification.
2.4.2. Strings 2.4.2. Strings
Scripts involve large numbers of strings as they are used for pattern Scripts involve large numbers of strings as they are used for pattern
matching, addresses, textual bodies, etc. Typically, short quoted matching, addresses, textual bodies, etc. Typically, short quoted
strings suffice for most uses, but a more convenient form is provided strings suffice for most uses, but a more convenient form is provided
for longer strings such as bodies of messages. for longer strings such as bodies of messages.
A quoted string starts and ends with a single double quote (the <"> A quoted string starts and ends with a single double quote (the <">
character, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted character, US-ASCII 34). A backslash ("\", ASCII 92) inside of a
string is followed by either another backslash or a double quote. quoted string is followed by either another backslash or a double
This two-character sequence represents a single backslash or double- quote. This two-character sequence represents a single backslash or
quote within the string, respectively. double- quote within the string, respectively.
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"). this case, "\a" is just "a").
Non-printing characters such as tabs, CR and LF, and control Non-printing characters such as tabs, CR and LF, and control
characters are permitted in quoted strings. Quoted strings MAY span characters are permitted in quoted strings. Quoted strings MAY span
multiple lines. NUL (ASCII 0) is not allowed in strings. multiple lines. NUL (US-ASCII 0) is not allowed in strings.
For entering larger amounts of text, such as an email message, a For entering larger amounts of text, such as an email message, a
multi-line form is allowed. It starts with the keyword "text:", multi-line form is allowed. It starts with the keyword "text:",
followed by a CRLF, and ends with the sequence of a CRLF, a single followed by a CRLF, and ends with the sequence of a CRLF, a single
period, and another CRLF. In order to allow the message to contain period, and another CRLF. In order to allow the message to contain
lines with a single-dot, lines are dot-stuffed. That is, when lines with a single-dot, lines are dot-stuffed. That is, when
composing a message body, an extra `.' is added before each line composing a message body, an extra `.' is added before each line
which begins with a `.'. When the server interprets the script, which begins with a `.'. When the server interprets the script,
these extra dots are removed. Note that a line that begins with a these extra dots are removed. Note that a line that begins with a
dot followed by a non-dot character is not interpreted dot-stuffed; dot followed by a non-dot character is not interpreted dot-stuffed;
skipping to change at page 8, line 42 skipping to change at page 8, line 42
Headers are a subset of strings. In the Internet Message Headers are a subset of strings. In the Internet Message
Specification [IMAIL], each header line is allowed to have whitespace Specification [IMAIL], each header line is allowed to have whitespace
nearly anywhere in the line, including after the field name and nearly anywhere in the line, including after the field name and
before the subsequent colon. Extra spaces between the header name before the subsequent colon. Extra spaces between the header name
and the ":" in a header field are ignored. and the ":" in a header field are ignored.
A header name never contains a colon. The "From" header refers to a A header name never contains a colon. The "From" header refers to a
line beginning "From:" (or "From :", etc.). No header will match line beginning "From:" (or "From :", etc.). No header will match
the string "From:" due to the trailing colon. the string "From:" due to the trailing colon.
Folding of long header lines (as described in [IMAIL] 2.2.3) is Similarly, synactically invalid header names cause the same result as
removed prior to interpretation of the data. The folding syntax (the syntactically valid header names that are not present in the message.
CRLF that ends a line plus any leading whitespace at the beginning of In particular, an implementation MUST NOT cause an error for
the next line that indicates folding) are interpreted as if they were synactically invalid header names.
a single space.
2.4.2.3. Addresses Header lines are unfolded as described in [IMAIL] section 2.2.3.
Interpretation of header data SHOULD be done according to [MIME3]
section 6.2 (see 2.7.2 below for details).
2.4.2.3. Addresses
A number of commands call for email addresses, which are also a A number of commands call for email addresses, which are also a
subset of strings. When these addresses are used in outbound subset of strings. When these addresses are used in outbound
contexts, addresses must be compliant with [IMAIL], but are further contexts, addresses must be compliant with [IMAIL], but are further
constrained. Using the symbols defined in [IMAIL], section 3, the constrained. Using the symbols defined in [IMAIL], section 3, the
syntax of an address is: syntax of an address is:
sieve-address = addr-spec ; simple address sieve-address = addr-spec ; simple address
/ phrase "<" addr-spec ">" ; name & addr-spec / phrase "<" addr-spec ">" ; name & addr-spec
That is, routes and group syntax are not permitted. If multiple That is, routes and group syntax are not permitted. If multiple
skipping to change at page 12, line 36 skipping to change at page 12, line 38
Syntax: ":is" / ":contains" / ":matches" Syntax: ":is" / ":contains" / ":matches"
2.7.2. Comparisons Across Character Sets 2.7.2. Comparisons Across Character Sets
All Sieve scripts are represented in UTF-8, but messages may involve All Sieve scripts are represented in UTF-8, but messages may involve
a number of character sets. In order for comparisons to work across a number of character sets. In order for comparisons to work across
character sets, implementations SHOULD implement the following character sets, implementations SHOULD implement the following
behavior: behavior:
Implementations decode header charsets to UTF-8. Two strings are Comparisons are performed in Unicode. Implementations convert
considered equal if their UTF-8 representations are identical. text from header fields in all charsets [MIME3] to Unicode as
Implementations should decode charsets represented in the forms input to the comparator (see 2.7.3). Implementations MUST be
specified by [MIME] for both message headers and bodies. capable of converting US-ASCII, ISO-8859-1, the US-ASCII subset of
Implementations must be capable of decoding US-ASCII, ISO-8859-1, ISO-8859-* character sets, and UTF-8. Text that the
the ASCII subset of ISO-8859-* character sets, and UTF-8. implementation cannot convert to Unicode for any reason MAY be
treated as plain US-ASCII (including any [MIME3] syntax), omitted,
or processed according to local conventions. An encoded NUL octet
(character zero) SHOULD NOT cause early termination of the header
content being compared against.
If implementations fail to support the above behavior, they MUST If implementations fail to support the above behavior, they MUST
conform to the following: conform to the following:
No two strings can be considered equal if one contains octets No two strings can be considered equal if one contains octets
greater than 127. greater than 127.
2.7.3. Comparators 2.7.3. Comparators
In order to allow for language-independent, case-independent matches, In order to allow for language-independent, case-independent matches,
the match type may be coupled with a comparator name. The Internet the match type may be coupled with a comparator name. The Internet
Application Protocol Collation Registry [COLLATION] provides the Application Protocol Collation Registry [COLLATION] provides the
framework for describing and naming comparators as used by this framework for describing and naming comparators as used by this
specification. specification.
While multiple comparator types are defined, only equality types are While multiple comparator types are defined, only equality types are
used in this specification. used in this specification.
All implementations MUST support the "i;octet" comparator (simply All implementations MUST support the "i;octet" comparator (simply
compares octets), the "en;ascii-casemap" comparator (which treats compares octets), the "en;ascii-casemap" comparator (which treats
uppercase and lowercase characters in the ASCII subset of UTF-8 as uppercase and lowercase characters in the US-ASCII subset of UTF-8 as
the same), as well as the "i;ascii-casemap" comparator, which is a the same), as well as the "i;ascii-casemap" comparator, which is a
deprecated synonym for "en;ascii-casemap". If left unspecified, the deprecated synonym for "en;ascii-casemap". If left unspecified, the
default is "en;ascii-casemap". default is "en;ascii-casemap".
Some comparators may not be usable with substring matches; that is, Some comparators may not be usable with substring matches; that is,
they may only work with ":is". It is an error to try and use a they may only work with ":is". It is an error to try and use a
comparator with ":matches" or ":contains" that is not compatible with comparator with ":matches" or ":contains" that is not compatible with
it. it.
A comparator is specified by the ":comparator" option with commands A comparator is specified by the ":comparator" option with commands
skipping to change at page 17, line 38 skipping to change at page 17, line 43
Such implementations are simpler, but have issues with partial Such implementations are simpler, but have issues with partial
failure (some actions happen, others don't). failure (some actions happen, others don't).
Implementations might even go so far as to ensure that scripts can Implementations might even go so far as to ensure that scripts can
never execute an invalid set of actions before execution, although never execute an invalid set of actions before execution, although
this could involve solving the Halting Problem. this could involve solving the Halting Problem.
This specification allows any of these approaches. Solving the This specification allows any of these approaches. Solving the
Halting Problem is considered extra credit. Halting Problem is considered extra credit.
Implementations MUST perform syntactic, semantic, and run-time checks
on code that is actually executed. Implementations MAY perform those
checks or any part of them on code that is not reached during
execution.
When an error happens, implementations MUST notify the user that an When an error happens, implementations MUST notify the user that an
error occurred, which actions (if any) were taken, and do an implicit error occurred, which actions (if any) were taken, and do an implicit
keep. keep.
2.10.7. Limits on Execution 2.10.7. Limits on Execution
Implementations may limit certain constructs. However, this Implementations may limit certain constructs. However, this
specification places a lower bound on some of these limits. specification places a lower bound on some of these limits.
Implementations MUST support fifteen levels of nested blocks. Implementations MUST support fifteen levels of nested blocks.
skipping to change at page 22, line 26 skipping to change at page 22, line 38
The address test matches Internet addresses in structured headers The address test matches Internet addresses in structured headers
that contain addresses. It returns true if any header contains any that contain addresses. It returns true if any header contains any
key in the specified part of the address, as modified by the key in the specified part of the address, as modified by the
comparator and the match keyword. Whether there are other addresses comparator and the match keyword. Whether there are other addresses
present in the header doesn't affect this test; this test does not present in the header doesn't affect this test; this test does not
provide any way to determine whether an address is the only address provide any way to determine whether an address is the only address
in a header. in a header.
Like envelope and header, this test returns true if any combination Like envelope and header, this test returns true if any combination
of the header-list and key-list arguments match. of the header-list and key-list arguments match and false otherwise.
Internet email addresses [IMAIL] have the somewhat awkward Internet email addresses [IMAIL] have the somewhat awkward
characteristic that the local-part to the left of the at-sign is characteristic that the local-part to the left of the at-sign is
considered case sensitive, and the domain-part to the right of the considered case sensitive, and the domain-part to the right of the
at-sign is case insensitive. The "address" command does not deal at-sign is case insensitive. The "address" command does not deal
with this itself, but provides the ADDRESS-PART argument for allowing with this itself, but provides the ADDRESS-PART argument for allowing
users to deal with it. users to deal with it.
The address primitive never acts on the phrase part of an email The address primitive never acts on the phrase part of an email
address, nor on comments within that address. It also never acts on address, nor on comments within that address. It also never acts on
skipping to change at page 23, line 45 skipping to change at page 24, line 10
matching occurs against the TO address used in the SMTP RCPT command matching occurs against the TO address used in the SMTP RCPT command
that resulted in this message getting delivered to this user. Note that resulted in this message getting delivered to this user. Note
that only the most recent TO is available, and only the one relevant that only the most recent TO is available, and only the one relevant
to this user. to this user.
The envelope-part is a string list and may contain more than one The envelope-part is a string list and may contain more than one
parameter, in which case all of the strings specified in the key-list parameter, in which case all of the strings specified in the key-list
are matched against all parts given in the envelope-part list. are matched against all parts given in the envelope-part list.
Like address and header, this test returns true if any combination of Like address and header, this test returns true if any combination of
the envelope-part and key-list arguments is true. the envelope-part list and key-list arguments match and false
otherwise.
All tests against envelopes MUST drop source routes. All tests against envelopes MUST drop source routes.
If the SMTP transaction involved several RCPT commands, only the data If the SMTP transaction involved several RCPT commands, only the data
from the RCPT command that caused delivery to this user is available from the RCPT command that caused delivery to this user is available
in the "to" part of the envelope. in the "to" part of the envelope.
If a protocol other than SMTP is used for message transport, If a protocol other than SMTP is used for message transport,
implementations are expected to adapt this command appropriately. implementations are expected to adapt this command appropriately.
skipping to change at page 24, line 38 skipping to change at page 25, line 4
discard; discard;
} }
5.6. Test false 5.6. Test false
Syntax: false Syntax: false
The "false" test always evaluates to false. The "false" test always evaluates to false.
5.7. Test header 5.7. Test header
Syntax: header [COMPARATOR] [MATCH-TYPE] Syntax: header [COMPARATOR] [MATCH-TYPE]
<header-names: string-list> <key-list: string-list> <header-names: string-list> <key-list: string-list>
The "header" test evaluates to true if any header name matches any The "header" test evaluates to true if any header name matches any
key. The type of match is specified by the optional match argument, key. The type of match is specified by the optional match argument,
which defaults to ":is" if not specified, as specified in section which defaults to ":is" if not specified, as specified in section
2.6. 2.6.
Like address and envelope, this test returns true if any combination Like address and envelope, this test returns true if any combination
of the string-list and key-list arguments match. of the header-names list and key-list arguments match and false
otherwise.
If a header listed in the header-names argument exists, it contains If a header listed in the header-names argument exists, it contains
the empty key (""). However, if the named header is not present, it the empty key (""). However, if the named header is not present, it
does not contain the empty key. So if a message contained the header does not contain the empty key. So if a message contained the header
X-Caffeine: C8H10N4O2 X-Caffeine: C8H10N4O2
these tests on that header evaluate as follows: these tests on that header evaluate as follows:
header :is ["X-Caffeine"] [""] => false header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true header :contains ["X-Caffeine"] [""] => true
5.8. Test not 5.8. Test not
Syntax: not <test> Syntax: not <test>
skipping to change at page 26, line 8 skipping to change at page 26, line 25
The "true" test always evaluates to true. The "true" test always evaluates to true.
6. Extensibility 6. Extensibility
New control structures, actions, and tests can be added to the New control structures, actions, and tests can be added to the
language. Sites must make these features known to their users; this language. Sites must make these features known to their users; this
document does not define a way to discover the list of extensions document does not define a way to discover the list of extensions
supported by the server. supported by the server.
Any extensions to this language MUST define a capability string that Any extensions to this language MUST define a capability string that
uniquely identifies that extension. If a new version of an extension uniquely identifies that extension. Capability string are case-
changes the functionality of a previously defined extension, it MUST sensitive; for example, "foo" and "FOO" are different capabilities.
use a different name. If a new version of an extension changes the functionality of a
previously defined extension, it MUST use a different name.
In a situation where there is a submission protocol and an extension In a situation where there is a submission protocol and an extension
advertisement mechanism aware of the details of this language, advertisement mechanism aware of the details of this language,
scripts submitted can be checked against the mail server to prevent scripts submitted can be checked against the mail server to prevent
use of an extension that the server does not support. use of an extension that the server does not support.
Extensions MUST state how they interact with constraints defined in Extensions MUST state how they interact with constraints defined in
section 2.10, e.g., whether they cancel the implicit keep, and which section 2.10, e.g., whether they cancel the implicit keep, and which
actions they are compatible and incompatible with. actions they are compatible and incompatible with.
skipping to change at page 29, line 9 skipping to change at page 29, line 26
See Editor information in this RFC. See Editor information in this RFC.
8. Parsing 8. Parsing
The Sieve grammar is separated into tokens and a separate grammar as The Sieve grammar is separated into tokens and a separate grammar as
most programming languages are. most programming languages are.
8.1. Lexical Tokens 8.1. Lexical Tokens
Sieve scripts are encoded in UTF-8. The following assumes a valid Sieve scripts are encoded in UTF-8. The following assumes a valid
UTF-8 encoding; special characters in Sieve scripts are all ASCII. UTF-8 encoding; special characters in Sieve scripts are all US-ASCII.
The following are tokens in Sieve: The following are tokens in Sieve:
- identifiers - identifiers
- tags - tags
- numbers - numbers
- quoted strings - quoted strings
- multi-line strings - multi-line strings
- other separators - other separators
skipping to change at page 33, line 11 skipping to change at page 33, line 29
multiple times might also allow a user to create a mailbomb triggered multiple times might also allow a user to create a mailbomb triggered
by mail from a specific user. Site- or implementation-defined limits by mail from a specific user. Site- or implementation-defined limits
on actions are useful for this. 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.
Implementations SHOULD take measures to prevent languages from Implementations SHOULD take measures to prevent languages from
looping. looping.
As with any filter on a message stream, if the sieve implementation
and the mail agents 'behind' sieve in the message stream differ in
their interpretation of the messages, it may be possible for an
attacker to subvert the filter. Of particular note are differences
in the interpretation of malformed messages (e.g., missing or extra
syntax characters) or those that exhibit corner cases (e.g., NUL
octects encoded via [MIME3]).
11. Acknowledgments 11. Acknowledgments
This document has been revised in part based on comments and This document has been revised in part based on comments and
discussions that took place on and off the SIEVE mailing list. discussions that took place on and off the SIEVE mailing list.
Thanks to Cyrus Daboo, Ned Freed, Michael Haardt, Kjetil Torgrim Thanks to Cyrus Daboo, Ned Freed, Michael Haardt, Kjetil Torgrim
Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski, Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski,
and Nigel Swinson for reviews and suggestions. and Nigel Swinson for reviews and suggestions.
12. Editors' Addresses 12. Editors' Addresses
skipping to change at page 33, line 26 skipping to change at page 34, line 4
Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski, Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski,
and Nigel Swinson for reviews and suggestions. and Nigel Swinson for reviews and suggestions.
12. Editors' Addresses 12. Editors' Addresses
Philip Guenther Philip Guenther
Sendmail, Inc. Sendmail, Inc.
6425 Christie St. Ste 400 6425 Christie St. Ste 400
Emeryville, CA 94608 Emeryville, CA 94608
Email: guenther@sendmail.com Email: guenther@sendmail.com
Tim Showalter Tim Showalter
Email: tjs@psaux.com Email: tjs@psaux.com
13. Normative References 13. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[COLLATION] Newman, C. and M. Duerst, "Internet Application Protocol [COLLATION] Newman, C. and M. Duerst, "Internet Application Protocol
Collation Registry" draft-newman-i18n-comparator-03.txt Collation Registry" draft-newman-i18n-
(work in progress), October 2004. comparator-03.txt (work in progress), October 2004.
[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 Message Extensions (MIME) Part One: Format of Internet
Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, November 1996
[MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition [MDN] T. Hansen, Ed., G. Vaudreuil, Ed., "Message Disposition
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[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 35, line 35 skipping to change at page 36, line 16
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Append A. Change History Append A. Change History
This section will be removed when this document leaves the Internet- This section will be removed when this document leaves the Internet-
Draft stage. Draft stage.
Open Issues: Open Issues:
- should 'redirect' provide an argument for specifying the envelope
sender
- should it be an error to give 'envelope' an envelope-part name - should it be an error to give 'envelope' an envelope-part name
other than "from" or "to"? other than "from" or "to"?
- should the requirements in 2.7.2 be tightened up?
Changes from draft-ietf-sieve-3028bis-02.txt
1. Change "ASCII" to "US-ASCII" throughout
2. Tweak section 2.7.2 to not require use of UTF-8 internally and
to explicitly leave implementation-defined the handling of text
that can't be converted to Unicode
3. Add reference to RFC 2047
4. Clarify that capability strings are case-sensitive
5. Clarify that address, envelope, and header return false if no
combination of arguments match
6. Directly state that code that isn't reached may still be checked
for errors.
7. Invalid header name syntax is not an error
8. Remove description of header unfolding that conflicts with
[IMAIL]
9. Warn that filters may be subvertable if agents interpret messages
differently
10. Encoded NUL octets SHOULD NOT cause truncation
Changes from draft-ietf-sieve-3028bis-01.txt Changes from draft-ietf-sieve-3028bis-01.txt
1. Remove ban on side effects 1. Remove ban on side effects
2. Remove definition of the 'reject' action, as it is being moved 2. Remove definition of the 'reject' action, as it is being moved
to the doc that also defines the 'refuse' action to the doc that also defines the 'refuse' action
3. Update capability registrations to reference the mailing list 3. Update capability registrations to reference the mailing list
4. Add Tim back as an editor 4. Add Tim back as an editor
5. Refer to the zero-length string ("") as "empty" instead of 5. Refer to the zero-length string ("") as "empty" instead of
"null" "null"
 End of changes. 

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