draft-ietf-sieve-3028bis-08.txt   draft-ietf-sieve-3028bis-09.txt 
Network Working Group P. Guenther Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: January 2007 T. Showalter Expires: February 2007 T. Showalter
Obsoletes: 3028 (if approved) Editors Obsoletes: 3028 (if approved) Editors
August 2006
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-08.txt draft-ietf-sieve-3028bis-09.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 7, line 6 skipping to change at page 7, line 6
Bracketed comments do not nest. Bracketed comments do not nest.
Example: if size :over 100K { /* this is a comment Example: if size :over 100K { /* this is a comment
this is still a comment */ discard /* this is a comment this is still a comment */ discard /* this is a comment
*/ ; */ ;
} }
2.4. Literal Data 2.4. Literal Data
Literal data means data that is not executed, merely evaluated "as Literal data means data that is not executed, merely evaluated "as
is", to be used as arguments to commands. Literal data is limited to is", to be used as arguments to commands. Literal data is limited to
numbers and strings. numbers, strings, and string lists.
2.4.1. Numbers 2.4.1. Numbers
Numbers are given as ordinary decimal numbers. However, those Numbers are given as ordinary decimal numbers. However, those
numbers that have a tendency to be fairly large, such as message numbers that have a tendency to be fairly large, such as message
sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of sizes, MAY have a "K", "M", or "G" appended to indicate a multiple of
a power of two. To be comparable with the power-of-two-based a power of two. To be comparable with the power-of-two-based
versions of SI units that computers frequently use, K specifies versions of SI units that computers frequently use, K specifies
kibi-, or 1,024 (2^10) times the value of the number; M specifies kibi-, or 1,024 (2^10) times the value of the number; M specifies
mebi-, or 1,048,576 (2^20) times the value of the number; and G mebi-, or 1,048,576 (2^20) times the value of the number; and G
skipping to change at page 7, line 33 skipping to change at page 7, line 33
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, US-ASCII 34). A backslash ("\", ASCII 92) inside of a character, US-ASCII 34). A backslash ("\", US-ASCII 92) inside of a
quoted string is followed by either another backslash or a double quoted string is followed by either another backslash or a double
quote. This two-character sequence represents a single backslash or quote. This two-character sequence represents a single backslash or
double- 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"), 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. NUL (US-ASCII 0) is not allowed in strings.
As messages 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 strings will use the UTF-8 encoding. However, section 2.7.2), most strings will use the UTF-8 encoding. However,
implementations MUST accept all strings that match the grammar in implementations MUST accept all strings that match the grammar in
section 8. The ability to use non-UTF-8 encoded strings matches section 8. The ability to use non-UTF-8 encoded strings matches
existing practice and has proven to be useful both in tests for existing practice and has proven to be useful both in tests for
invalid data and in arguments containing raw MIME parts for extension invalid data and in arguments containing raw MIME parts for extension
actions that generate outgoing messages. 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
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. The CRLF before the final period is
lines with a single-dot, lines are dot-stuffed. That is, when considered part of the string. In order to allow the message to
composing a message body, an extra `.' is added before each line contain lines with a single-dot, lines are dot-stuffed. That is,
when 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;
that is, ".foo" is interpreted as ".foo". However, because this is that is, ".foo" is interpreted as ".foo". However, because this is
potentially ambiguous, scripts SHOULD be properly dot-stuffed so such potentially ambiguous, scripts SHOULD be properly dot-stuffed so such
lines do not appear. lines do not appear.
Note that a hashed comment or whitespace may occur in between the Note that a hashed comment or whitespace may occur in between the
"text:" and the CRLF, but not within the string itself. Bracketed "text:" and the CRLF, but not within the string itself. Bracketed
comments are not allowed here. comments are not allowed here.
skipping to change at page 10, line 31 skipping to change at page 10, line 33
2.6.2. Tagged Arguments 2.6.2. Tagged Arguments
This document provides for tagged arguments in the style of This document provides for tagged arguments in the style of
CommonLISP. These are also similar to flags given to commands in CommonLISP. These are also similar to flags given to commands in
most command-line systems. most command-line systems.
A tagged argument is an argument for a command that begins with ":" A tagged argument is an argument for a command that begins with ":"
followed by a tag naming the argument, such as ":contains". This followed by a tag naming the argument, such as ":contains". This
argument means that zero or more of the next tokens have some argument means that zero or more of the next tokens have some
particular meaning depending on the argument. These next tokens may particular meaning depending on the argument. These next tokens may
be numbers or strings but they are never blocks. be literal data but they are never blocks.
Tagged arguments are similar to positional arguments, except that Tagged arguments are similar to positional arguments, except that
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
skipping to change at page 16, line 28 skipping to change at page 16, line 30
For instance, with any of the short messages offered above, the For instance, with any of the short messages offered above, the
following script produces no actions. following script produces no actions.
Example: if size :over 500K { discard; } Example: if size :over 500K { discard; }
As a result, the implicit keep is taken. As a result, the implicit keep is taken.
2.10.3. Message Uniqueness in a Mailbox 2.10.3. Message Uniqueness in a Mailbox
Implementations SHOULD NOT deliver a message to the same folder more Implementations SHOULD NOT deliver a message to the same mailbox more
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
skipping to change at page 20, line 32 skipping to change at page 20, line 34
Implementations MUST support the "keep", "discard", and "redirect" Implementations MUST support the "keep", "discard", and "redirect"
actions. actions.
Implementations SHOULD support "fileinto". Implementations SHOULD support "fileinto".
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 <mailbox: string>
The "fileinto" action delivers the message into the specified folder. The "fileinto" action delivers the message into the specified
Implementations SHOULD support fileinto, but in some environments mailbox. Implementations SHOULD support fileinto, but in some
this may be impossible. Implementations MAY place restrictions on environments this may be impossible. Implementations MAY place
folder names; use of an invalid folder name MAY be treated as an restrictions on mailbox names; use of an invalid mailbox name MAY be
error or result in delivery to an implementation-defined folder. If treated as an error or result in delivery to an implementation-
the implementation uses a different encoding scheme than UTF-8 for defined mailbox. If the implementation uses a different encoding
folder names, it SHOULD reencode the folder name from UTF-8 to its scheme than UTF-8 for mailbox names, it SHOULD reencode the mailbox
encoding scheme. For example, the Internet Message Access Protocol name from UTF-8 to its encoding scheme. For example, the Internet
[IMAP] uses modified UTF-7, such that a folder argument of "odds & Message Access Protocol [IMAP] uses modified UTF-7, such that a
ends" would appear in IMAP as "odds &- ends". mailbox argument of "odds & ends" would appear in IMAP as "odds &-
ends".
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 mailbox
"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";
} }
4.2. Action redirect 4.2. Action redirect
Usage: redirect <address: string> Usage: redirect <address: string>
skipping to change at page 28, line 47 skipping to change at page 28, line 47
5. The "Person and email address to contact for further information" 5. The "Person and email address to contact for further information"
field should be renamed to "Contact address" field should be renamed to "Contact address"
6.2.3. Initial Capability Registrations 6.2.3. Initial Capability Registrations
This RFC updates the the following entries in the IANA registry for This RFC updates the the following entries in the IANA registry for
Sieve extensions. Sieve extensions.
Capability name: fileinto Capability name: fileinto
Description: adds the 'fileinto' action for delivering to a Description: adds the 'fileinto' action for delivering to a
folder 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-")
skipping to change at page 33, line 13 skipping to change at page 33, line 13
does not make use of the implicit keep. does not make use of the implicit keep.
# #
# Example Sieve Filter # Example Sieve Filter
# Declare any optional features or extension used by the script # Declare any optional features or extension used by the script
# #
require ["fileinto"]; require ["fileinto"];
# #
# Handle messages from known mailing lists # Handle messages from known mailing lists
# Move messages from IETF filter discussion list to filter folder # Move messages from IETF filter discussion list to filter mailbox
# #
if header :is "Sender" "owner-ietf-mta-filters@imc.org" if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{ {
fileinto "filter"; # move to "filter" folder fileinto "filter"; # move to "filter" mailbox
} }
# #
# Keep all messages to or from people in my company # Keep all messages to or from people in my company
# #
elsif address :domain :is ["From", "To"] "example.com" elsif address :domain :is ["From", "To"] "example.com"
{ {
keep; # keep in "In" folder keep; # keep in "In" mailbox
} }
# #
# Try and catch unsolicited email. If a message is not to me, # Try and catch unsolicited email. If a message is not to me,
# or it contains a subject known to be spam, file it away. # or it contains a subject known to be spam, file it away.
# #
elsif anyof (not address :all :contains elsif anyof (not address :all :contains
["To", "Cc", "Bcc"] "me@example.com", ["To", "Cc", "Bcc"] "me@example.com",
header :matches "subject" header :matches "subject"
["*make*money*fast*", "*university*dipl*mas*"]) ["*make*money*fast*", "*university*dipl*mas*"])
{ {
# If message header does not contain my address, # If message header does not contain my address,
# it's from a list. # it's from a list.
fileinto "spam"; # move to "spam" folder fileinto "spam"; # move to "spam" mailbox
} }
else else
{ {
# Move all other (non-company) mail to "personal" # Move all other (non-company) mail to "personal"
# folder. # 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 It is equally important that implementations sanity-check the user's
skipping to change at page 35, line 28 skipping to change at page 35, line 28
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.
[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
[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.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC
3028, January 2001.
[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
skipping to change at page 36, line 11 skipping to change at page 36, line 8
System", Int. J. of Man-Machine Studies, April, 1991. System", Int. J. of Man-Machine Studies, April, 1991.
Reprinted in Computer-Supported Cooperative Work and Reprinted in Computer-Supported Cooperative Work and
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.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language", RFC
3028, January 2001.
15. Changes from RFC 3028 15. Changes from RFC 3028
This following list is a summary of the changes that have been made This following list is a summary of the changes that have been made
in the Sieve language base specification from [RFC3028]. in the Sieve language base specification from [RFC3028].
1. Removed ban on tests having side-effects 1. Removed ban on tests having side-effects
2. Removed reject extension (will be specified in a separate RFC) 2. Removed reject extension (will be specified in a separate RFC)
3. Clarified description of comparators to match [COLLATION], the 3. Clarified description of comparators to match [COLLATION], the
new base specification for them new base specification for them
4. Require stripping of leading and trailing whitespace in 4. Require stripping of leading and trailing whitespace in
"header" test "header" test
5. Clarified or tightened handling of many minor items, including: 5. Clarified or tightened handling of many minor items, including:
- invalid [MIME3] encoding - invalid [MIME3] encoding
- invalid addresses in headers - invalid addresses in headers
- invalid header field names in tests - invalid header field names in tests
- 'undefined' comparator result - 'undefined' comparator result
- unknown envelope parts
- null return-path in "envelope" test
6. Capability strings are case-sensitive
7. Clarified that fileinto should reencode non-ASCII mailbox
names to match the mailstore's conventions
8. Errors in the ABNF were corrected
9. The references were updated and split into normative and
informative
16. Full Copyright Statement 16. Full Copyright Statement
Copyright (C) The Internet Society (2006). 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
skipping to change at page 37, line 30 skipping to change at page 37, line 36
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Append A. Change History Append A. Change History
This section will be 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-08.txt
1. [RFC3028] reference is merely informative
2. String lists are literal data
3. Tagged and optional arguments can take any sort of literal data
as arguments
4. Change "folder" to "mailbox" throughout
5. Added more items to the "Changes from RFC 3028" list
6. A multi-line string includes the CRLF before the final dot
Changes from draft-ietf-sieve-3028bis-07.txt Changes from draft-ietf-sieve-3028bis-07.txt
1. Improve description in the extension registrations 1. Improve description in the extension registrations
2. Give IANA directions on how to massage existing registrations 2. Give IANA directions on how to massage existing registrations
into the new form into the new form
3. Added "Changes from RFC 3028" section 3. Added "Changes from RFC 3028" section
4. Updated pages numbers in table of contents 4. Updated pages numbers in table of contents
5. Permit non-UTF-8 octet sequences in comments 5. Permit non-UTF-8 octet sequences in comments
6. It's an error to use conflicting or repeated tagged and optional 6. It's an error to use conflicting or repeated tagged and optional
arguments arguments
7. Update description of script encoding 7. Update description of script encoding
 End of changes. 22 change blocks. 
31 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/