draft-ietf-sieve-3028bis-01.txt   draft-ietf-sieve-3028bis-02.txt 
Network Working Group P. Guenther
Internet-Draft Sendmail, Inc. Internet-Draft Sendmail, Inc.
Expires: November 2005 May 2005 Expires: December 2005 T. Showalter
Obsoletes: 3028 (if approved) Editors
June 2005
Sieve: An Email Filtering Language Sieve: An Email Filtering Language
draft-ietf-sieve-3028bis-01.txt draft-ietf-sieve-3028bis-02.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 13 skipping to change at page 2, line 14
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
variables, loops, or ability to shell out to external programs. variables, loops, or ability to shell out to external programs.
Table of Contents Table of Contents
1. Introduction ........................................... 3 1. Introduction ........................................... 3
1.1. Conventions Used in This Document ..................... 4 1.1. Conventions Used in This Document ..................... 4
1.2. Example mail messages ................................. 4 1.2. Example mail messages ................................. 5
2. Design ................................................. 5 2. Design ................................................. 5
2.1. Form of the Language .................................. 5 2.1. Form of the Language .................................. 6
2.2. Whitespace ............................................ 5 2.2. Whitespace ............................................ 6
2.3. Comments .............................................. 6 2.3. Comments .............................................. 6
2.4. Literal Data .......................................... 6 2.4. Literal Data .......................................... 6
2.4.1. Numbers ............................................... 6 2.4.1. Numbers ............................................... 6
2.4.2. Strings ............................................... 7 2.4.2. Strings ............................................... 7
2.4.2.1. String Lists .......................................... 7 2.4.2.1. String Lists .......................................... 8
2.4.2.2. Headers ............................................... 8 2.4.2.2. Headers ............................................... 8
2.4.2.3. Addresses ............................................. 8 2.4.2.3. Addresses ............................................. 8
2.4.2.4. MIME Parts ............................................ 9 2.4.2.4. MIME Parts ............................................ 9
2.5. Tests ................................................. 9 2.5. Tests ................................................. 9
2.5.1. Test Lists ............................................ 9 2.5.1. Test Lists ............................................ 9
2.6. Arguments ............................................. 9 2.6. Arguments ............................................. 9
2.6.1. Positional Arguments .................................. 9 2.6.1. Positional Arguments .................................. 9
2.6.2. Tagged Arguments ...................................... 10 2.6.2. Tagged Arguments ...................................... 10
2.6.3. Optional Arguments .................................... 10 2.6.3. Optional Arguments .................................... 10
2.6.4. Types of Arguments .................................... 10 2.6.4. Types of Arguments .................................... 10
2.7. String Comparison ..................................... 11 2.7. String Comparison ..................................... 11
2.7.1. Match Type ............................................ 11 2.7.1. Match Type ............................................ 11
2.7.2. Comparisons Across Character Sets ..................... 12 2.7.2. Comparisons Across Character Sets ..................... 12
2.7.3. Comparators ........................................... 12 2.7.3. Comparators ........................................... 12
2.7.4. Comparisons Against Addresses ......................... 13 2.7.4. Comparisons Against Addresses ......................... 14
2.8. Blocks ................................................ 14 2.8. Blocks ................................................ 14
2.9. Commands .............................................. 14 2.9. Commands .............................................. 14
2.10. Evaluation ............................................ 15 2.10. Evaluation ............................................ 15
2.10.1. Action Interaction .................................... 15 2.10.1. Action Interaction .................................... 15
2.10.2. Implicit Keep ......................................... 15 2.10.2. Implicit Keep ......................................... 15
2.10.3. Message Uniqueness in a Mailbox ....................... 15 2.10.3. Message Uniqueness in a Mailbox ....................... 16
2.10.4. Limits on Numbers of Actions .......................... 16 2.10.4. Limits on Numbers of Actions .......................... 16
2.10.5. Extensions and Optional Features ...................... 16 2.10.5. Extensions and Optional Features ...................... 16
2.10.6. Errors ................................................ 17 2.10.6. Errors ................................................ 17
2.10.7. Limits on Execution ................................... 17 2.10.7. Limits on Execution ................................... 17
3. Control Commands ....................................... 17 3. Control Commands ....................................... 17
3.1. Control Structure If .................................. 18 3.1. Control Structure If .................................. 18
3.2. Control Structure Require ............................. 19 3.2. Control Structure Require ............................. 19
3.3. Control Structure Stop ................................ 19 3.3. Control Structure Stop ................................ 19
4. Action Commands ........................................ 19 4. Action Commands ........................................ 19
4.1. Action reject ......................................... 20 4.1. Action fileinto ....................................... 20
4.2. Action fileinto ....................................... 20 4.2. Action redirect ....................................... 20
4.3. Action redirect ....................................... 21 4.3. Action keep ........................................... 20
4.4. Action keep ........................................... 21 4.4. Action discard ........................................ 21
4.5. Action discard ........................................ 22 5. Test Commands .......................................... 21
5. Test Commands .......................................... 22 5.1. Test address .......................................... 22
5.1. Test address .......................................... 23 5.2. Test allof ............................................ 22
5.2. Test allof ............................................ 23 5.3. Test anyof ............................................ 23
5.3. Test anyof ............................................ 24 5.4. Test envelope ......................................... 23
5.4. Test envelope ......................................... 24 5.5. Test exists ........................................... 24
5.5. Test exists ........................................... 25 5.6. Test false ............................................ 24
5.6. Test false ............................................ 25 5.7. Test header ........................................... 24
5.7. Test header ........................................... 25 5.8. Test not .............................................. 25
5.8. Test not .............................................. 26 5.9. Test size ............................................. 25
5.9. Test size ............................................. 26 5.10. Test true ............................................. 25
5.10. Test true ............................................. 26 6. Extensibility .......................................... 25
6. Extensibility .......................................... 26 6.1. Capability String ..................................... 26
6.1. Capability String ..................................... 27 6.2. IANA Considerations ................................... 26
6.2. IANA Considerations ................................... 28 6.2.1. Template for Capability Registrations ................. 27
6.2.1. Template for Capability Registrations ................. 28 6.2.2. Initial Capability Registrations ...................... 27
6.2.2. Initial Capability Registrations ...................... 28 6.3. Capability Transport .................................. 28
6.3. Capability Transport .................................. 29 7. Transmission ........................................... 28
7. Transmission ........................................... 29 8. Parsing ................................................ 29
8. Parsing ................................................ 30 8.1. Lexical Tokens ........................................ 29
8.1. Lexical Tokens ........................................ 30
8.2. Grammar ............................................... 31 8.2. Grammar ............................................... 31
9. Extended Example ....................................... 32 9. Extended Example ....................................... 31
10. Security Considerations ................................ 34 10. Security Considerations ................................ 32
11. Acknowledgments ........................................ 34 11. Acknowledgments ........................................ 33
12. Author's Address ....................................... 34 12. Editor's Address ....................................... 33
13. References ............................................. 34 13. Normative References ................................... 33
14. Full Copyright Statement ............................... 36 14. Informative References ................................. 34
14. Full Copyright Statement ............................... 34
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
skipping to change at page 9, line 33 skipping to change at page 9, line 33
embedding typed data within a Sieve script so that, among other embedding typed data within a Sieve script so that, among other
things, character sets other than UTF-8 can be used for output things, character sets other than UTF-8 can be used for output
messages. messages.
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/else to
decide which block of code is run. decide which block of code is run.
Tests MUST NOT have side effects. That is, a test cannot affect the
state of the filter or message. No tests in this specification have
side effects, and side effects are forbidden in extension tests as
well.
The rationale for this is that tests with side effects impair
readability and maintainability and are difficult to represent in a
graphic interface for generating scripts. Side effects are confined
to actions where they are clearer.
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. tests.
Example: if anyof (not exists ["From", "Date"], Example: if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.edu") { header :contains "from" "fool@example.edu") {
discard; discard;
skipping to change at page 12, line 6 skipping to change at page 11, line 44
specification: ":is", ":contains", and ":matches". Match type specification: ":is", ":contains", and ":matches". Match type
arguments are supplied to those commands which allow them to specify arguments are supplied to those commands which allow them to specify
what kind of match is to be performed. what kind of match is to be performed.
These are used as tagged arguments to tests that perform string These are used as tagged arguments to tests that perform string
comparison. 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 null 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 null key ":is" and only ":is" the null 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, and "?" matches a single character. matches zero or more characters, and "?" matches a single character.
"?" and "*" may be escaped as "\\?" and "\\*" in strings to match "?" and "*" may be escaped as "\\?" and "\\*" in strings to match
against themselves. The first backslash escapes the second against themselves. The first backslash escapes the second
backslash; together, they escape the "*". This is awkward, but it is backslash; 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.
skipping to change at page 15, line 50 skipping to change at page 15, line 40
2.10.2. Implicit Keep 2.10.2. Implicit Keep
Previous experience with filtering systems suggests that cases tend Previous experience with filtering systems suggests that cases tend
to be missed in scripts. To prevent errors, Sieve has an "implicit to be missed in scripts. To prevent errors, Sieve has an "implicit
keep". keep".
An implicit keep is a keep action (see 4.4) performed in absence of An implicit keep is a keep action (see 4.4) performed in absence of
any action that cancels the implicit keep. any action that cancels the implicit keep.
An implicit keep is performed if a message is not written to a An implicit keep is performed if a message is not written to a
mailbox, redirected to a new address, rejected, or explicitly thrown mailbox, redirected to a new address, or explicitly thrown out. That
out. That is, if a fileinto, a keep, a redirect, a reject, or a is, if a fileinto, a keep, a redirect, or a discard is performed, an
discard is performed, an implicit keep is not. implicit keep is not.
Some actions may be defined to not cancel the implicit keep. These Some actions may be defined to not cancel the implicit keep. These
actions may not directly affect the delivery of a message, and are actions may not directly affect the delivery of a message, and are
used for their side effects. None of the actions specified in this used for their side effects. None of the actions specified in this
document meet that criteria, but extension actions will. document meet that criteria, but extension actions will.
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; }
skipping to change at page 16, line 35 skipping to change at page 16, line 27
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 numbers 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 prohibit more than one reject.
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.
Implementations SHOULD prohibit reject when used with other actions.
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. treat it as if they did not support it at all.
skipping to change at page 17, line 44 skipping to change at page 17, line 32
Implementations MAY choose to do a full parse, then evaluate the Implementations MAY choose to do a full parse, then evaluate the
script, then do all actions. Implementations might even go so far as script, then do all actions. Implementations might even go so far as
to ensure that execution is atomic (either all actions are executed to ensure that execution is atomic (either all actions are executed
or none are executed). or none are executed).
Other implementations may choose to parse and run at the same time. Other implementations may choose to parse and run at the same time.
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 (e.g., reject + fileinto) never execute an invalid set of actions before execution, although
before execution, although this could involve solving the Halting this could involve solving the Halting Problem.
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.
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
skipping to change at page 20, line 4 skipping to change at page 19, line 38
after a command other than require. after a command other than require.
Example: require ["fileinto", "reject"]; Example: require ["fileinto", "reject"];
Example: require "fileinto"; Example: require "fileinto";
require "vacation"; require "vacation";
3.3. Control Structure Stop 3.3. Control Structure Stop
Syntax: stop Syntax: stop
The "stop" action ends all processing. If no actions have been The "stop" action ends all processing. If no actions have been
executed, then the keep action is taken. executed, then the keep action is taken.
4. Action Commands 4. Action Commands
This document supplies five actions that may be taken on a message: This document supplies four actions that may be taken on a message:
keep, fileinto, redirect, reject, and discard. keep, fileinto, redirect, and discard.
Implementations MUST support the "keep", "discard", and "redirect" Implementations MUST support the "keep", "discard", and "redirect"
actions. actions.
Implementations SHOULD support "reject" and "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 reject 4.1. Action fileinto
Syntax: reject <reason: string>
The optional "reject" action refuses delivery of a message by sending
back an [MDN] to the sender and cancels the implict keep. It resends
the message to the sender, wrapping it in a "reject" form, noting
that it was rejected by the recipient. In the following script,
message A is rejected and returned to the sender.
Example: if header :contains "from" "coyote@desert.example.org" {
reject "I am not taking mail from you, and I don't want
your birdseed, either!";
}
A reject message MUST take the form of a failure MDN as specified by
[MDN]. The human-readable portion of the message, the first
component of the MDN, contains the human readable message describing
the error, and it SHOULD contain additional text alerting the
original sender that mail was refused by a filter. This part of the
MDN might appear as follows:
------------------------------------------------------------
Message was refused by recipient's mail filtering program. Reason
given was as follows:
I am not taking mail from you, and I don't want your birdseed,
either!
------------------------------------------------------------
The MDN action-value field as defined in the MDN specification MUST
be "deleted" and MUST have the MDN-sent-automatically and automatic-
action modes set.
Because some implementations can not or will not implement the reject
command, it is optional. The capability string to be used with the
require command is "reject".
4.2. Action fileinto
Syntax: fileinto <folder: string> Syntax: 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.
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";
} }
4.3. Action redirect 4.2. Action redirect
Syntax: redirect <address: string> Syntax: redirect <address: string>
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. The "redirect" modifies the headers, but it may add new headers. The "redirect" modifies the
envelope recipient. envelope recipient.
The redirect command performs an MTA-style "forward"--that is, what The redirect command performs an MTA-style "forward"--that is, what
skipping to change at page 22, line 5 skipping to change at page 20, line 49
message ID, wrapping the old message in a new one.) message ID, wrapping the old message in a new one.)
A simple script can be used for redirecting all mail: A simple script can be used for redirecting all mail:
Example: redirect "bart@example.edu"; Example: redirect "bart@example.edu";
Implementations SHOULD take measures to implement loop control, Implementations SHOULD 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. If an implementation detects a loop, it causes an error.
4.4. Action keep 4.3. Action keep
Syntax: keep Syntax: 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
needing to understand the user's setup, or the underlying mail needing to understand the user's setup, or the underlying mail
system. system.
For instance, in an implementation where the Internet Message Access For instance, in an implementation where the Internet Message Access
Protocol (IMAP) server is running scripts on behalf of the user at Protocol (IMAP) server is running scripts on behalf of the user at
skipping to change at page 22, line 27 skipping to change at page 21, line 22
For instance, in an implementation where the Internet Message Access For instance, in an implementation where the Internet Message Access
Protocol (IMAP) server is running scripts on behalf of the user at Protocol (IMAP) server is running scripts on behalf of the user at
time of delivery, a keep command is equivalent to a fileinto "INBOX". time of delivery, a keep command is equivalent to a fileinto "INBOX".
Example: if size :under 1M { keep; } else { discard; } Example: if size :under 1M { keep; } else { discard; }
Note that the above script is identical to the one below. Note that the above script is identical to the one below.
Example: if not size :under 1M { discard; } Example: if not size :under 1M { discard; }
4.5. Action discard 4.4. Action discard
Syntax: discard Syntax: discard
Discard is used to silently throw away the message. It does so by Discard is used to silently throw away the message. It does so by
simply canceling the implicit keep. If discard is used with other simply canceling the implicit keep. If discard is used with other
actions, the other actions still happen. Discard is compatible with actions, the other actions still happen. Discard is compatible with
all other actions. (For instance fileinto+discard is equivalent to all other actions. (For instance fileinto+discard is equivalent to
fileinto.) fileinto.)
Discard MUST be silent; that is, it MUST NOT return a non-delivery Discard MUST be silent; that is, it MUST NOT return a non-delivery
skipping to change at page 26, line 6 skipping to change at page 24, line 51
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 string-list and key-list arguments match.
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 null 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 null 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 27, line 45 skipping to change at page 26, line 40
name of the vendor and product, such as "vnd.acme.rocket-sled". name of the vendor and product, such as "vnd.acme.rocket-sled".
The following capability strings are defined by this document: The following capability strings are defined by this document:
envelope The string "envelope" indicates that the implementation envelope The string "envelope" indicates that the implementation
supports the "envelope" command. supports the "envelope" command.
fileinto The string "fileinto" indicates that the implementation fileinto The string "fileinto" indicates that the implementation
supports the "fileinto" command. supports the "fileinto" command.
reject The string "reject" indicates that the implementation
supports the "reject" command.
comparator- The string "comparator-elbonia" is provided if the comparator- The string "comparator-elbonia" is provided if the
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-en;ascii-casemap", "comparator-i;octet", "comparator-en;ascii-casemap",
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
skipping to change at page 28, line 40 skipping to change at page 27, line 33
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
Capability keyword: fileinto Capability keyword: fileinto
Capability arguments: fileinto <folder: string> Capability arguments: fileinto <folder: string>
Standards Track/IESG-approved experimental RFC number: Standards Track/IESG-approved experimental RFC number:
This RFC (Sieve base spec) This RFC (Sieve base spec)
Person and email address to contact for further information: Person and email address to contact for further information:
Tim Showalter The Sieve discussion list <ietf-mta-filters@imc.org>
tjs@mirapoint.com
Capability name: reject
Capability keyword: reject
Capability arguments: reject <reason: string>
Standards Track/IESG-approved experimental RFC number:
This RFC (Sieve base spec)
Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com
Capability name: envelope Capability name: envelope
Capability keyword: envelope Capability keyword: envelope
Capability arguments: Capability arguments:
envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE]
<envelope-part: string-list> <key-list: string-list> <envelope-part: string-list> <key-list: string-list>
Standards Track/IESG-approved experimental RFC number: Standards Track/IESG-approved experimental RFC number:
This RFC (Sieve base spec) This RFC (Sieve base spec)
Person and email address to contact for further information: Person and email address to contact for further information:
Tim Showalter The Sieve discussion list <ietf-mta-filters@imc.org>
tjs@mirapoint.com
Capability name: comparator-* Capability name: comparator-*
Capability keyword: Capability keyword:
comparator-* (anything starting with "comparator-") comparator-* (anything starting with "comparator-")
Capability arguments: (none) Capability arguments: (none)
Standards Track/IESG-approved experimental RFC number: Standards Track/IESG-approved experimental RFC number:
This RFC, Sieve, by reference to [COLLATION] This RFC, Sieve, by reference to [COLLATION]
Person and email address to contact for further information: Person and email address to contact for further information:
Tim Showalter
tjs@mirapoint.com 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 As the range of mail systems that this document is intended to apply
to is quite varied, a method of advertising which capabilities an to is quite varied, a method of advertising which capabilities an
implementation supports is difficult due to the wide range of implementation supports is difficult due to the wide range of
possible implementations. Such a mechanism, however, should have the possible implementations. Such a mechanism, however, should have the
property that the implementation can advertise the complete set of property that the implementation can advertise the complete set of
extensions that it supports. extensions that it supports.
skipping to change at page 30, line 19 skipping to change at page 28, line 48
Applications which use this media type: sieve-enabled mail servers Applications which use this media type: sieve-enabled mail servers
Additional information: Additional information:
Magic number(s): Magic number(s):
File extension(s): .siv File extension(s): .siv
Macintosh File Type Code(s): Macintosh File Type Code(s):
Person & email address to contact for further information: Person & email address to contact for further information:
See the discussion list at ietf-mta-filters@imc.org. See the discussion list at ietf-mta-filters@imc.org.
Intended usage: Intended usage:
COMMON COMMON
Author/Change controller: Author/Change controller:
See Author 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 ASCII.
skipping to change at page 31, line 13 skipping to change at page 29, line 42
*(not-star-slash *not-star 1*STAR) "/" *(not-star-slash *not-star 1*STAR) "/"
; No */ allowed inside a comment. ; No */ allowed inside a comment.
; (No * is allowed unless it is the last ; (No * is allowed unless it is the last
; character, or unless it is followed by a ; character, or unless it is followed by a
; character that isn't a slash.) ; character that isn't a slash.)
STAR = "*" STAR = "*"
not-star = CRLF / %x01-09 / %x0b-0c / %x0e-29 / %x2b-7f / not-star = CRLF / %x01-09 / %x0b-0c / %x0e-29 / %x2b-7f /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
; either a CRLF pair, OR a single UTF-8 character ; either a CRLF pair, OR a single UTF-8
; other than NUL, CR, LF, or star ; character other than NUL, CR, LF, or star
not-star-or-slash = CRLF / %x01-09 / %x0b-0c / %x0e-29 / %x2b-2e / not-star-or-slash = CRLF / %x01-09 / %x0b-0c / %x0e-29 / %x2b-2e /
%x30-7f / UTF8-2 / UTF8-3 / UTF8-4 %x30-7f / UTF8-2 / UTF8-3 / UTF8-4
; either a CRLF pair, OR a single UTF-8 character ; either a CRLF pair, OR a single UTF-8
; other than NUL, CR, LF, star, or slash ; character other than NUL, CR, LF, star,
; or slash
UTF8-NOT-CRLF = %x01-09 / %x0b-0c / %x0e-7f / UTF8-NOT-CRLF = %x01-09 / %x0b-0c / %x0e-7f /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
; a single UTF-8 character other than NUL, ; a single UTF-8 character other than NUL,
; CR, or LF ; CR, or LF
UTF8-NOT-PERIOD = %x01-09 / %x0b-0c / %x0e-2d / %x2f-7f / UTF8-NOT-PERIOD = %x01-09 / %x0b-0c / %x0e-2d / %x2f-7f /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
; a single UTF-8 character other than NUL, ; a single UTF-8 character other than NUL,
; CR, LF, or period ; CR, LF, or period
skipping to change at page 33, line 21 skipping to change at page 31, line 50
9. Extended Example 9. Extended Example
The following is an extended example of a Sieve script. Note that it The following is an extended example of a Sieve script. Note that it
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", "reject"]; require ["fileinto"];
#
# Reject any large messages (note that the four leading dots get
# "stuffed" to three)
#
if size :over 1M
{
reject text:
Please do not send me large attachments.
Put your file on a server and send me the URL.
Thank you.
.... Fred
.
;
stop;
}
# #
# 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 folder
# #
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" folder
} }
# #
# Keep all messages to or from people in my company # Keep all messages to or from people in my company
skipping to change at page 34, line 49 skipping to change at page 33, line 15
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.
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, Kjetil Torgrim Homme, Barry Leiba, Thanks to Cyrus Daboo, Ned Freed, Michael Haardt, Kjetil Torgrim
Mark E. Mallett, Alexey Melnikov, Rob Siemborski, and Nigel Swinson Homme, Barry Leiba, Mark E. Mallett, Alexey Melnikov, Rob Siemborski,
for reviews and suggestions. and Nigel Swinson for reviews and suggestions.
The editor gratefully acknowledges the extensive work of Tim
Showalter as the author of the RFC 3028.
12. Editor's 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
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-comparator-03.txt
(work in progress), October 2004. (work in progress), October 2004.
[IMAIL] P. Resnick, Ed., "Internet Message Format", RFC 2822, [IMAIL] P. Resnick, Ed., "Internet Message Format", RFC 2822,
skipping to change at page 37, line 18 skipping to change at page 35, line 31
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
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-
Draft stage.
Open Issues: Open Issues:
- pull 'reject' out of this doc? Whether or not that happens, the - should 'redirect' provide an argument for specifying the envelope
security considerations for 'reject' need to be updated to sender
document the "joe job" problem - should it be an error to give 'envelope' an envelope-part name
- should 'redirect' provide an argument for specifying the envelope sender other than "from" or "to"?
- should the requirements in 2.7.2 be tightened up?
Changes from draft-ietf-sieve-3028bis-01.txt
1. Remove ban on side effects
2. Remove definition of the 'reject' action, as it is being moved
to the doc that also defines the 'refuse' action
3. Update capability registrations to reference the mailing list
4. Add Tim back as an editor
5. Refer to the zero-length string ("") as "empty" instead of
"null"
Changes from draft-ietf-sieve-3028bis-00.txt Changes from draft-ietf-sieve-3028bis-00.txt
1. More grammar corrections: 1. More grammar corrections:
- permit /***/, - permit /***/,
- remove ambiguity in finding end of bracket comment, - remove ambiguity in finding end of bracket comment,
- require valid UTF-8, - require valid UTF-8,
- express quoting in the grammar - express quoting in the grammar
- ban bare CR and LF in all locations - ban bare CR and LF in all locations
2. Correct a bunch of whitespace and linewrapping nits 2. Correct a bunch of whitespace and linewrapping nits
3. Update IMAIL and SMTP references RFC 2822 and RFC 2821 3. Update IMAIL and SMTP references RFC 2822 and RFC 2821
4. Require support for en;ascii-casemap comparator as well as the 4. Require support for en;ascii-casemap comparator as well as the
old i;ascii-casemap. As with the old one, you do not need to old i;ascii-casemap. As with the old one, you do not need to
use 'require' to use the new comparator. use 'require' to use the new comparator.
skipping to change at page 37, line 49 skipping to change at page 36, line 28
7. Update Acknowledgments 7. Update Acknowledgments
Changes from RFC 3028 Changes from RFC 3028
1. Split references into normative and informative 1. Split references into normative and informative
2. Update references to current versions of DSN, IMAP, MDN, and 2. Update references to current versions of DSN, IMAP, MDN, and
UTF-8 RFCs UTF-8 RFCs
3. Replace "e-mail" with "email" 3. Replace "e-mail" with "email"
4. Incorporate RFC 3028 errata 4. Incorporate RFC 3028 errata
5. The "reject" action cancels the implicit keep 5. The "reject" action cancels the implicit keep
6. Replace references to ACAP with references to the i18n-comparator 6. Replace references to ACAP with references to the i18n-comparator
draft. Further work is needed to completely sync with that draft. draft. Further work is needed to completely sync with that
draft.
7. Start to update grammar to only permit legal UTF-8 (incomplete) 7. Start to update grammar to only permit legal UTF-8 (incomplete)
and correct various other errors and typos and correct various other errors and typos
8. Update IPR broilerplate to RFC 3978/3979 8. Update IPR broilerplate to RFC 3978/3979
 End of changes. 

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