draft-ietf-sieve-3028bis-05.txt   draft-ietf-sieve-3028bis-06.txt 
Network Working Group P. Guenther Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: May 2006 T. Showalter Expires: September 2006 T. Showalter
Obsoletes: 3028 (if approved) Editors Obsoletes: 3028 (if approved) Editors
November 2005 March 2006
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-05.txt draft-ietf-sieve-3028bis-06.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 1, line 43 skipping to change at page 1, line 43
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Standard Track RFC for the Internet Community. editor as a Standard Track RFC for the Internet Community.
Discussion and suggestions for improvement are requested, and should Discussion and suggestions for improvement are requested, and should
be sent to ietf-mta-filters@imc.org. Distribution of this memo is be sent to ietf-mta-filters@imc.org. Distribution of this memo is
unlimited. unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes a language for filtering email messages at This document describes a language for filtering email messages at
time of final delivery. It is designed to be implementable on either time of final delivery. It is designed to be implementable on either
a mail client or mail server. It is meant to be extensible, simple, a mail client or mail server. It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating and independent of access protocol, mail architecture, and operating
system. It is suitable for running on a mail server where users may system. It is suitable for running on a mail server where users may
not be allowed to execute arbitrary programs, such as on black box not be allowed to execute arbitrary programs, such as on black box
Internet Message Access Protocol (IMAP) servers, as it has no Internet Message Access Protocol (IMAP) servers, as it has no
skipping to change at page 8, line 21 skipping to change at page 8, line 21
2.4.2.1. String Lists 2.4.2.1. String Lists
When matching patterns, it is frequently convenient to match against When matching patterns, it is frequently convenient to match against
groups of strings instead of single strings. For this reason, a list groups of strings instead of single strings. For this reason, a list
of strings is allowed in many tests, implying that if the test is of strings is allowed in many tests, implying that if the test is
true using any one of the strings, then the test is true. true using any one of the strings, then the test is true.
Implementations are encouraged to use short-circuit evaluation in Implementations are encouraged to use short-circuit evaluation in
these cases. these cases.
For instance, the test `header :contains ["To", "Cc"] For instance, the test `header :contains ["To", "Cc"]
["me@example.com", "me00@landru.example.edu"]' is true if either the ["me@example.com", "me00@landru.example.edu"]' is true if either a To
To header or Cc header of the input message contains either of the header or Cc header of the input message contains either of the email
email addresses "me@example.com" or "me00@landru.example.edu". addresses "me@example.com" or "me00@landru.example.edu".
Conversely, in any case where a list of strings is appropriate, a Conversely, in any case where a list of strings is appropriate, a
single string is allowed without being a member of a list: it is single string is allowed without being a member of a list: it is
equivalent to a list with a single member. This means that the test equivalent to a list with a single member. This means that the test
`exists "To"' is equivalent to the test `exists ["To"]'. `exists "To"' is equivalent to the test `exists ["To"]'.
2.4.2.2. Headers 2.4.2.2. Headers
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
skipping to change at page 20, line 12 skipping to change at page 20, line 12
Implementations MAY limit the number of certain actions taken (see Implementations MAY limit the number of certain actions taken (see
section 2.10.4). section 2.10.4).
4.1. Action fileinto 4.1. Action fileinto
Usage: fileinto <folder: string> Usage: fileinto <folder: string>
The "fileinto" action delivers the message into the specified folder. The "fileinto" action delivers the message into the specified folder.
Implementations SHOULD support fileinto, but in some environments Implementations SHOULD support fileinto, but in some environments
this may be impossible. this may be impossible. Implementations MAY place restrictions on
folder names; use of an invalid folder name MAY be treated as an
error or result in delivery to an implementation-defined folder.
The capability string for use with the require command is "fileinto". The capability string for use with the require command is "fileinto".
In the following script, message A is filed into folder In the following script, message A is filed into folder
"INBOX.harassment". "INBOX.harassment".
Example: require "fileinto"; Example: require "fileinto";
if header :contains ["from"] "coyote" { if header :contains ["from"] "coyote" {
fileinto "INBOX.harassment"; fileinto "INBOX.harassment";
} }
skipping to change at page 25, line 21 skipping to change at page 25, line 22
does not match any key, including the empty key. So if a message does not match any key, including the empty key. So if a message
contained the header contained the header
X-Caffeine: C8H10N4O2 X-Caffeine: C8H10N4O2
these tests on that header evaluate as follows: these tests on that header evaluate as follows:
header :is ["X-Caffeine"] [""] => false header :is ["X-Caffeine"] [""] => false
header :contains ["X-Caffeine"] [""] => true header :contains ["X-Caffeine"] [""] => true
The preferred way to test whether a given header is either empty or Testing whether a given header is either absent or doesn't contain
absent is to combine an "exists" test and a "header" test: any non-whitespace characters can be done using a negated "header"
test:
anyof (header :is "Cc" "", not exists "Cc") not header :matches "Cc" "?*"
5.8. Test not 5.8. Test not
Usage: not <test1: test> Usage: not <test1: test>
The "not" test takes some other test as an argument, and yields the The "not" test takes some other test as an argument, and yields the
opposite result. "not false" evaluates to "true" and "not true" opposite result. "not false" evaluates to "true" and "not true"
evaluates to "false". evaluates to "false".
5.9. Test size 5.9. Test size
skipping to change at page 34, line 19 skipping to change at page 34, line 23
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" draft-
newman-i18n-comparator-04.txt (work in progress), newman-i18n-comparator-07.txt (work in progress),
July 2005. 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 Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
skipping to change at page 35, line 21 skipping to change at page 35, line 25
Groupware, Saul Greenberg, editor, Harcourt Brace Groupware, Saul Greenberg, editor, Harcourt Brace
Jovanovich, 1991. Reprinted in Readings in Groupware and Jovanovich, 1991. Reprinted in Readings in Groupware and
Computer-Supported Cooperative Work, Ronald Baecker, Computer-Supported Cooperative Work, Ronald Baecker,
editor, Morgan Kaufmann, 1993. editor, Morgan Kaufmann, 1993.
[IMAP] Crispin, M., "Internet Message Access Protocol - version [IMAP] Crispin, M., "Internet Message Access Protocol - version
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
14. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
skipping to change at page 36, line 22 skipping to change at page 36, line 26
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Append A. Change History Append A. Change History
This section will be replaced with a summary of the changes since RFC This section will be replaced with a summary of the changes since RFC
3028 when this document leaves the Internet-Draft stage. 3028 when this document leaves the Internet-Draft stage.
Open Issues: Open Issues:
1. Compression of embedded whitespace 1. Merge reject back in with textual changes to permit MDNs and
2. Merge reject back in with textual changes to permit MDNs and
protocol level rejection protocol level rejection
2. Should this recommend/require that fileinto map UTF-8 to mUTF-7
when working with an IMAP store?
Changes from draft-ietf-sieve-3028bis-05.txt Changes from draft-ietf-sieve-3028bis-05.txt
1. Add non-terminals for MATCH-TYPE, COMPARATOR, and ADDRESS-PART 1. The specifics of what names are acceptable for fileinto and
2. Strip leading and trailing whitespace in the value being matched the handling of invalid names are both implementation-defined.
by header 2. Update to draft-newman-i18n-comparator-07.txt
3. Collations operate on octets, not characters, and for character 3. Adjust the example in 5.7 again
data that is the UTF-8 encoding of the Unicode characters
4. :matches uses character definition of comparator
Changes from draft-ietf-sieve-3028bis-04.txt Changes from draft-ietf-sieve-3028bis-04.txt
1. Change "Syntax:" to "Usage:" 1. Change "Syntax:" to "Usage:"
2. Update ABNF reference to RFC 4234 2. Update ABNF reference to RFC 4234
3. Add non-terminals for MATCH-TYPE, COMPARATOR, and ADDRESS-PART
4. Strip leading and trailing whitespace in the value being matched
by header
5. Collations operate on octets, not characters, and for character
data that is the UTF-8 encoding of the Unicode characters
6. :matches uses character definition of comparator
Changes from draft-ietf-sieve-3028bis-03.txt Changes from draft-ietf-sieve-3028bis-03.txt
1. Remove section 2.4.2.4., MIME Parts, as unreferenced 1. Remove section 2.4.2.4., MIME Parts, as unreferenced
2. Update to draft-newman-i18n-comparator-04.txt 2. Update to draft-newman-i18n-comparator-04.txt
3. Various tweaks to examples and syntax lines 3. Various tweaks to examples and syntax lines
4. Define "control structure" as a control command with a block 4. Define "control structure" as a control command with a block
argument, then use it consistently. Reword description of argument, then use it consistently. Reword description of
blocks to match blocks to match
5. Clarify that "header" can never match an absent header and give 5. Clarify that "header" can never match an absent header and give
the preferred way to test for absent or empty the preferred way to test for absent or empty
 End of changes. 14 change blocks. 
22 lines changed or deleted 30 lines changed or added

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