rohrpost

A commandline mail client to change the world as we see it.
git clone git://r-36.net/rohrpost
Log | Files | Refs | LICENSE

commit c1cd5dd02d6645c597a81f5f1efb681af9f59095
parent c742105bf1e76f07544ee3d56300eff2b31934ca
Author: Christoph Lohmann <20h@r-36.net>
Date:   Tue, 24 Jul 2012 12:38:23 +0200

Add sieve RFCs and fix example sieve script.

Diffstat:
proto/sieve.example | 2+-
proto/sieve/rfc3028.txt | 2019+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
proto/sieve/rfc3431.txt | 451+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
proto/sieve/rfc5231.txt | 507+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
proto/sieve/rfc5260.txt | 731+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
proto/sieve/rfc5437.txt | 787+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
proto/sieve/rfc5804.txt | 2747+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 7243 insertions(+), 1 deletion(-)

diff --git a/proto/sieve.example b/proto/sieve.example @@ -42,7 +42,7 @@ if header :contains "List-Id" "more.important.example.com" { # Main filter # if anyof ( - address :all :contains ["To", "Cc", "Bcc"] "me@me.com", + address :all :is ["To", "Cc", "Bcc"] "me@me.com", address :all :contains ["To", "Cc", "Bcc"] "no-spam@me.com" ) { fileinto "me-com"; diff --git a/proto/sieve/rfc3028.txt b/proto/sieve/rfc3028.txt @@ -0,0 +1,2019 @@ + + + + + + +Network Working Group T. Showalter +Request for Comments: 3028 Mirapoint, Inc. +Category: Standards Track January 2001 + + + Sieve: A Mail Filtering Language + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document describes a language for filtering e-mail messages at + 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, + and independent of access protocol, mail architecture, and operating + 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 + Internet Message Access Protocol (IMAP) servers, as it has no + variables, loops, or ability to shell out to external programs. + +Table of Contents + + 1. Introduction ........................................... 3 + 1.1. Conventions Used in This Document ..................... 4 + 1.2. Example mail messages ................................. 4 + 2. Design ................................................. 5 + 2.1. Form of the Language .................................. 5 + 2.2. Whitespace ............................................ 5 + 2.3. Comments .............................................. 6 + 2.4. Literal Data .......................................... 6 + 2.4.1. Numbers ............................................... 6 + 2.4.2. Strings ............................................... 7 + 2.4.2.1. String Lists .......................................... 7 + 2.4.2.2. Headers ............................................... 8 + 2.4.2.3. Addresses ............................................. 8 + 2.4.2.4. MIME Parts ............................................ 9 + 2.5. Tests ................................................. 9 + 2.5.1. Test Lists ............................................ 9 + + + +Showalter Standards Track [Page 1] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + 2.6. Arguments ............................................. 9 + 2.6.1. Positional Arguments .................................. 9 + 2.6.2. Tagged Arguments ...................................... 10 + 2.6.3. Optional Arguments .................................... 10 + 2.6.4. Types of Arguments .................................... 10 + 2.7. String Comparison ..................................... 11 + 2.7.1. Match Type ............................................ 11 + 2.7.2. Comparisons Across Character Sets ..................... 12 + 2.7.3. Comparators ........................................... 12 + 2.7.4. Comparisons Against Addresses ......................... 13 + 2.8. Blocks ................................................ 14 + 2.9. Commands .............................................. 14 + 2.10. Evaluation ............................................ 15 + 2.10.1. Action Interaction .................................... 15 + 2.10.2. Implicit Keep ......................................... 15 + 2.10.3. Message Uniqueness in a Mailbox ....................... 15 + 2.10.4. Limits on Numbers of Actions .......................... 16 + 2.10.5. Extensions and Optional Features ...................... 16 + 2.10.6. Errors ................................................ 17 + 2.10.7. Limits on Execution ................................... 17 + 3. Control Commands ....................................... 17 + 3.1. Control Structure If .................................. 18 + 3.2. Control Structure Require ............................. 19 + 3.3. Control Structure Stop ................................ 19 + 4. Action Commands ........................................ 19 + 4.1. Action reject ......................................... 20 + 4.2. Action fileinto ....................................... 20 + 4.3. Action redirect ....................................... 21 + 4.4. Action keep ........................................... 21 + 4.5. Action discard ........................................ 22 + 5. Test Commands .......................................... 22 + 5.1. Test address .......................................... 23 + 5.2. Test allof ............................................ 23 + 5.3. Test anyof ............................................ 24 + 5.4. Test envelope ......................................... 24 + 5.5. Test exists ........................................... 25 + 5.6. Test false ............................................ 25 + 5.7. Test header ........................................... 25 + 5.8. Test not .............................................. 26 + 5.9. Test size ............................................. 26 + 5.10. Test true ............................................. 26 + 6. Extensibility .......................................... 26 + 6.1. Capability String ..................................... 27 + 6.2. IANA Considerations ................................... 28 + 6.2.1. Template for Capability Registrations ................. 28 + 6.2.2. Initial Capability Registrations ...................... 28 + 6.3. Capability Transport .................................. 29 + 7. Transmission ........................................... 29 + + + +Showalter Standards Track [Page 2] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + 8. Parsing ................................................ 30 + 8.1. Lexical Tokens ........................................ 30 + 8.2. Grammar ............................................... 31 + 9. Extended Example ....................................... 32 + 10. Security Considerations ................................ 34 + 11. Acknowledgments ........................................ 34 + 12. Author's Address ....................................... 34 + 13. References ............................................. 34 + 14. Full Copyright Statement ............................... 36 + +1. Introduction + + This memo documents a language that can be used to create filters for + electronic mail. It is not tied to any particular operating system or + mail architecture. It requires the use of [IMAIL]-compliant + messages, but should otherwise generalize to many systems. + + 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 + make it impossible for users to do anything more complex (and + dangerous) than write simple mail filters, along with facilitating + the use of GUIs for filter creation and manipulation. The language is + not Turing-complete: it provides no way to write a loop or a function + and variables are not provided. + + Scripts written in Sieve are executed during final delivery, when the + message is moved to the user-accessible mailbox. In systems where + the MTA does final delivery, such as traditional Unix mail, it is + reasonable to sort when the MTA deposits mail into the user's + mailbox. + + There are a number of reasons to use a filtering system. Mail + traffic for most users has been increasing due to increased usage of + e-mail, the emergence of unsolicited email as a form of advertising, + and increased usage of mailing lists. + + Experience at Carnegie Mellon has shown that if a filtering system is + made available to users, many will make use of it in order to file + messages from specific users or mailing lists. However, many others + did not make use of the Andrew system's FLAMES filtering language + [FLAMES] due to difficulty in setting it up. + + Because of the expectation that users will make use of filtering if + it is offered and easy to use, this language has been made simple + enough to allow many users to make use of it, but rich enough that it + can be used productively. However, it is expected that GUI-based + editors will be the preferred way of editing filters for a large + number of users. + + + +Showalter Standards Track [Page 3] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +1.1. Conventions Used in This Document + + In the sections of this document that discuss the requirements of + various keywords and operators, the following conventions have been + adopted. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and + "MAY" in this document are to be interpreted as defined in + [KEYWORDS]. + + Each section on a command (test, action, or control structure) has a + line labeled "Syntax:". This line describes the syntax of the + command, including its name and its arguments. Required arguments + are listed inside angle brackets ("<" and ">"). Optional arguments + are listed inside square brackets ("[" and "]"). Each argument is + followed by its type, so "<key: string>" represents an argument + called "key" that is a string. Literal strings are represented with + double-quoted strings. Alternatives are separated with slashes, and + parenthesis are used for grouping, similar to [ABNF]. + + In the "Syntax" line, there are three special pieces of syntax that + are frequently repeated, MATCH-TYPE, COMPARATOR, and ADDRESS-PART. + These are discussed in sections 2.7.1, 2.7.3, and 2.7.4, + respectively. + + The formal grammar for these commands in section 10 and is the + authoritative reference on how to construct commands, but the formal + grammar does not specify the order, semantics, number or types of + arguments to commands, nor the legal command names. The intent is to + allow for extension without changing the grammar. + +1.2. Example mail messages + + The following mail messages will be used throughout this document in + examples. + + Message A + ----------------------------------------------------------- + Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST) + From: coyote@desert.example.org + To: roadrunner@acme.example.com + Subject: I have a present for you + + Look, I'm sorry about the whole anvil thing, and I really + didn't mean to try and drop it on you from the top of the + cliff. I want to try to make it up to you. I've got some + great birdseed over here at my place--top of the line + + + + +Showalter Standards Track [Page 4] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + stuff--and if you come by, I'll have it all wrapped up + for you. I'm really sorry for all the problems I've caused + for you over the years, but I know we can work this out. + -- + Wile E. Coyote "Super Genius" coyote@desert.example.org + ----------------------------------------------------------- + + Message B + ----------------------------------------------------------- + From: youcouldberich!@reply-by-postal-mail.invalid + Sender: b1ff@de.res.example.com + To: rube@landru.example.edu + Date: Mon, 31 Mar 1997 18:26:10 -0800 + Subject: $$$ YOU, TOO, CAN BE A MILLIONAIRE! $$$ + + YOU MAY HAVE ALREADY WON TEN MILLION DOLLARS, BUT I DOUBT + IT! SO JUST POST THIS TO SIX HUNDRED NEWSGROUPS! IT WILL + GUARANTEE THAT YOU GET AT LEAST FIVE RESPONSES WITH MONEY! + MONEY! MONEY! COLD HARD CASH! YOU WILL RECEIVE OVER + $20,000 IN LESS THAN TWO MONTHS! AND IT'S LEGAL!!!!!!!!! + !!!!!!!!!!!!!!!!!!111111111!!!!!!!11111111111!!1 JUST + SEND $5 IN SMALL, UNMARKED BILLS TO THE ADDRESSES BELOW! + ----------------------------------------------------------- + +2. Design + +2.1. Form of the Language + + The language consists of a set of commands. Each command consists of + a set of tokens delimited by whitespace. The command identifier is + the first token and it is followed by zero or more argument tokens. + Arguments may be literal data, tags, blocks of commands, or test + commands. + + The language is represented in UTF-8, as specified in [UTF-8]. + + Tokens in the ASCII range are considered case-insensitive. + +2.2. Whitespace + + Whitespace is used to separate tokens. Whitespace is made up of + tabs, newlines (CRLF, never just CR or LF), and the space character. + The amount of whitespace used is not significant. + + + + + + + + +Showalter Standards Track [Page 5] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +2.3. Comments + + Two types of comments are offered. Comments are semantically + equivalent to whitespace and can be used anyplace that whitespace is + (with one exception in multi-line strings, as described in the + grammar). + + Hash comments begin with a "#" character that is not contained within + a string and continue until the next CRLF. + + Example: if size :over 100K { # this is a comment + discard; + } + + Bracketed comments begin with the token "/*" and end with "*/" outside + of a string. Bracketed comments may span multiple lines. Bracketed + comments do not nest. + + Example: if size :over 100K { /* this is a comment + this is still a comment */ discard /* this is a comment + */ ; + } + +2.4. Literal Data + + Literal data means data that is not executed, merely evaluated "as + is", to be used as arguments to commands. Literal data is limited to + numbers and strings. + +2.4.1. Numbers + + Numbers are given as ordinary decimal numbers. However, those + 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 + a power of two. To be comparable with the power-of-two-based + versions of SI units that computers frequently use, K 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 + specifies tebi-, or 1,073,741,824 (2^30) times the value of the + number [BINARY-SI]. + + Implementations MUST provide 31 bits of magnitude in numbers, but MAY + provide more. + + Only positive integers are permitted by this specification. + + + + + + +Showalter Standards Track [Page 6] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +2.4.2. Strings + + Scripts involve large numbers of strings as they are used for pattern + matching, addresses, textual bodies, etc. Typically, short quoted + strings suffice for most uses, but a more convenient form is provided + for longer strings such as bodies of messages. + + A quoted string starts and ends with a single double quote (the <"> + character, ASCII 34). A backslash ("\", ASCII 92) inside of a quoted + string is followed by either another backslash or a double quote. + This two-character sequence represents a single backslash or double- + quote within the string, respectively. + + No other characters should be escaped with a single backslash. + + 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 + this case, "\a" is just "a"). + + Non-printing characters such as tabs, CR and LF, and control + characters are permitted in quoted strings. Quoted strings MAY span + multiple lines. NUL (ASCII 0) is not allowed in strings. + + For entering larger amounts of text, such as an email message, a + 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 + period, and another CRLF. In order to allow the message to 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, + 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; + that is, ".foo" is interpreted as ".foo". However, because this is + potentially ambiguous, scripts SHOULD be properly dot-stuffed so such + lines do not appear. + + Note that a hashed comment or whitespace may occur in between the + "text:" and the CRLF, but not within the string itself. Bracketed + comments are not allowed here. + +2.4.2.1. String Lists + + When matching patterns, it is frequently convenient to match against + 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 + true using any one of the strings, then the test is true. + Implementations are encouraged to use short-circuit evaluation in + these cases. + + + +Showalter Standards Track [Page 7] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + For instance, the test `header :contains ["To", "Cc"] + ["me@example.com", "me00@landru.example.edu"]' is true if either the + To header or Cc header of the input message contains either of the + e-mail addresses "me@example.com" or "me00@landru.example.edu". + + 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 + equivalent to a list with a single member. This means that the test + `exists "To"' is equivalent to the test `exists ["To"]'. + +2.4.2.2. Headers + + Headers are a subset of strings. In the Internet Message + Specification [IMAIL] [RFC1123], each header line is allowed to have + whitespace nearly anywhere in the line, including after the field + name and before the subsequent colon. Extra spaces between the + header name and the ":" in a header field are ignored. + + A header name never contains a colon. The "From" header refers to a + line beginning "From:" (or "From :", etc.). No header will match + the string "From:" due to the trailing colon. + + Folding of long header lines (as described in [IMAIL] 3.4.8) is + removed prior to interpretation of the data. The folding syntax (the + CRLF that ends a line plus any leading whitespace at the beginning of + the next line that indicates folding) are interpreted as if they were + a single space. + +2.4.2.3. Addresses + + A number of commands call for email addresses, which are also a + subset of strings. When these addresses are used in outbound + contexts, addresses must be compliant with [IMAIL], but are further + constrained. Using the symbols defined in [IMAIL], section 6.1, the + syntax of an address is: + + sieve-address = addr-spec ; simple address + / phrase "<" addr-spec ">" ; name & addr-spec + + That is, routes and group syntax are not permitted. If multiple + addresses are required, use a string list. Named groups are not used + here. + + Implementations MUST ensure that the addresses are syntactically + valid, but need not ensure that they actually identify an email + recipient. + + + + + +Showalter Standards Track [Page 8] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +2.4.2.4. MIME Parts + + In a few places, [MIME] body parts are represented as strings. These + parts include MIME headers and the body. This provides a way of + embedding typed data within a Sieve script so that, among other + things, character sets other than UTF-8 can be used for output + messages. + +2.5. Tests + + Tests are given as arguments to commands in order to control their + actions. In this document, tests are given to if/elsif/else to + 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 + + Some tests ("allof" and "anyof", which implement logical "and" and + logical "or", respectively) may require more than a single test as an + argument. The test-list syntax element provides a way of grouping + tests. + + Example: if anyof (not exists ["From", "Date"], + header :contains "from" "fool@example.edu") { + discard; + } + +2.6. Arguments + + In order to specify what to do, most commands take arguments. There + are three types of arguments: positional, tagged, and optional. + +2.6.1. Positional Arguments + + Positional arguments are given to a command which discerns their + meaning based on their order. When a command takes positional + arguments, all positional arguments must be supplied and must be in + the order prescribed. + + + + +Showalter Standards Track [Page 9] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +2.6.2. Tagged Arguments + + This document provides for tagged arguments in the style of + CommonLISP. These are also similar to flags given to commands in + most command-line systems. + + A tagged argument is an argument for a command that begins with ":" + followed by a tag naming the argument, such as ":contains". This + argument means that zero or more of the next tokens have some + particular meaning depending on the argument. These next tokens may + be numbers or strings but they are never blocks. + + Tagged arguments are similar to positional arguments, except that + instead of the meaning being derived from the command, it is derived + from the tag. + + Tagged arguments must appear before positional arguments, but they + may appear in any order with other tagged arguments. For simplicity + of the specification, this is not expressed in the syntax definitions + with commands, but they still may be reordered arbitrarily provided + they appear before positional arguments. Tagged arguments may be + mixed with optional arguments. + + To simplify this specification, tagged arguments SHOULD NOT take + tagged arguments as arguments. + +2.6.3. Optional Arguments + + Optional arguments are exactly like tagged arguments except that they + may be left out, in which case a default value is implied. Because + optional arguments tend to result in shorter scripts, they have been + used far more than tagged arguments. + + One particularly noteworthy case is the ":comparator" argument, which + allows the user to specify which [ACAP] comparator will be used to + compare two strings, since different languages may impose different + orderings on UTF-8 [UTF-8] characters. + +2.6.4. Types of Arguments + + Abstractly, arguments may be literal data, tests, or blocks of + commands. In this way, an "if" control structure is merely a command + that happens to take a test and a block as arguments and may execute + the block of code. + + However, this abstraction is ambiguous from a parsing standpoint. + The grammar in section 9.2 presents a parsable version of this: + Arguments are string-lists, numbers, and tags, which may be followed + + + +Showalter Standards Track [Page 10] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + by a test or a test-list, which may be followed by a block of + commands. No more than one test or test list, nor more than one + block of commands, may be used, and commands that end with blocks of + commands do not end with semicolons. + +2.7. String Comparison + + When matching one string against another, there are a number of ways + of performing the match operation. These are accomplished with three + types of matches: an exact match, a substring match, and a wildcard + glob-style match. These are described below. + + In order to provide for matches between character sets and case + insensitivity, Sieve borrows ACAP's comparator registry. + + However, when a string represents the name of a header, the + comparator is never user-specified. Header comparisons are always + done with the "i;ascii-casemap" operator, i.e., case-insensitive + comparisons, because this is the way things are defined in the + message specification [IMAIL]. + +2.7.1. Match Type + + There are three match types describing the matching used in this + specification: ":is", ":contains", and ":matches". Match type + arguments are supplied to those commands which allow them to specify + what kind of match is to be performed. + + These are used as tagged arguments to tests that perform string + comparison. + + The ":contains" match type describes a substring match. If the value + argument contains the key argument as a substring, the match is true. + For instance, the string "frobnitzm" contains "frob" and "nit", but + not "fbm". The null key ("") is contained in all values. + + The ":is" match type describes an absolute match; if the contents of + the first string are absolutely the same as the contents of the + second string, they match. Only the string "frobnitzm" is the string + "frobnitzm". The null key ":is" and only ":is" the null value. + + The ":matches" version specifies a wildcard match using the + characters "*" and "?". "*" matches zero or more characters, and "?" + matches a single character. "?" and "*" may be escaped as "\\?" and + "\\*" in strings to match against themselves. The first backslash + escapes the second backslash; together, they escape the "*". This is + awkward, but it is commonplace in several programming languages that + use globs and regular expressions. + + + +Showalter Standards Track [Page 11] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + In order to specify what type of match is supposed to happen, + commands that support matching take optional tagged arguments + ":matches", ":is", and ":contains". Commands default to using ":is" + matching if no match type argument is supplied. Note that these + modifiers may interact with comparators; in particular, some + comparators are not suitable for matching with ":contains" or + ":matches". It is an error to use a comparator with ":contains" or + ":matches" that is not compatible with it. + + It is an error to give more than one of these arguments to a given + command. + + For convenience, the "MATCH-TYPE" syntax element is defined here as + follows: + + Syntax: ":is" / ":contains" / ":matches" + +2.7.2. Comparisons Across Character Sets + + All Sieve scripts are represented in UTF-8, but messages may involve + a number of character sets. In order for comparisons to work across + character sets, implementations SHOULD implement the following + behavior: + + Implementations decode header charsets to UTF-8. Two strings are + considered equal if their UTF-8 representations are identical. + Implementations should decode charsets represented in the forms + specified by [MIME] for both message headers and bodies. + Implementations must be capable of decoding US-ASCII, ISO-8859-1, + the ASCII subset of ISO-8859-* character sets, and UTF-8. + + If implementations fail to support the above behavior, they MUST + conform to the following: + + No two strings can be considered equal if one contains octets + greater than 127. + +2.7.3. Comparators + + In order to allow for language-independent, case-independent matches, + the match type may be coupled with a comparator name. Comparators + are described for [ACAP]; a registry is defined for ACAP, and this + specification uses that registry. + + ACAP defines multiple comparator types. Only equality types are used + in this specification. + + + + + +Showalter Standards Track [Page 12] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + All implementations MUST support the "i;octet" comparator (simply + compares octets) and the "i;ascii-casemap" comparator (which treats + uppercase and lowercase characters in the ASCII subset of UTF-8 as + the same). If left unspecified, the default is "i;ascii-casemap". + + 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 + comparator with ":matches" or ":contains" that is not compatible with + it. + + A comparator is specified by the ":comparator" option with commands + that support matching. This option is followed by a string providing + the name of the comparator to be used. For convenience, the syntax + of a comparator is abbreviated to "COMPARATOR", and (repeated in + several tests) is as follows: + + Syntax: ":comparator" <comparator-name: string> + + So in this example, + + Example: if header :contains :comparator "i;octet" "Subject" + "MAKE MONEY FAST" { + discard; + } + + would discard any message with subjects like "You can MAKE MONEY + FAST", but not "You can Make Money Fast", since the comparator used + is case-sensitive. + + Comparators other than i;octet and i;ascii-casemap must be declared + with require, as they are extensions. If a comparator declared with + require is not known, it is an error, and execution fails. If the + comparator is not declared with require, it is also an error, even if + the comparator is supported. (See 2.10.5.) + + Both ":matches" and ":contains" match types are compatible with the + "i;octet" and "i;ascii-casemap" comparators and may be used with + them. + + It is an error to give more than one of these arguments to a given + command. + +2.7.4. Comparisons Against Addresses + + Addresses are one of the most frequent things represented as strings. + These are structured, and being able to compare against the local- + part or the domain of an address is useful, so some tests that act + + + + +Showalter Standards Track [Page 13] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + exclusively on addresses take an additional optional argument that + specifies what the test acts on. + + These optional arguments are ":localpart", ":domain", and ":all", + which act on the local-part (left-side), the domain part (right- + side), and the whole address. + + The kind of comparison done, such as whether or not the test done is + case-insensitive, is specified as a comparator argument to the test. + + If an optional address-part is omitted, the default is ":all". + + It is an error to give more than one of these arguments to a given + command. + + For convenience, the "ADDRESS-PART" syntax element is defined here as + follows: + + Syntax: ":localpart" / ":domain" / ":all" + +2.8. Blocks + + Blocks are sets of commands enclosed within curly braces. Blocks are + supplied to commands so that the commands can implement control + commands. + + A control structure is a command that happens to take a test and a + block as one of its arguments; depending on the result of the test + supplied as another argument, it runs the code in the block some + number of times. + + With the commands supplied in this memo, there are no loops. The + control structures supplied--if, elsif, and else--run a block either + once or not at all. So there are two arguments, the test and the + block. + +2.9. Commands + + Sieve scripts are sequences of commands. Commands can take any of + the tokens above as arguments, and arguments may be either tagged or + positional arguments. Not all commands take all arguments. + + There are three kinds of commands: test commands, action commands, + and control commands. + + The simplest is an action command. An action command is an + identifier followed by zero or more arguments, terminated by a + semicolon. Action commands do not take tests or blocks as arguments. + + + +Showalter Standards Track [Page 14] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + A control command is similar, but it takes a test as an argument, and + ends with a block instead of a semicolon. + + A test command is used as part of a control command. It is used to + specify whether or not the block of code given to the control command + is executed. + +2.10. Evaluation + +2.10.1. Action Interaction + + Some actions cannot be used with other actions because the result + would be absurd. These restrictions are noted throughout this memo. + + Extension actions MUST state how they interact with actions defined + in this specification. + +2.10.2. Implicit Keep + + Previous experience with filtering systems suggests that cases tend + to be missed in scripts. To prevent errors, Sieve has an "implicit + keep". + + An implicit keep is a keep action (see 4.4) performed in absence of + any action that cancels the implicit keep. + + An implicit keep is performed if a message is not written to a + mailbox, redirected to a new address, or explicitly thrown out. That + is, if a fileinto, a keep, a redirect, or a discard is performed, an + implicit keep is not. + + Some actions may be defined to not cancel the implicit keep. These + actions may not directly affect the delivery of a message, and are + used for their side effects. None of the actions specified in this + document meet that criteria, but extension actions will. + + For instance, with any of the short messages offered above, the + following script produces no actions. + + Example: if size :over 500K { discard; } + + As a result, the implicit keep is taken. + +2.10.3. Message Uniqueness in a Mailbox + + Implementations SHOULD NOT deliver a message to the same folder more + than once, even if a script explicitly asks for a message to be + written to a mailbox twice. + + + +Showalter Standards Track [Page 15] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + 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 + MUST NOT be treated as an error. + +2.10.4. Limits on Numbers of Actions + + Site policy MAY limit numbers of actions taken and MAY impose + 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 + a particular message, an error occurs. + + Implementations MUST prohibit more than one reject. + + Implementations MUST allow at least one keep or one fileinto. If + fileinto is not implemented, implementations MUST allow at least one + keep. + + Implementations SHOULD prohibit reject when used with other actions. + +2.10.5. Extensions and Optional Features + + Because of the differing capabilities of many mail systems, several + features of this specification are optional. Before any of these + extensions can be executed, they must be declared with the "require" + action. + + If an extension is not enabled with "require", implementations MUST + treat it as if they did not support it at all. + + If a script does not understand an extension declared with require, + the script must not be used at all. Implementations MUST NOT execute + scripts which require unknown capability names. + + Note: The reason for this restriction is that prior experiences with + languages such as LISP and Tcl suggest that this is a workable + way of noting that a given script uses an extension. + + Experience with PostScript suggests that mechanisms that allow + a script to work around missing extensions are not used in + practice. + + Extensions which define actions MUST state how they interact with + actions discussed in the base specification. + + + + + + + +Showalter Standards Track [Page 16] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +2.10.6. Errors + + In any programming language, there are compile-time and run-time + errors. + + Compile-time errors are ones in syntax that are detectable if a + syntax check is done. + + Run-time errors are not detectable until the script is run. This + includes transient failures like disk full conditions, but also + includes issues like invalid combinations of actions. + + When an error occurs in a Sieve script, all processing stops. + + Implementations MAY choose to do a full parse, then evaluate the + script, then do all actions. Implementations might even go so far as + to ensure that execution is atomic (either all actions are executed + or none are executed). + + Other implementations may choose to parse and run at the same time. + Such implementations are simpler, but have issues with partial + failure (some actions happen, others don't). + + Implementations might even go so far as to ensure that scripts can + never execute an invalid set of actions (e.g., reject + fileinto) + before execution, although this could involve solving the Halting + Problem. + + This specification allows any of these approaches. Solving the + Halting Problem is considered extra credit. + + When an error happens, implementations MUST notify the user that an + error occurred, which actions (if any) were taken, and do an implicit + keep. + +2.10.7. Limits on Execution + + Implementations may limit certain constructs. However, this + 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 test lists. + +3. Control Commands + + Control structures are needed to allow for multiple and conditional + actions. + + + +Showalter Standards Track [Page 17] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +3.1. Control Structure If + + There are three pieces to if: "if", "elsif", and "else". Each is + actually a separate command in terms of the grammar. However, an + elsif MUST only follow an if, and an else MUST follow only either an + if or an elsif. An error occurs if these conditions are not met. + + Syntax: if <test1: test> <block1: block> + + Syntax: elsif <test2: test> <block2: block> + + Syntax: else <block> + + The semantics are similar to those of any of the many other + programming languages these control commands appear in. When the + interpreter sees an "if", it evaluates the test associated with it. + If the test is true, it executes the block associated with it. + + If the test of the "if" is false, it evaluates the test of the first + "elsif" (if any). If the test of "elsif" is true, it runs the + elsif's block. An elsif may be followed by an elsif, in which case, + the interpreter repeats this process until it runs out of elsifs. + + When the interpreter runs out of elsifs, there may be an "else" case. + If there is, and none of the if or elsif tests were true, the + interpreter runs the else case. + + This provides a way of performing exactly one of the blocks in the + chain. + + In the following example, both Message A and B are dropped. + + Example: require "fileinto"; + if header :contains "from" "coyote" { + discard; + } elsif header :contains ["subject"] ["$$$"] { + discard; + } else { + fileinto "INBOX"; + } + + + When the script below is run over message A, it redirects the message + to acm@example.edu; message B, to postmaster@example.edu; any other + message is redirected to field@example.edu. + + + + + + +Showalter Standards Track [Page 18] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + Example: if header :contains ["From"] ["coyote"] { + redirect "acm@example.edu"; + } elsif header :contains "Subject" "$$$" { + redirect "postmaster@example.edu"; + } else { + redirect "field@example.edu"; + } + + Note that this definition prohibits the "... else if ..." sequence + used by C. This is intentional, because this construct produces a + shift-reduce conflict. + +3.2. Control Structure Require + + Syntax: require <capabilities: string-list> + + The require action notes that a script makes use of a certain + extension. Such a declaration is required to use the extension, as + discussed in section 2.10.5. Multiple capabilities can be declared + with a single require. + + The require command, if present, MUST be used before anything other + than a require can be used. An error occurs if a require appears + after a command other than require. + + Example: require ["fileinto", "reject"]; + + Example: require "fileinto"; + require "vacation"; + +3.3. Control Structure Stop + + Syntax: stop + + The "stop" action ends all processing. If no actions have been + executed, then the keep action is taken. + +4. Action Commands + + This document supplies five actions that may be taken on a message: + keep, fileinto, redirect, reject, and discard. + + Implementations MUST support the "keep", "discard", and "redirect" + actions. + + Implementations SHOULD support "reject" and "fileinto". + + + + + +Showalter Standards Track [Page 19] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + Implementations MAY limit the number of certain actions taken (see + section 2.10.4). + +4.1. Action reject + + Syntax: reject <reason: string> + + The optional "reject" action refuses delivery of a message by sending + back an [MDN] to the sender. 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> + + The "fileinto" action delivers the message into the specified folder. + Implementations SHOULD support fileinto, but in some environments + this may be impossible. + + + +Showalter Standards Track [Page 20] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + The capability string for use with the require command is "fileinto". + + In the following script, message A is filed into folder + "INBOX.harassment". + + Example: require "fileinto"; + if header :contains ["from"] "coyote" { + fileinto "INBOX.harassment"; + } + +4.3. Action redirect + + Syntax: redirect <address: string> + + The "redirect" action is used to send the message to another user at + a supplied address, as a mail forwarding feature does. The + "redirect" action makes no changes to the message body or existing + headers, but it may add new headers. The "redirect" modifies the + envelope recipient. + + The redirect command performs an MTA-style "forward"--that is, what + you get from a .forward file using sendmail under UNIX. The address + on the SMTP envelope is replaced with the one on the redirect command + and the message is sent back out. (This is not an MUA-style forward, + which creates a new message with a different sender and message ID, + wrapping the old message in a new one.) + + A simple script can be used for redirecting all mail: + + Example: redirect "bart@example.edu"; + + Implementations SHOULD take measures to implement loop control, + possibly including adding headers to the message or counting received + headers. If an implementation detects a loop, it causes an error. + +4.4. Action keep + + Syntax: keep + + The "keep" action is whatever action is taken in lieu of all other + actions, if no filtering happens at all; generally, this simply means + to file the message into the user's main mailbox. This command + 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 + needing to understand the user's setup, or the underlying mail + system. + + + + + +Showalter Standards Track [Page 21] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + For instance, in an implementation where the IMAP server is running + scripts on behalf of the user at time of delivery, a keep command is + equivalent to a fileinto "INBOX". + + Example: if size :under 1M { keep; } else { discard; } + + Note that the above script is identical to the one below. + + Example: if not size :under 1M { discard; } + +4.5. Action discard + + Syntax: discard + + Discard is used to silently throw away the message. It does so by + simply canceling the implicit keep. If discard is used with other + actions, the other actions still happen. Discard is compatible with + all other actions. (For instance fileinto+discard is equivalent to + fileinto.) + + Discard MUST be silent; that is, it MUST NOT return a non-delivery + notification of any kind ([DSN], [MDN], or otherwise). + + In the following script, any mail from "idiot@example.edu" is thrown + out. + + Example: if header :contains ["from"] ["idiot@example.edu"] { + discard; + } + + While an important part of this language, "discard" has the potential + to create serious problems for users: Students who leave themselves + logged in to an unattended machine in a public computer lab may find + their script changed to just "discard". In order to protect users in + this situation (along with similar situations), implementations MAY + keep messages destroyed by a script for an indefinite period, and MAY + disallow scripts that throw out all mail. + +5. Test Commands + + Tests are used in conditionals to decide which part(s) of the + conditional to execute. + + Implementations MUST support these tests: "address", "allof", + "anyof", "exists", "false", "header", "not", "size", and "true". + + Implementations SHOULD support the "envelope" test. + + + + +Showalter Standards Track [Page 22] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +5.1. Test address + + Syntax: address [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE] + <header-list: string-list> <key-list: string-list> + + The address test matches Internet addresses in structured headers + that contain addresses. It returns true if any header contains any + key in the specified part of the address, as modified by the + comparator and the match keyword. + + Like envelope and header, this test returns true if any combination + of the header-list and key-list arguments match. + + Internet email addresses [IMAIL] have the somewhat awkward + 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 + at-sign is case insensitive. The "address" command does not deal + with this itself, but provides the ADDRESS-PART argument for allowing + users to deal with it. + + The address primitive never acts on the phrase part of an email + address, nor on comments within that address. It also never acts on + group names, although it does act on the addresses within the group + construct. + + Implementations MUST restrict the address test to headers that + contain addresses, but MUST include at least From, To, Cc, Bcc, + Sender, Resent-From, Resent-To, and SHOULD include any other header + that utilizes an "address-list" structured header body. + + Example: if address :is :all "from" "tim@example.com" { + discard; + +5.2. Test allof + + Syntax: allof <tests: test-list> + + The allof test performs a logical AND on the tests supplied to it. + + Example: allof (false, false) => false + allof (false, true) => false + allof (true, true) => true + + The allof test takes as its argument a test-list. + + + + + + + +Showalter Standards Track [Page 23] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +5.3. Test anyof + + Syntax: anyof <tests: test-list> + + The anyof test performs a logical OR on the tests supplied to it. + + Example: anyof (false, false) => false + anyof (false, true) => true + anyof (true, true) => true + +5.4. Test envelope + + Syntax: envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] + <envelope-part: string-list> <key-list: string-list> + + The "envelope" test is true if the specified part of the SMTP (or + equivalent) envelope matches the specified key. + + If one of the envelope-part strings is (case insensitive) "from", + then matching occurs against the FROM address used in the SMTP MAIL + command. + + If one of the envelope-part strings is (case insensitive) "to", then + matching occurs against the TO address used in the SMTP RCPT command + that resulted in this message getting delivered to this user. Note + that only the most recent TO is available, and only the one relevant + to this user. + + 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 + are matched against all parts given in the envelope-part list. + + Like address and header, this test returns true if any combination of + the envelope-part and key-list arguments is true. + + All tests against envelopes MUST drop source routes. + + If the SMTP transaction involved several RCPT commands, only the data + from the RCPT command that caused delivery to this user is available + in the "to" part of the envelope. + + If a protocol other than SMTP is used for message transport, + implementations are expected to adapt this command appropriately. + + The envelope command is optional. Implementations SHOULD support it, + but the necessary information may not be available in all cases. + + + + + +Showalter Standards Track [Page 24] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + Example: require "envelope"; + if envelope :all :is "from" "tim@example.com" { + discard; + } + +5.5. Test exists + + Syntax: exists <header-names: string-list> + + The "exists" test is true if the headers listed in the header-names + argument exist within the message. All of the headers must exist or + the test is false. + + The following example throws out mail that doesn't have a From header + and a Date header. + + Example: if not exists ["From","Date"] { + discard; + } + +5.6. Test false + + Syntax: false + + The "false" test always evaluates to false. + +5.7. Test header + + Syntax: header [COMPARATOR] [MATCH-TYPE] + <header-names: string-list> <key-list: string-list> + + The "header" test evaluates to true if any header name matches any + key. The type of match is specified by the optional match argument, + which defaults to ":is" if not specified, as specified in section + 2.6. + + Like address and envelope, this test returns true if any combination + of the string-list and key-list arguments match. + + If a header listed in the header-names argument exists, it contains + the null key (""). However, if the named header is not present, it + does not contain the null key. So if a message contained the header + + X-Caffeine: C8H10N4O2 + + + + + + + +Showalter Standards Track [Page 25] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + these tests on that header evaluate as follows: + + header :is ["X-Caffeine"] [""] => false + header :contains ["X-Caffeine"] [""] => true + +5.8. Test not + + Syntax: not <test> + + The "not" test takes some other test as an argument, and yields the + opposite result. "not false" evaluates to "true" and "not true" + evaluates to "false". + +5.9. Test size + + Syntax: size <":over" / ":under"> <limit: number> + + The "size" test deals with the size of a message. It takes either a + tagged argument of ":over" or ":under", followed by a number + representing the size of the message. + + If the argument is ":over", and the size of the message is greater + than the number provided, the test is true; otherwise, it is false. + + If the argument is ":under", and the size of the message is less than + the number provided, the test is true; otherwise, it is false. + + Exactly one of ":over" or ":under" must be specified, and anything + else is an error. + + The size of a message is defined to be the number of octets from the + initial header until the last character in the message body. + + Note that for a message that is exactly 4,000 octets, the message is + neither ":over" 4000 octets or ":under" 4000 octets. + +5.10. Test true + + Syntax: true + + The "true" test always evaluates to true. + +6. Extensibility + + New control structures, actions, and tests can be added to the + language. Sites must make these features known to their users; this + document does not define a way to discover the list of extensions + supported by the server. + + + +Showalter Standards Track [Page 26] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + Any extensions to this language MUST define a capability string that + uniquely identifies that extension. 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 + advertisement mechanism aware of the details of this language, + scripts submitted can be checked against the mail server to prevent + use of an extension that the server does not support. + + Extensions MUST state how they interact with constraints defined in + section 2.10, e.g., whether they cancel the implicit keep, and which + actions they are compatible and incompatible with. + +6.1. Capability String + + Capability strings are typically short strings describing what + capabilities are supported by the server. + + Capability strings beginning with "vnd." represent vendor-defined + extensions. Such extensions are not defined by Internet standards or + RFCs, but are still registered with IANA in order to prevent + conflicts. Extensions starting with "vnd." SHOULD be followed by the + name of the vendor and product, such as "vnd.acme.rocket-sled". + + The following capability strings are defined by this document: + + envelope The string "envelope" indicates that the implementation + supports the "envelope" command. + + fileinto The string "fileinto" indicates that the implementation + 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 + implementation supports the "elbonia" comparator. + Therefore, all implementations have at least the + "comparator-i;octet" and "comparator-i;ascii-casemap" + capabilities. However, these comparators may be used + without being declared with require. + + + + + + + + + +Showalter Standards Track [Page 27] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +6.2. IANA Considerations + + In order to provide a standard set of extensions, a registry is + provided by IANA. Capability names may be registered on a first- + come, first-served basis. Extensions designed for interoperable use + SHOULD be defined as standards track or IESG approved experimental + RFCs. + +6.2.1. Template for Capability Registrations + + The following template is to be used for registering new Sieve + extensions with IANA. + + To: iana@iana.org + Subject: Registration of new Sieve extension + + Capability name: + Capability keyword: + Capability arguments: + Standards Track/IESG-approved experimental RFC number: + Person and email address to contact for further information: + +6.2.2. Initial Capability Registrations + + The following are to be added to the IANA registry for Sieve + extensions as the initial contents of the capability registry. + + Capability name: fileinto + Capability keyword: fileinto + Capability arguments: fileinto <folder: string> + Standards Track/IESG-approved experimental RFC number: + RFC 3028 (Sieve base spec) + Person and email address to contact for further information: + Tim Showalter + tjs@mirapoint.com + + Capability name: reject + Capability keyword: reject + Capability arguments: reject <reason: string> + Standards Track/IESG-approved experimental RFC number: + RFC 3028 (Sieve base spec) + Person and email address to contact for further information: + Tim Showalter + tjs@mirapoint.com + + + + + + + +Showalter Standards Track [Page 28] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + Capability name: envelope + Capability keyword: envelope + Capability arguments: + envelope [COMPARATOR] [ADDRESS-PART] [MATCH-TYPE] + <envelope-part: string-list> <key-list: string-list> + Standards Track/IESG-approved experimental RFC number: + RFC 3028 (Sieve base spec) + Person and email address to contact for further information: + Tim Showalter + tjs@mirapoint.com + + Capability name: comparator-* + Capability keyword: + comparator-* (anything starting with "comparator-") + Capability arguments: (none) + Standards Track/IESG-approved experimental RFC number: + RFC 3028, Sieve, by reference of + RFC 2244, Application Configuration Access Protocol + Person and email address to contact for further information: + Tim Showalter + tjs@mirapoint.com + +6.3. Capability Transport + + As the range of mail systems that this document is intended to apply + to is quite varied, a method of advertising which capabilities an + implementation supports is difficult due to the wide range of + possible implementations. Such a mechanism, however, should have + property that the implementation can advertise the complete set of + extensions that it supports. + +7. Transmission + + The MIME type for a Sieve script is "application/sieve". + + The registration of this type for RFC 2048 requirements is as + follows: + + Subject: Registration of MIME media type application/sieve + + MIME media type name: application + MIME subtype name: sieve + Required parameters: none + Optional parameters: none + Encoding considerations: Most sieve scripts will be textual, + written in UTF-8. When non-7bit characters are used, + quoted-printable is appropriate for transport systems + that require 7bit encoding. + + + +Showalter Standards Track [Page 29] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + Security considerations: Discussed in section 10 of RFC 3028. + Interoperability considerations: Discussed in section 2.10.5 + of RFC 3028. + Published specification: RFC 3028. + Applications which use this media type: sieve-enabled mail servers + Additional information: + Magic number(s): + File extension(s): .siv + Macintosh File Type Code(s): + Person & email address to contact for further information: + See the discussion list at ietf-mta-filters@imc.org. + Intended usage: + COMMON + Author/Change controller: + See Author information in RFC 3028. + +8. Parsing + + The Sieve grammar is separated into tokens and a separate grammar as + most programming languages are. + +8.1. Lexical Tokens + + Sieve scripts are encoded in UTF-8. The following assumes a valid + UTF-8 encoding; special characters in Sieve scripts are all ASCII. + + The following are tokens in Sieve: + + - identifiers + - tags + - numbers + - quoted strings + - multi-line strings + - other separators + + Blanks, horizontal tabs, CRLFs, and comments ("white space") are + ignored except as they separate tokens. Some white space is required + to separate otherwise adjacent tokens and in specific places in the + multi-line strings. + + The other separators are single individual characters, and are + mentioned explicitly in the grammar. + + The lexical structure of sieve is defined in the following BNF (as + described in [ABNF]): + + + + + + +Showalter Standards Track [Page 30] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + bracket-comment = "/*" *(CHAR-NOT-STAR / ("*" CHAR-NOT-SLASH)) "*/" + ;; No */ allowed inside a comment. + ;; (No * is allowed unless it is the last character, + ;; or unless it is followed by a character that isn't a + ;; slash.) + + CHAR-NOT-DOT = (%x01-09 / %x0b-0c / %x0e-2d / %x2f-ff) + ;; no dots, no CRLFs + + CHAR-NOT-CRLF = (%x01-09 / %x0b-0c / %x0e-ff) + + CHAR-NOT-SLASH = (%x00-57 / %x58-ff) + + CHAR-NOT-STAR = (%x00-51 / %x53-ff) + + comment = bracket-comment / hash-comment + + hash-comment = ( "#" *CHAR-NOT-CRLF CRLF ) + + identifier = (ALPHA / "_") *(ALPHA DIGIT "_") + + tag = ":" identifier + + number = 1*DIGIT [QUANTIFIER] + + QUANTIFIER = "K" / "M" / "G" + + quoted-string = DQUOTE *CHAR DQUOTE + ;; in general, \ CHAR inside a string maps to CHAR + ;; so \" maps to " and \\ maps to \ + ;; note that newlines and other characters are all allowed + ;; strings + + multi-line = "text:" *(SP / HTAB) (hash-comment / CRLF) + *(multi-line-literal / multi-line-dotstuff) + "." CRLF + multi-line-literal = [CHAR-NOT-DOT *CHAR-NOT-CRLF] CRLF + multi-line-dotstuff = "." 1*CHAR-NOT-CRLF CRLF + ;; A line containing only "." ends the multi-line. + ;; Remove a leading '.' if followed by another '.'. + + white-space = 1*(SP / CRLF / HTAB) / comment + +8.2. Grammar + + The following is the grammar of Sieve after it has been lexically + interpreted. No white space or comments appear below. The start + symbol is "start". + + + +Showalter Standards Track [Page 31] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + argument = string-list / number / tag + + arguments = *argument [test / test-list] + + block = "{" commands "}" + + command = identifier arguments ( ";" / block ) + + commands = *command + + start = commands + + string = quoted-string / multi-line + + string-list = "[" string *("," string) "]" / string ;; if + there is only a single string, the brackets are optional + + test = identifier arguments + + test-list = "(" test *("," test) ")" + +9. Extended Example + + The following is an extended example of a Sieve script. Note that it + does not make use of the implicit keep. + + # + # Example Sieve Filter + # Declare any optional features or extension used by the script + # + require ["fileinto", "reject"]; + + # + # 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; + } + # + + + +Showalter Standards Track [Page 32] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + # Handle messages from known mailing lists + # Move messages from IETF filter discussion list to filter folder + # + if header :is "Sender" "owner-ietf-mta-filters@imc.org" + { + fileinto "filter"; # move to "filter" folder + } + # + # Keep all messages to or from people in my company + # + elsif address :domain :is ["From", "To"] "example.com" + { + keep; # keep in "In" folder + } + + # + # Try and catch unsolicited email. If a message is not to me, + # or it contains a subject known to be spam, file it away. + # + elsif anyof (not address :all :contains + ["To", "Cc", "Bcc"] "me@example.com", + header :matches "subject" + ["*make*money*fast*", "*university*dipl*mas*"]) + { + # If message header does not contain my address, + # it's from a list. + fileinto "spam"; # move to "spam" folder + } + else + { + # Move all other (non-company) mail to "personal" + # folder. + fileinto "personal"; + } + + + + + + + + + + + + + + + + + +Showalter Standards Track [Page 33] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +10. Security Considerations + + Users must get their mail. It is imperative that whatever method + implementations use to store the user-defined filtering scripts be + secure. + + It is equally important that implementations sanity-check the user's + scripts, and not allow users to create on-demand mailbombs. For + instance, an implementation that allows a user to reject or redirect + multiple times to a single message might also allow a user to create + a mailbomb triggered by mail from a specific user. Site- or + implementation-defined limits on actions are useful for this. + + Several commands, such as "discard", "redirect", and "fileinto" allow + for actions to be taken that are potentially very dangerous. + + Implementations SHOULD take measures to prevent languages from + looping. + +11. Acknowledgments + + I am very thankful to Chris Newman for his support and his ABNF + syntax checker, to John Myers and Steve Hole for outlining the + requirements for the original drafts, to Larry Greenfield for nagging + me about the grammar and finally fixing it, to Greg Sereda for + repeatedly fixing and providing examples, to Ned Freed for fixing + everything else, to Rob Earhart for an early implementation and a + great deal of help, and to Randall Gellens for endless amounts of + proofreading. I am grateful to Carnegie Mellon University where most + of the work on this document was done. I am also indebted to all of + the readers of the ietf-mta-filters@imc.org mailing list. + +12. Author's Address + + Tim Showalter + Mirapoint, Inc. + 909 Hermosa Court + Sunnyvale, CA 94085 + + EMail: tjs@mirapoint.com + +13. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + + + + + +Showalter Standards Track [Page 34] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + + [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + [BINARY-SI] "Standard IEC 60027-2: Letter symbols to be used in + electrical technology - Part 2: Telecommunications and + electronics", January 1999. + + [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 1894, January + 1996. + + [FLAMES] Borenstein, N, and C. Thyberg, "Power, Ease of Use, and + Cooperative Work in a Practical Multimedia Message + System", Int. J. of Man-Machine Studies, April, 1991. + Reprinted in Computer-Supported Cooperative Work and + Groupware, Saul Greenberg, editor, Harcourt Brace + Jovanovich, 1991. Reprinted in Readings in Groupware and + Computer-Supported Cooperative Work, Ronald Baecker, + editor, Morgan Kaufmann, 1993. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [IMAP] Crispin, M., "Internet Message Access Protocol - version + 4rev1", RFC 2060, December 1996. + + [IMAIL] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, August 1982. + + [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [MDN] Fajman, R., "An Extensible Message Format for Message + Disposition Notifications", RFC 2298, March 1998. + + [RFC1123] Braden, R., "Requirements for Internet Hosts -- + Application and Support", STD 3, RFC 1123, November 1989. + + [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode + and ISO 10646", RFC 2044, October 1996. + + + + + + + +Showalter Standards Track [Page 35] + +RFC 3028 Sieve: A Mail Filtering Language January 2001 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Showalter Standards Track [Page 36] + diff --git a/proto/sieve/rfc3431.txt b/proto/sieve/rfc3431.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group W. Segmuller +Request for Comment: 3431 IBM T.J. Watson Research Center +Category: Standards Track December 2002 + + + Sieve Extension: Relational Tests + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document describes the RELATIONAL extension to the Sieve mail + filtering language defined in RFC 3028. This extension extends + existing conditional tests in Sieve to allow relational operators. + In addition to testing their content, it also allows for testing of + the number of entities in header and envelope fields. + +1 Introduction + + Sieve [SIEVE] is a language for filtering e-mail messages at the 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, + and independent of access protocol, mail architecture, and operating + 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 + Internet Messages Access Protocol (IMAP) servers, as it has no + variables, loops, nor the ability to shell out to external programs. + + The RELATIONAL extension provides relational operators on the + address, envelope, and header tests. This extension also provides a + way of counting the entities in a message header or address field. + + With this extension, the sieve script may now determine if a field is + greater than or less than a value instead of just equivalent. One + use is for the x-priority field: move messages with a priority + greater than 3 to the "work on later" folder. Mail could also be + sorted by the from address. Those userids that start with 'a'-'m' go + to one folder, and the rest go to another folder. + + + +Segmuller Standards Track [Page 1] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + + The sieve script can also determine the number of fields in the + header, or the number of addresses in a recipient field. For + example: are there more than 5 addresses in the to and cc fields. + +2 Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119. + + Conventions for notations are as in [SIEVE] section 1.1, including + the use of [KEYWORDS] and "Syntax:" label for the definition of + action and tagged arguments syntax, and the use of [ABNF]. + + The capability string associated with extension defined in this + document is "relational". + +3 Comparators + + This document does not define any comparators or exempt any + comparators from the require clause. Any comparator used, other than + "i;octet" and "i;ascii-casemap", MUST be declared a require clause as + defined in [SIEVE]. + + The "i;ascii-numeric" comparator, as defined in [ACAP], MUST be + supported for any implementation of this extension. The comparator + "i;ascii-numeric" MUST support at least 32 bit unsigned integers. + + Larger integers MAY be supported. Note: the "i;ascii-numeric" + comparator does not support negative numbers. + +4 Match Type + + This document defines two new match types. They are the VALUE match + type and the COUNT match type. + + The syntax is: + + MATCH-TYPE =/ COUNT / VALUE + + COUNT = ":count" relational-match + + VALUE = ":value" relational-match + + relational-match = DQUOTE ( "gt" / "ge" / "lt" + / "le" / "eq" / "ne" ) DQUOTE + + + + + +Segmuller Standards Track [Page 2] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + +4.1 Match Type Value + + The VALUE match type does a relational comparison between strings. + + The VALUE match type may be used with any comparator which returns + sort information. + + Leading and trailing white space MUST be removed from the value of + the message for the comparison. White space is defined as + + SP / HTAB / CRLF + + A value from the message is considered the left side of the relation. + A value from the test expression, the key-list for address, envelope, + and header tests, is the right side of the relation. + + If there are multiple values on either side or both sides, the test + is considered true, if any pair is true. + +4.2 Match Type Count + + The COUNT match type first determines the number of the specified + entities in the message and does a relational comparison of the + number of entities to the values specified in the test expression. + + The COUNT match type SHOULD only be used with numeric comparators. + + The Address Test counts the number of recipients in the specified + fields. Group names are ignored. + + The Envelope Test counts the number of recipients in the specified + envelope parts. The envelope "to" will always have only one entry, + which is the address of the user for whom the sieve script is + running. There is no way a sieve script can determine if the message + was actually sent to someone else using this test. The envelope + "from" will be 0 if the MAIL FROM is blank, or 1 if MAIL FROM is not + blank. + + The Header Test counts the total number of instances of the specified + fields. This does not count individual addresses in the "to", "cc", + and other recipient fields. + + In all cases, if more than one field name is specified, the counts + for all specified fields are added together to obtain the number for + comparison. Thus, specifying ["to", "cc"] in an address COUNT test, + comparing the total number of "to" and "cc" addresses; if separate + counts are desired, they must be done in two comparisons, perhaps + joined by "allof" or "anyof". + + + +Segmuller Standards Track [Page 3] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + +5 Security Considerations + + Security considerations are discussed in [SIEVE]. + + An implementation MUST ensure that the test for envelope "to" only + reflects the delivery to the current user. It MUST not be possible + for a user to determine if this message was delivered to someone else + using this test. + +6 Example + + Using the message: + + received: ... + received: ... + subject: example + to: foo@example.com.invalid, baz@example.com.invalid + cc: qux@example.com.invalid + + The test: + + address :count "ge" :comparator "i;ascii-numeric" ["to", "cc"] + ["3"] + + would be true and the test + + anyof ( address :count "ge" :comparator "i;ascii-numeric" + ["to"] ["3"], + address :count "ge" :comparator "i;ascii-numeric" + ["cc"] ["3"] ) + + would be false. + + To check the number of received fields in the header, the + following test may be used: + + header :count "ge" :comparator "i;ascii-numeric" + ["received"] ["3"] + + This would return false. But + + header :count "ge" :comparator "i;ascii-numeric" + ["received", "subject"] ["3"] + + would return true. + + + + + + +Segmuller Standards Track [Page 4] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + + The test: + + header :count "ge" :comparator "i;ascii-numeric" + ["to", "cc"] ["3"] + + will always return false on an RFC 2822 compliant message [RFC2822], + since a message can have at most one "to" field and at most one "cc" + field. This test counts the number of fields, not the number of + addresses. + +7 Extended Example + + require ["relational", "comparator-i;ascii-numeric"]; + + if header :value "lt" :comparator "i;ascii-numeric" + ["x-priority"] ["3"] + { + fileinto "Priority"; + } + + elseif address :count "gt" :comparator "i;ascii-numeric" + ["to"] ["5"] + { + # everything with more than 5 recipients in the "to" field + # is considered SPAM + fileinto "SPAM"; + } + + elseif address :value "gt" :all :comparator "i;ascii-casemap" + ["from"] ["M"] + { + fileinto "From N-Z"; + } else { + fileinto "From A-M"; + } + + if allof ( address :count "eq" :comparator "i;ascii-numeric" + ["to", "cc"] ["1"] , + address :all :comparator "i;ascii-casemap" + ["to", "cc"] ["me@foo.example.com.invalid"] + { + fileinto "Only me"; + } + + + + + + + + +Segmuller Standards Track [Page 5] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + +8 IANA Considerations + + The following template specifies the IANA registration of the Sieve + extension specified in this document: + + To: iana@iana.org + Subject: Registration of new Sieve extension + + Capability name: RELATIONAL + Capability keyword: relational + Capability arguments: N/A + Standards Track/IESG-approved experimental RFC number: this RFC + Person and email address to contact for further information: + Wolfgang Segmuller + IBM T.J. Watson Research Center + 30 Saw Mill River Rd + Hawthorne, NY 10532 + + Email: whs@watson.ibm.com + + This information should be added to the list of sieve extensions + given on http://www.iana.org/assignments/sieve-extensions. + +9 References + +9.1 Normative References + + [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", RFC + 3028, January 2001. + + [Keywords] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: + ABNF", RFC 2234, November 1997. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April + 2001. + +9.2 Non-Normative References + + [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + + + + + + + +Segmuller Standards Track [Page 6] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + +10 Author's Address + + Wolfgang Segmuller + IBM T.J. Watson Research Center + 30 Saw Mill River Rd + Hawthorne, NY 10532 + + EMail: whs@watson.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Segmuller Standards Track [Page 7] + +RFC 3431 Sieve Extension: Relational Tests December 2002 + + +11 Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Segmuller Standards Track [Page 8] + diff --git a/proto/sieve/rfc5231.txt b/proto/sieve/rfc5231.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group W. Segmuller +Request for Comments: 5231 B. Leiba +Obsoletes: 3431 IBM T.J. Watson Research Center +Category: Standards Track January 2008 + + + Sieve Email Filtering: Relational Extension + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes the RELATIONAL extension to the Sieve mail + filtering language defined in RFC 3028. This extension extends + existing conditional tests in Sieve to allow relational operators. + In addition to testing their content, it also allows for testing of + the number of entities in header and envelope fields. + + This document obsoletes RFC 3431. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 + 3. Comparators . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Match Types . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4.1. Match Type VALUE . . . . . . . . . . . . . . . . . . . . . 3 + 4.2. Match Type COUNT . . . . . . . . . . . . . . . . . . . . . 3 + 5. Interaction with Other Sieve Actions . . . . . . . . . . . . . 4 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 7. Extended Example . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Changes since RFC 3431 . . . . . . . . . . . . . . . . . . . . 6 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 + 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7 + + + + + + + + + + +Segmuller & Leiba Standards Track [Page 1] + +RFC 5231 Sieve: Relational Extension January 2008 + + +1. Introduction + + The RELATIONAL extension to the Sieve mail filtering language [Sieve] + provides relational operators on the address, envelope, and header + tests. This extension also provides a way of counting the entities + in a message header or address field. + + With this extension, the Sieve script may now determine if a field is + greater than or less than a value instead of just equivalent. One + use is for the x-priority field: move messages with a priority + greater than 3 to the "work on later" folder. Mail could also be + sorted by the from address. Those userids that start with 'a'-'m' go + to one folder, and the rest go to another folder. + + The Sieve script can also determine the number of fields in the + header, or the number of addresses in a recipient field, for example, + whether there are more than 5 addresses in the to and cc fields. + + The capability string associated with the extension defined in this + document is "relational". + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119. + + Conventions for notations are as in [Sieve] section 1.1, including + the use of [Kwds] and the use of [ABNF]. + +3. Comparators + + This document does not define any comparators or exempt any + comparators from the require clause. Any comparator used must be + treated as defined in [Sieve]. + + The "i;ascii-numeric" comparator, as defined in [RFC4790], MUST be + supported for any implementation of this extension. The comparator + "i;ascii-numeric" MUST support at least 32-bit unsigned integers. + + Larger integers MAY be supported. Note: the "i;ascii-numeric" + comparator does not support negative numbers. + + + + + + + + + +Segmuller & Leiba Standards Track [Page 2] + +RFC 5231 Sieve: Relational Extension January 2008 + + +4. Match Types + + This document defines two new match types. They are the VALUE match + type and the COUNT match type. + + The syntax is: + + MATCH-TYPE =/ COUNT / VALUE + + COUNT = ":count" relational-match + + VALUE = ":value" relational-match + + relational-match = DQUOTE + ("gt" / "ge" / "lt" / "le" / "eq" / "ne") DQUOTE + ; "gt" means "greater than", the C operator ">". + ; "ge" means "greater than or equal", the C operator ">=". + ; "lt" means "less than", the C operator "<". + ; "le" means "less than or equal", the C operator "<=". + ; "eq" means "equal to", the C operator "==". + ; "ne" means "not equal to", the C operator "!=". + +4.1. Match Type VALUE + + The VALUE match type does a relational comparison between strings. + + The VALUE match type may be used with any comparator that returns + sort information. + + A value from the message is considered the left side of the relation. + A value from the test expression, the key-list for address, envelope, + and header tests, is the right side of the relation. + + If there are multiple values on either side or both sides, the test + is considered true if any pair is true. + +4.2. Match Type COUNT + + The COUNT match type first determines the number of the specified + entities in the message and does a relational comparison of the + number of entities, as defined below, to the values specified in the + test expression. + + The COUNT match type SHOULD only be used with numeric comparators. + + The Address Test counts the number of addresses (the number of + "mailbox" elements, as defined in [RFC2822]) in the specified fields. + Group names are ignored, but the contained mailboxes are counted. + + + +Segmuller & Leiba Standards Track [Page 3] + +RFC 5231 Sieve: Relational Extension January 2008 + + + The Envelope Test counts the number of addresses in the specified + envelope parts. The envelope "to" will always have only one entry, + which is the address of the user for whom the Sieve script is + running. Using this test, there is no way a Sieve script can + determine if the message was actually sent to someone else. The + envelope "from" will be 0 if the MAIL FROM is empty, or 1 if MAIL + FROM is not empty. + + The Header Test counts the total number of instances of the specified + fields. This does not count individual addresses in the "to", "cc", + and other recipient fields. + + In all cases, if more than one field name is specified, the counts + for all specified fields are added together to obtain the number for + comparison. Thus, specifying ["to", "cc"] in an address COUNT test + compares the total number of "to" and "cc" addresses; if separate + counts are desired, they must be done in two comparisons, perhaps + joined by "allof" or "anyof". + +5. Interaction with Other Sieve Actions + + This specification adds two match types. The VALUE match type only + works with comparators that return sort information. The COUNT match + type only makes sense with numeric comparators. + + There is no interaction with any other Sieve operations, nor with any + known extensions. In particular, this specification has no effect on + implicit KEEP, nor on any explicit message actions. + +6. Example + + Using the message: + + received: ... + received: ... + subject: example + to: foo@example.com, baz@example.com + cc: qux@example.com + + The test: + + address :count "ge" :comparator "i;ascii-numeric" + ["to", "cc"] ["3"] + + would evaluate to true, and the test + + + + + + +Segmuller & Leiba Standards Track [Page 4] + +RFC 5231 Sieve: Relational Extension January 2008 + + + anyof ( address :count "ge" :comparator "i;ascii-numeric" + ["to"] ["3"], + address :count "ge" :comparator "i;ascii-numeric" + ["cc"] ["3"] ) + + would evaluate to false. + + To check the number of received fields in the header, the following + test may be used: + + header :count "ge" :comparator "i;ascii-numeric" + ["received"] ["3"] + + This would evaluate to false. But + + header :count "ge" :comparator "i;ascii-numeric" + ["received", "subject"] ["3"] + + would evaluate to true. + + The test: + + header :count "ge" :comparator "i;ascii-numeric" + ["to", "cc"] ["3"] + + will always evaluate to false on an RFC 2822 compliant message + [RFC2822], since a message can have at most one "to" field and at + most one "cc" field. This test counts the number of fields, not the + number of addresses. + + + + + + + + + + + + + + + + + + + + + + +Segmuller & Leiba Standards Track [Page 5] + +RFC 5231 Sieve: Relational Extension January 2008 + + +7. Extended Example + + require ["relational", "comparator-i;ascii-numeric", "fileinto"]; + + if header :value "lt" :comparator "i;ascii-numeric" + ["x-priority"] ["3"] + { + fileinto "Priority"; + } + + elsif address :count "gt" :comparator "i;ascii-numeric" + ["to"] ["5"] + { + # everything with more than 5 recipients in the "to" field + # is considered SPAM + fileinto "SPAM"; + } + + elsif address :value "gt" :all :comparator "i;ascii-casemap" + ["from"] ["M"] + { + fileinto "From N-Z"; + } else { + fileinto "From A-M"; + } + + if allof ( address :count "eq" :comparator "i;ascii-numeric" + ["to", "cc"] ["1"] , + address :all :comparator "i;ascii-casemap" + ["to", "cc"] ["me@foo.example.com"] ) + { + fileinto "Only me"; + } + +8. Changes since RFC 3431 + + Apart from several minor editorial/wording changes, the following + list describes the notable changes to this specification since RFC + 3431. + + o Updated references, including changing the comparator reference + from the Application Configuration Access Protocol (ACAP) to the + "Internet Application Protocol Collation Registry" document + [RFC4790]. + + o Updated and corrected the examples. + + + + + +Segmuller & Leiba Standards Track [Page 6] + +RFC 5231 Sieve: Relational Extension January 2008 + + + o Added definition comments to ABNF for "gt", "lt", etc. + + o Clarified what RFC 2822 elements are counted in the COUNT test. + + o Removed the requirement to strip white space from header fields + before comparing; a more general version of this requirement has + been added to the Sieve base spec. + +9. IANA Considerations + + The following template specifies the IANA registration of the + relational Sieve extension specified in this document: + + To: iana@iana.org + Subject: Registration of new Sieve extension + + Capability name: relational + Description: Extends existing conditional tests in Sieve language + to allow relational operators + RFC number: RFC 5231 + Contact address: The Sieve discussion list <ietf-mta-filters@imc.org> + +10. Security Considerations + + An implementation MUST ensure that the test for envelope "to" only + reflects the delivery to the current user. Using this test, it MUST + not be possible for a user to determine if this message was delivered + to someone else. + + Additional security considerations are discussed in [Sieve]. + +11. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [Kwds] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet + Application Protocol Collation Registry", RFC 4790, + March 2007. + + [Sieve] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email + Filtering Language", RFC 5228, January 2008. + + + +Segmuller & Leiba Standards Track [Page 7] + +RFC 5231 Sieve: Relational Extension January 2008 + + +Authors' Addresses + + Wolfgang Segmuller + IBM T.J. Watson Research Center + 19 Skyline Drive + Hawthorne, NY 10532 + US + + Phone: +1 914 784 7408 + EMail: werewolf@us.ibm.com + + + Barry Leiba + IBM T.J. Watson Research Center + 19 Skyline Drive + Hawthorne, NY 10532 + US + + Phone: +1 914 784 7941 + EMail: leiba@watson.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Segmuller & Leiba Standards Track [Page 8] + +RFC 5231 Sieve: Relational Extension January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Segmuller & Leiba Standards Track [Page 9] + diff --git a/proto/sieve/rfc5260.txt b/proto/sieve/rfc5260.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 5260 Sun Microsystems +Category: Standards Track July 2008 + + + Sieve Email Filtering: Date and Index Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes the "date" and "index" extensions to the + Sieve email filtering language. The "date" extension gives Sieve the + ability to test date and time values in various ways. The "index" + extension provides a means to limit header and address tests to + specific instances of header fields when header fields are repeated. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 + 3. Capability Identifiers . . . . . . . . . . . . . . . . . . . . 3 + 4. Date Test . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 4.1. Zone and Originalzone Arguments . . . . . . . . . . . . . 4 + 4.2. Date-part Argument . . . . . . . . . . . . . . . . . . . . 4 + 4.3. Comparator Interactions with Date-part Arguments . . . . . 5 + 4.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Currentdate Test . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Index Extension . . . . . . . . . . . . . . . . . . . . . . . 7 + 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. Julian Date Conversions . . . . . . . . . . . . . . . 11 + Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 12 + + + + + + + +Freed Standards Track [Page 1] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + +1. Introduction + + Sieve [RFC5228] is a language for filtering email messages at or + around the 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, and independent of access protocol, mail + architecture, and operating 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 Internet Message Access Protocol + [RFC3501] servers, as it does not have user-controlled loops or the + ability to run external programs. + + The "date" extension provides a new date test to extract and match + date/time information from structured header fields. The date test + is similar in concept to the address test specified in [RFC5228], + which performs similar operations on addresses in header fields. + + The "date" extension also provides a currentdate test that operates + on the date and time when the Sieve script is executed. + + Some header fields containing date/time information, e.g., Received:, + naturally occur more than once in a single header. In such cases it + is useful to be able to restrict the date test to some subset of the + fields that are present. For example, it may be useful to apply a + date test to the last (earliest) Received: field. Additionally, it + may also be useful to apply similar restrictions to either the header + or address tests specified in [RFC5228]. + + For this reason, this specification also defines an "index" + extension. This extension adds two additional tagged arguments + :index and :last to the header, address, and date tests. If present, + these arguments specify which occurrence of the named header field is + to be tested. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + The terms used to describe the various components of the Sieve + language are taken from Section 1.1 of [RFC5228]. Section 2 of the + same document describes basic Sieve language syntax and semantics. + The date-time syntactic element defined using ABNF notation [RFC5234] + in [RFC3339] is also used here. + + + + + + +Freed Standards Track [Page 2] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + +3. Capability Identifiers + + The capability strings associated with the two extensions defined in + this document are "date" and "index". + +4. Date Test + + Usage: date [<":zone" <time-zone: string>> / ":originalzone"] + [COMPARATOR] [MATCH-TYPE] <header-name: string> + <date-part: string> <key-list: string-list> + + The date test matches date/time information derived from headers + containing [RFC2822] date-time values. The date/time information is + extracted from the header, shifted to the specified time zone, and + the value of the given date-part is determined. The test returns + true if the resulting string matches any of the strings specified in + the key-list, as controlled by the comparator and match keywords. + The date test returns false unconditionally if the specified header + field does not exist, the field exists but does not contain a + syntactically valid date-time specification, the date-time isn't + valid according to the rules of the calendar system (e.g., January + 32nd, February 29 in a non-leap year), or the resulting string fails + to match any key-list value. + + The type of match defaults to ":is" and the default comparator is + "i;ascii-casemap". + + Unlike the header and address tests, the date test can only be + applied to a single header field at a time. If multiple header + fields with the same name are present, only the first field that is + found is used. (Note, however, that this behavior can be modified + with the "index" extension defined below.) These restrictions + simplify the test and keep the meaning clear. + + The "relational" extension [RFC5231] adds a match type called + ":count". The count of a date test is 1 if the specified field + exists and contains a valid date; 0, otherwise. + + Implementations MUST support extraction of RFC 2822 date-time + information that either makes up the entire header field (e.g., as it + does in a standard Date: header field) or appears at the end of a + header field following a semicolon (e.g., as it does in a standard + Received: header field). Implementations MAY support extraction of + date and time information in RFC2822 or other formats that appears in + other positions in header field content. In the case of a field + containing more than one date or time value, the last one that + appears SHOULD be used. + + + + +Freed Standards Track [Page 3] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + +4.1. Zone and Originalzone Arguments + + The :originalzone argument specifies that the time zone offset + originally in the extracted date-time value should be retained. The + :zone argument specifies a specific time zone offset that the date- + time value is to be shifted to prior to testing. It is an error to + specify both :zone and :originalzone. + + The value of time-zone MUST be an offset relative to UTC with the + following syntax: + + time-zone = ( "+" / "-" ) 4DIGIT + + The "+" or "-" indicates whether the time-of-day is ahead of (i.e., + east of) or behind (i.e., west of) UTC. The first two digits + indicate the number of hours difference from Universal Time, and the + last two digits indicate the number of minutes difference from + Universal Time. Note that this agrees with the RFC 2822 format for + time zone offsets, not the ISO 8601 format. + + If both the :zone and :originalzone arguments are omitted, the local + time zone MUST be used. + +4.2. Date-part Argument + + The date-part argument specifies a particular part of the resulting + date/time value to match against the key-list. Possible case- + insensitive values are: + + "year" => the year, "0000" .. "9999". + "month" => the month, "01" .. "12". + "day" => the day, "01" .. "31". + "date" => the date in "yyyy-mm-dd" format. + "julian" => the Modified Julian Day, that is, the date + expressed as an integer number of days since + 00:00 UTC on November 17, 1858 (using the Gregorian + calendar). This corresponds to the regular + Julian Day minus 2400000.5. Sample routines to + convert to and from modified Julian dates are + given in Appendix A. + "hour" => the hour, "00" .. "23". + "minute" => the minute, "00" .. "59". + "second" => the second, "00" .. "60". + "time" => the time in "hh:mm:ss" format. + "iso8601" => the date and time in restricted ISO 8601 format. + "std11" => the date and time in a format appropriate + for use in a Date: header field [RFC2822]. + + + + +Freed Standards Track [Page 4] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + + "zone" => the time zone in use. If the user specified a + time zone with ":zone", "zone" will + contain that value. If :originalzone is specified + this value will be the original zone specified + in the date-time value. If neither argument is + specified the value will be the server's default + time zone in offset format "+hhmm" or "-hhmm". An + offset of 0 (Zulu) always has a positive sign. + "weekday" => the day of the week expressed as an integer between + "0" and "6". "0" is Sunday, "1" is Monday, etc. + + The restricted ISO 8601 format is specified by the date-time ABNF + production given in [RFC3339], Section 5.6, with the added + restrictions that the letters "T" and "Z" MUST be in upper case, and + a time zone offset of zero MUST be represented by "Z" and not + "+00:00". + +4.3. Comparator Interactions with Date-part Arguments + + Not all comparators are suitable with all date-part arguments. In + general, the date-parts can be compared and tested for equality with + either "i;ascii-casemap" (the default) or "i;octet", but there are + two exceptions: + + julian This is an integer, and may or may not have leading zeros. + As such, "i;ascii-numeric" is almost certainly the best + comparator to use with it. + + std11 This is provided as a means to obtain date/time values in a + format appropriate for inclusion in email header fields. The + wide range of possible syntaxes for a std11 date/time -- + which implementations of this extension are free to use when + composing a std11 string -- makes this format a poor choice + for comparisons. Nevertheless, if a comparison must be + performed, this is case-insensitive, and therefore "i;ascii- + casemap" needs to be used. + + "year", "month", "day", "hour", "minute", "second" and "weekday" all + use fixed-width string representations of integers, and can therefore + be compared with "i;octet", "i;ascii-casemap", and "i;ascii-numeric" + with equivalent results. + + "date" and "time" also use fixed-width string representations of + integers, and can therefore be compared with "i;octet" and "i;ascii- + casemap"; however, "i;ascii-numeric" can't be used with it, as + "i;ascii-numeric" doesn't allow for non-digit characters. + + + + + +Freed Standards Track [Page 5] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + +4.4. Examples + + The Date: field can be checked to test when the sender claims to have + created the message and act accordingly: + + require ["date", "relational", "fileinto"]; + if allof(header :is "from" "boss@example.com", + date :value "ge" :originalzone "date" "hour" "09", + date :value "lt" :originalzone "date" "hour" "17") + { fileinto "urgent"; } + + Testing the initial Received: field can provide an indication of when + a message was actually received by the local system: + + require ["date", "relational", "fileinto"]; + if anyof(date :is "received" "weekday" "0", + date :is "received" "weekday" "6") + { fileinto "weekend"; } + +5. Currentdate Test + + Usage: currentdate [":zone" <time-zone: string>] + [COMPARATOR] [MATCH-TYPE] + <date-part: string> + <key-list: string-list> + + The currentdate test is similar to the date test, except that it + operates on the current date/time rather than a value extracted from + the message header. In particular, the ":zone" and date-part + arguments are the same as those in the date test. + + All currentdate tests in a single Sieve script MUST refer to the same + point in time during execution of the script. + + The :count value of a currentdate test is always 1. + +5.1. Examples + + The simplest use of currentdate is to have an action that only + operates at certain times. For example, a user might want to have + messages redirected to their pager after business hours and on + weekends: + + + + + + + + + +Freed Standards Track [Page 6] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + + require ["date", "relational"]; + if anyof(currentdate :is "weekday" "0", + currentdate :is "weekday" "6", + currentdate :value "lt" "hour" "09", + currentdate :value "ge" "hour" "17") + { redirect "pager@example.com"; } + + Currentdate can be used to set up vacation [RFC5230] responses in + advance and to stop response generation automatically: + + require ["date", "relational", "vacation"]; + if allof(currentdate :value "ge" "date" "2007-06-30", + currentdate :value "le" "date" "2007-07-07") + { vacation :days 7 "I'm away during the first week in July."; } + + Currentdate may also be used in conjunction with the variables + extension to pass time-dependent arguments to other tests and + actions. The following Sieve places messages in a folder named + according to the current month and year: + + require ["date", "variables", "fileinto"]; + if currentdate :matches "month" "*" { set "month" "${1}"; } + if currentdate :matches "year" "*" { set "year" "${1}"; } + fileinto "${month}-${year}"; + + Finally, currentdate can be used in conjunction with the editheader + extension to insert a header-field containing date/time information: + + require ["variables", "date", "editheader"]; + if currentdate :matches "std11" "*" + {addheader "Processing-date" "${0}";} + +6. Index Extension + + The "index" extension, if specified, adds optional :index and :last + arguments to the header, address, and date tests as follows: + + Syntax: date [":index" <fieldno: number> [":last"]] + [<":zone" <time-zone: string>> / ":originalzone"] + [COMPARATOR] [MATCH-TYPE] <header-name: string> + <date-part: string> <key-list: string-list> + + + Syntax: header [":index" <fieldno: number> [":last"]] + [COMPARATOR] [MATCH-TYPE] + <header-names: string-list> <key-list: string-list> + + + + + +Freed Standards Track [Page 7] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + + Syntax: address [":index" <fieldno: number> [":last"]] + [ADDRESS-PART] [COMPARATOR] [MATCH-TYPE] + <header-list: string-list> <key-list: string-list> + + If :index <fieldno> is specified, the attempts to match a value are + limited to the header field fieldno (beginning at 1, the first named + header field). If :last is also specified, the count is backwards; 1 + denotes the last named header field, 2 the second to last, and so on. + Specifying :last without :index is an error. + + :index only counts separate header fields, not multiple occurrences + within a single field. In particular, :index cannot be used to test + a specific address in an address list contained within a single + header field. + + Both header and address allow the specification of more than one + header field name. If more than one header field name is specified, + all the named header fields are counted in the order specified by the + header-list. + +6.1. Example + + Mail delivery may involve multiple hops, resulting in the Received: + field containing information about when a message first entered the + local administrative domain being the second or subsequent field in + the message. As long as the field offset is consistent, it can be + tested: + + # Implement the Internet-Draft cutoff date check assuming the + # second Received: field specifies when the message first + # entered the local email infrastructure. + require ["date", "relational", "index"]; + if date :value "gt" :index 2 :zone "-0500" "received" + "iso8601" "2007-02-26T09:00:00-05:00", + { redirect "aftercutoff@example.org"; } + +7. Security Considerations + + The facilities defined here, like the facilities in the base Sieve + specification, operate on message header information that can easily + be forged. Note, however, that some fields are inherently more + reliable than others. For example, the Date: field is typically + inserted by the message sender and can be altered at any point. By + contrast, the uppermost Received: field is typically inserted by the + local mail system and is therefore difficult for the sender or an + intermediary to falsify. + + + + + +Freed Standards Track [Page 8] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + + Use of the currentdate test makes script behavior inherently less + predictable and harder to analyze. This may have consequences for + systems that use script analysis to try and spot problematic scripts. + + All of the security considerations given in the base Sieve + specification also apply to these extensions. + +8. IANA Considerations + + The following templates specify the IANA registrations of the two + Sieve extensions specified in this document: + + To: iana@iana.org + Subject: Registration of new Sieve extensions + + Capability name: date + Description: The "date" extension gives Sieve the ability + to test date and time values. + RFC number: RFC 5260 + Contact address: Sieve discussion list <ietf-mta-filters@imc.org> + + Capability name: index + Description: The "index" extension provides a means to + limit header and address tests to specific + instances when more than one field of a + given type is present. + RFC number: RFC 5260 + Contact address: Sieve discussion list <ietf-mta-filters@imc.org> + +9. References + +9.1. Normative References + + [CALGO199] Tantzen, R., "Algorithm 199: Conversions Between Calendar + Date and Julian Day Number", Collected Algorithms from + CACM 199. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the + Internet: Timestamps", RFC 3339, July 2002. + + [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering + Language", RFC 5228, January 2008. + + + +Freed Standards Track [Page 9] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + + [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: + Relational Extension", RFC 5231, January 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + +9.2. Informative References + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: + Vacation Extension", RFC 5230, January 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed Standards Track [Page 10] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + +Appendix A. Julian Date Conversions + + The following C routines show how to translate day/month/year + information to and from modified Julian dates. These routines are + straightforward translations of the Algol routines specified in CACM + Algorithm 199 [CALGO199]. + + Given the day, month, and year, jday returns the modified Julian + date. + + int jday(int year, int month, int day) + { + int j, c, ya; + + if (month > 2) + month -= 3; + else + { + month += 9; + year--; + } + c = year / 100; + ya = year - c * 100; + return (c * 146097 / 4 + ya * 1461 / 4 + (month * 153 + 2) / 5 + + day + 1721119); + } + + + + + + + + + + + + + + + + + + + + + + + + + +Freed Standards Track [Page 11] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + + Given j, the modified Julian date, jdate returns the day, month, and + year. + + void jdate(int j, int *year, int *month, int *day) + { + int y, m, d; + + j -= 1721119; + y = (j * 4 - 1) / 146097; + j = j * 4 - y * 146097 - 1; + d = j / 4; + j = (d * 4 + 3) / 1461; + d = d * 4 - j * 1461 + 3; + d = (d + 4) / 4; + m = (d * 5 - 3) / 153; + d = d * 5 - m * 153 - 3; + *day = (d + 5) / 5; + *year = y * 100 + j; + if (m < 10) + *month = m + 3; + else + { + *month = m - 9; + *year += 1; + } + } + +Appendix B. Acknowledgements + + Dave Cridland contributed the text describing the proper comparators + to use with different date-parts. Cyrus Daboo, Frank Ellerman, + Alexey Melnikov, Chris Newman, Dilyan Palauzov, and Aaron Stone + provided helpful suggestions and corrections. + +Author's Address + + Ned Freed + Sun Microsystems + 800 Royal Oaks + Monrovia, CA 91016-6347 + USA + + Phone: +1 909 457 4293 + EMail: ned.freed@mrochek.com + + + + + + + +Freed Standards Track [Page 12] + +RFC 5260 Sieve Date and Index Extensions July 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Freed Standards Track [Page 13] + diff --git a/proto/sieve/rfc5437.txt b/proto/sieve/rfc5437.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group P. Saint-Andre +Request for Comments: 5437 Cisco +Category: Standards Track A. Melnikov + Isode Limited + January 2009 + + + Sieve Notification Mechanism: + Extensible Messaging and Presence Protocol (XMPP) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + This document describes a profile of the Sieve extension for + notifications, to allow notifications to be sent over the Extensible + Messaging and Presence Protocol (XMPP), also known as Jabber. + + + + + + + + + + + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 1] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Overview ...................................................3 + 1.2. Terminology ................................................3 + 2. Definition ......................................................3 + 2.1. Notify Parameter "method" ..................................3 + 2.2. Test notify_method_capability ..............................3 + 2.3. Notify Tag ":from" .........................................4 + 2.4. Notify Tag ":importance" ...................................4 + 2.5. Notify Tag ":message" ......................................4 + 2.6. Notify Tag ":options" ......................................4 + 2.7. XMPP Syntax ................................................4 + 3. Examples ........................................................6 + 3.1. Basic Action ...............................................6 + 3.2. Action with "body" .........................................7 + 3.3. Action with "body", ":importance", ":message", and + "subject" ..................................................7 + 3.4. Action with ":from", ":message", ":importance", + "body", and "subject" ......................................8 + 4. Requirements Conformance ........................................9 + 5. Internationalization Considerations ............................10 + 6. Security Considerations ........................................11 + 7. IANA Considerations ............................................12 + 8. References .....................................................12 + 8.1. Normative References ......................................12 + 8.2. Informative References ....................................13 + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 2] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +1. Introduction + +1.1. Overview + + The [NOTIFY] extension to the [SIEVE] mail filtering language is a + framework for providing notifications by employing URIs to specify + the notification mechanism. This document defines how xmpp URIs (see + [XMPP-URI]) are used to generate notifications via the Extensible + Messaging and Presence Protocol [XMPP], which is widely implemented + in Jabber instant messaging technologies. + +1.2. Terminology + + This document inherits terminology from [NOTIFY], [SIEVE], and + [XMPP]. In particular, the terms "parameter" and "tag" are used as + described in [NOTIFY] to refer to aspects of Sieve scripts, and the + term "key" is used as described in [XMPP-URI] to refer to aspects of + an XMPP URI. + + The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", + "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT + RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be + interpreted as described in [TERMS]. + +2. Definition + +2.1. Notify Parameter "method" + + The "method" parameter MUST be a URI that conforms to the xmpp URI + scheme (as specified in [XMPP-URI]) and that identifies an XMPP + account associated with the email inbox. The URI MAY include the + resource identifier of an XMPP address and/or the query component + portion of an XMPP URI, but SHOULD NOT include an authority component + or fragment identifier component. The processing application MUST + extract an XMPP address from the URI in accordance with the + processing rules specified in [XMPP-URI]. The resulting XMPP address + MUST be encapsulated in XMPP syntax as the value of the XMPP 'to' + attribute. + +2.2. Test notify_method_capability + + In response to a notify_method_capability test for the "online" + notification-capability, an implementation SHOULD return a value of + "yes" if it has knowledge of an active presence session (see + [XMPP-IM]) for the specified XMPP notification-uri; otherwise, it + SHOULD return a value of "maybe" (since typical XMPP systems may not + allow a Sieve engine to gain knowledge about the presence of XMPP + entities). + + + +Saint-Andre & Melnikov Standards Track [Page 3] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +2.3. Notify Tag ":from" + + If included, the ":from" tag MUST be an electronic address that + conforms to the "Mailbox" rule defined in [RFC5321]. The value of + the ":from" tag MAY be included in the human-readable XML character + data of the XMPP notification; alternatively or in addition, it MAY + be transformed into formal XMPP syntax, in which case it MUST be + encapsulated as the value of an XMPP SHIM (Stanza Headers and + Internet Metadata) [SHIM] header named "Resent-From". + +2.4. Notify Tag ":importance" + + The ":importance" tag has no special meaning for this notification + mechanism, and this specification puts no restriction on its use. + The value of the ":importance" tag MAY be transformed into XMPP + syntax (in addition to or instead of including appropriate text in + the XML character data of the XMPP <body/> element); if so, it SHOULD + be encapsulated as the value of an XMPP SHIM (Stanza Headers and + Internet Metadata) [SHIM] header named "Urgency", where the XML + character of that header is "high" if the value of the ":importance" + tag is "1", "medium" if the value of the ":importance" tag is "2", + and "low" if the value of the ":importance" tag is "3". + +2.5. Notify Tag ":message" + + If the ":message" tag is included, that string MUST be transformed + into the XML character data of an XMPP <body/> element (where the + string is generated according to the guidelines specified in Section + 3.6 of [NOTIFY]). + +2.6. Notify Tag ":options" + + The ":options" tag has no special meaning for this notification + mechanism. Any handling of this tag is the responsibility of an + implementation. + +2.7. XMPP Syntax + + The xmpp mechanism results in the sending of an XMPP message to + notify a recipient about an email message. The general XMPP syntax + is as follows: + + o The notification MUST be an XMPP <message/> stanza. + + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 4] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + + o The value of the XMPP 'from' attribute SHOULD be the XMPP address + of the notification service associated with the Sieve engine or + the XMPP address of the entity to be notified. The value of the + XMPP 'from' attribute MUST NOT be generated from the Sieve ":from" + tag. + + o The value of the XMPP 'to' attribute MUST be the XMPP address + specified in the XMPP URI contained in the "method" notify + parameter. + + o The value of the XMPP 'type' attribute MUST be 'headline' or + 'normal'. + + o The XMPP <message/> stanza MUST include a <body/> child element. + If the ":message" tag is included in the Sieve script, that string + MUST be used as the XML character data of the <body/> element. If + not and if the XMPP URI contained in the "method" notify parameter + specified a "body" key in the query component, that value SHOULD + be used. Otherwise, the XML character data SHOULD be some + configurable text indicating that the message is a Sieve + notification. + + o The XMPP <message/> stanza MAY include a <subject/> child element. + If the XMPP URI contained in the "method" notify parameter + specified a "subject" key in the query component, that value + SHOULD be used as the XML character data of the <subject/> + element. Otherwise, the XML character data SHOULD be some + configurable text indicating that the message is a Sieve + notification. + + o The XMPP <message/> stanza SHOULD include a URI, for the recipient + to use as a hint in locating the message, encapsulated as the XML + character data of a <url/> child element of an <x/> element + qualified by the 'jabber:x:oob' namespace, as specified in [OOB]. + If included, the URI SHOULD be an Internet Message Access Protocol + [IMAP] URL that specifies the location of the message, as defined + in [IMAP-URL], but MAY be another URI type that can specify or + hint at the location of an email message, such as a URI for an + HTTP resource [HTTP] or a Post Office Protocol Version 3 (POP3) + mailbox [POP-URL] at which the message can be accessed. It is not + expected that an XMPP user agent shall directly handle such a URI, + but instead that it shall invoke an appropriate helper application + to handle the URI. + + o The XMPP <message/> stanza MAY include an XMPP SHIM (Stanza + Headers and Internet Metadata) [SHIM] header named "Resent-From". + If the Sieve script included a ":from" tag, the "Resent-From" + + + + +Saint-Andre & Melnikov Standards Track [Page 5] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + + value MUST be the value of the ":from" tag; otherwise, the + "Resent-From" value SHOULD be the envelope recipient address of + the original email message that triggered the notification. + +3. Examples + + In the following examples, the sender of the email has an address of + <mailto:juliet@example.org>, the entity to be notified has an email + address of <mailto:romeo@example.com> and an XMPP address of + romeo@im.example.com (resulting in an XMPP URI of + <xmpp:romeo@im.example.com>), and the notification service associated + with the Sieve engine has an XMPP address of notify.example.com. + + Note: In the following examples, line breaks are included in XMPP + URIs solely for the purpose of readability. + +3.1. Basic Action + + The following is a basic Sieve notify action with only a method. The + XML character data of the XMPP <body/> and <subject/> elements are + therefore generated by the Sieve engine based on configuration. In + addition, the Sieve engine includes a URI pointing to the message. + + Basic action (Sieve syntax) + + notify "xmpp:romeo@im.example.com" + + The resulting XMPP <message/> stanza might be as follows: + + Basic action (XMPP syntax) + + <message from='notify.example.com' + to='romeo@im.example.com' + type='headline' + xml:lang='en'> + <subject>SIEVE</subject> + <body>&lt;juliet@example.com&gt; You got mail.</body> + <x xmlns='jabber:x:oob'> + <url> + imap://romeo@example.com/INBOX;UIDVALIDITY=385759043/;UID=18 + </url> + </x> + </message> + + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 6] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +3.2. Action with "body" + + The following action contains a "body" key in the query component of + the XMPP URI but no ":message" tag in the Sieve script. As a result, + the XML character data of the XMPP <body/> element in the XMPP + notification is taken from the XMPP URI. In addition, the Sieve + engine includes a URI pointing to the message. + + Action with "body" (Sieve syntax) + + notify "xmpp:romeo@im.example.com?message + ;body=Wherefore%20art%20thou%3F" + + The resulting XMPP <message/> stanza might be as follows. + + Action with "body" (XMPP syntax) + + <message from='notify.example.com' + to='romeo@im.example.com' + type='headline' + xml:lang='en'> + <subject>SIEVE</subject> + <body>Wherefore art thou?</body> + <x xmlns='jabber:x:oob'> + <url> + imap://romeo@example.com/INBOX;UIDVALIDITY=385759044/;UID=19 + </url> + </x> + </message> + +3.3. Action with "body", ":importance", ":message", and "subject" + + The following action specifies an ":importance" tag and a ":message" + tag in the Sieve script, as well as a "body" key and a "subject" key + in the query component of the XMPP URI. As a result, the ":message" + tag from the Sieve script overrides the "body" key from the XMPP URI + when generating the XML character data of the XMPP <body/> element. + In addition, the Sieve engine includes a URI pointing to the message. + + Action with "body", ":importance", ":message", and "subject" (Sieve + syntax) + + notify :importance "1" + :message "Contact Juliet immediately!" + "xmpp:romeo@im.example.com?message + ;body=You%27re%20in%20trouble + ;subject=ALERT%21" + + + + +Saint-Andre & Melnikov Standards Track [Page 7] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + + The resulting XMPP <message/> stanza might be as follows. + + Action with "body", ":importance", ":message", and "subject" (XMPP + syntax) + + <message from='notify.example.com' + to='romeo@im.example.com' + type='headline' + xml:lang='en'> + <subject>ALERT!</subject> + <body>Contact Juliet immediately!</body> + <headers xmlns='http://jabber.org/protocol/shim'> + <header name='Urgency'>high</header> + </headers> + <x xmlns='jabber:x:oob'> + <url> + imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=20 + </url> + </x> + </message> + +3.4. Action with ":from", ":message", ":importance", "body", and + "subject" + + The following action specifies a ":from" tag, an ":importance" tag, + and a ":message" tag in the Sieve script, as well as a "body" key and + a "subject" key in the query component of the XMPP URI. As a result, + the ":message" tag from the Sieve script overrides the "body" key + from the XMPP URI when generating the XML character data of the XMPP + <body/> element. In addition, the Sieve engine includes a URI + pointing to the message, as well as an XMPP SHIM (Stanza Headers and + Internet Metadata) [SHIM] header named "Resent-From" (which + encapsulates the value of the ":from" tag). + + Action with ":from", ":importance", ":message", "body", and "subject" + (Sieve syntax) + + notify :from "romeo.my.romeo@example.com" + :importance "1" + :message "Contact Juliet immediately!" + "xmpp:romeo@im.example.com?message + ;body=You%27re%20in%20trouble + ;subject=ALERT%21" + + The resulting XMPP <message/> stanza might be as follows. + + + + + + +Saint-Andre & Melnikov Standards Track [Page 8] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + + Action with ":from", ":importance", ":message", "body", and "subject" + (XMPP syntax) + + <message from='notify.example.com' + to='romeo@im.example.com' + type='headline' + xml:lang='en'> + <subject>ALERT!</subject> + <body>Contact Juliet immediately!</body> + <headers xmlns='http://jabber.org/protocol/shim'> + <header name='Resent-From'>romeo.my.romeo@example.com</header> + <header name='Urgency'>high</header> + </headers> + <x xmlns='jabber:x:oob'> + <url> + imap://romeo@example.com/INBOX;UIDVALIDITY=385759045/;UID=21 + </url> + </x> + </message> + +4. Requirements Conformance + + Section 3.8 of [NOTIFY] specifies a set of requirements for Sieve + notification methods. The conformance of the xmpp notification + mechanism is provided here. + + 1. An implementation of the xmpp notification method SHOULD NOT + modify the final notification text (e.g., to limit the length); + however, a given deployment MAY do so (e.g., if recipients pay + per character or byte for XMPP messages). Modification of + characters themselves should not be necessary, since XMPP + character data is encoded in [UTF-8]. + + 2. An implementation MAY ignore parameters specified in the + ":from", ":importance", and ":options" tags. + + 3. There is no recommended default message for an implementation to + include if the ":message" tag is not specified. + + 4. A notification sent via the xmpp notification method MAY include + a timestamp in the textual message. + + 5. The value of the XMPP 'from' attribute MUST be the XMPP address + of the notification service associated with the Sieve engine. + The value of the Sieve ":from" tag MAY be transformed into the + value of an XMPP SHIM (Stanza Headers and Internet Metadata) + [SHIM] header named "Resent-From". + + + + +Saint-Andre & Melnikov Standards Track [Page 9] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + + 6. The value of the XMPP 'to' attribute MUST be the XMPP address + specified in the XMPP URI contained in the "method" parameter. + + 7. In accordance with [XMPP-URI], an implementation MUST ignore any + URI action or key it does not understand (i.e., the URI MUST be + processed as if the action or key were not present). It is + RECOMMENDED to support the XMPP "message" query type (see + [QUERIES]) and the associated "body" and "subject" keys, which + SHOULD be mapped to the XMPP <body/> and <subject/> child + elements of the XMPP <message/> stanza, respectively. However, + if included, then the Sieve notify ":message" tag MUST be mapped + to the XMPP <body/> element, overriding the "body" key (if any) + included in the XMPP URI. + + 8. An implementation MUST NOT include any other extraneous + information not specified in parameters to the notify action. + + 9. In response to a notify_method_capability test for the "online" + notification-capability, an implementation SHOULD return a value + of "yes" if it has knowledge of an active presence session (see + [XMPP-IM]) for the specified XMPP notification-uri, but only if + the entity that requested the test is authorized to know the + presence of the associated XMPP entity (e.g., via explicit + presence subscription as specified in [XMPP-IM]); otherwise, it + SHOULD return a value of "maybe" (since typical XMPP systems may + not allow a Sieve engine to gain knowledge about the presence of + XMPP entities). + + 10. An implementation SHOULD NOT attempt to retry delivery of a + notification if it receives an XMPP error of type "auth" or + "cancel", MAY attempt to retry delivery if it receives an XMPP + error of type "wait", and MAY attempt to retry delivery if it + receives an XMPP error of "modify", but only if it makes + appropriate modifications to the notification (see [XMPP]); in + any case, the number of retries SHOULD be limited to a + configurable number no less than 3 and no more than 10. An + implementation MAY throttle notifications if the number of + notifications within a given time period becomes excessive + according to local service policy. Duplicate suppression (if + any) is a matter of implementation and is not specified herein. + +5. Internationalization Considerations + + Although an XMPP address may contain nearly any [UNICODE] character, + the value of the "method" parameter MUST be a Uniform Resource + Identifier (see [URI]) rather than an Internationalized Resource + Identifier (see [IRI]). The rules specified in [XMPP-URI] MUST be + followed when generating XMPP URIs. + + + +Saint-Andre & Melnikov Standards Track [Page 10] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + + In accordance with Section 13 of RFC 3920, all data sent over XMPP + MUST be encoded in [UTF-8]. + +6. Security Considerations + + Depending on the information included, sending a notification can be + comparable to forwarding mail to the notification recipient. Care + must be taken when forwarding mail automatically, to ensure that + confidential information is not sent into an insecure environment. + In particular, implementations MUST conform to the security + considerations given in [NOTIFY], [SIEVE], and [XMPP]. + + [NOTIFY] specifies that a notification method MUST provide mechanisms + for avoiding notification loops. One type of notification loop can + be caused by message forwarding; however, such loops are prevented + because XMPP does not support the forwarding of messages from one + XMPP address to another. Another type of notification loop can be + caused by auto-replies to XMPP messages received by the XMPP + notification service associated with the Sieve engine; therefore, + such a service MUST NOT auto-reply to XMPP messages it receives. + + A common use case might be for a user to create a script that enables + the Sieve engine to act differently if the user is currently + available at a particular type of service (e.g., send notifications + to the user's XMPP address if the user has an active session at an + XMPP service). Whether the user is currently available can be + determined by means of a notify_method_capability test for the + "online" notification-capability. In XMPP, information about current + network availability is called "presence" (see also [MODEL]). Since + [XMPP-IM] requires that a user must approve a presence subscription + before an entity can gain access to the user's presence information, + a limited but reasonably safe implementation might be for the Sieve + engine to request a subscription to the user's presence. The user + would then need to approve that subscription request so that the + Sieve engine can act appropriately depending on whether the user is + online or offline. However, the Sieve engine MUST NOT use the user's + presence information when processing scripts on behalf of a script + owner other than the user, unless the Sieve engine has explicit + knowledge (e.g., via integration with an XMPP server's presence + authorization rules) that the script owner is authorized to know the + user's presence. While it would be possible to design a more + advanced approach to the delegation of presence authorization, any + such approach is left to future standards work. + + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 11] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +7. IANA Considerations + + The following template provides the IANA registration of the Sieve + notification mechanism specified in this document: + + To: iana@iana.org + Subject: Registration of new Sieve notification mechanism + Mechanism name: xmpp + Mechanism URI: RFC 5122 [XMPP-URI] + Mechanism-specific options: none + Permanent and readily available reference: RFC 5437 + Person and email address to contact for further information: + Peter Saint-Andre <registrar@xmpp.org> + + This information has been added to the list of Sieve notification + mechanisms maintained at <http://www.iana.org>. + +8. References + +8.1. Normative References + + [NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and T. + Martin, "Sieve Email Filtering: Extension for + Notifications", RFC 5435, January 2009. + + [OOB] Saint-Andre, P., "Out of Band Data", XSF XEP 0066, + August 2006. + + [QUERIES] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF + XEP 0147, September 2006. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [SHIM] Saint-Andre, P. and J. Hildebrand, "Stanza Headers and + Internet Metadata", XSF XEP 0131, July 2006. + + [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email + Filtering Language", RFC 5228, January 2008. + + [TERMS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers + (IRIs) and Uniform Resource Identifiers (URIs) for the + Extensible Messaging and Presence Protocol (XMPP)", + RFC 5122, February 2008. + + + + +Saint-Andre & Melnikov Standards Track [Page 12] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +8.2. Informative References + + [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + [IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, + November 2007. + + [IRI] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + + [MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for + Presence and Instant Messaging", RFC 2778, February 2000. + + [POP-URL] Gellens, R., "POP URL Scheme", RFC 2384, August 1998. + + [UNICODE] The Unicode Consortium, "The Unicode Standard, Version + 3.2.0", 2000. + + The Unicode Standard, Version 3.2.0 is defined by The + Unicode Standard, Version 3.0 (Reading, MA, Addison- + Wesley, 2000. ISBN 0-201-61633-5), as amended by the + Unicode Standard Annex #27: Unicode 3.1 + (http://www.unicode.org/reports/tr27/) and by the Unicode + Standard Annex #28: Unicode 3.2 + (http://www.unicode.org/reports/tr28/). + + [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [XMPP] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 3920, October 2004. + + [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", + RFC 3921, October 2004. + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 13] + +RFC 5437 Sieve Notify Method: XMPP January 2009 + + +Authors' Addresses + + Peter Saint-Andre + Cisco + + EMail: psaintan@cisco.com + + + Alexey Melnikov + Isode Limited + + EMail: Alexey.Melnikov@isode.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Saint-Andre & Melnikov Standards Track [Page 14] + diff --git a/proto/sieve/rfc5804.txt b/proto/sieve/rfc5804.txt @@ -0,0 +1,2747 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Melnikov, Ed. +Request for Comments: 5804 Isode Limited +Category: Standards Track T. Martin +ISSN: 2070-1721 BeThereBeSquare, Inc. + July 2010 + + + A Protocol for Remotely Managing Sieve Scripts + +Abstract + + Sieve scripts allow users to filter incoming email. Message stores + are commonly sealed servers so users cannot log into them, yet users + must be able to update their scripts on them. This document + describes a protocol "ManageSieve" for securely managing Sieve + scripts on a remote server. This protocol allows a user to have + multiple scripts, and also alerts a user to syntactically flawed + scripts. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5804. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + +Melnikov & Martin Standards Track [Page 1] + +RFC 5804 ManageSieve July 2010 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Commands and Responses .....................................3 + 1.2. Syntax .....................................................3 + 1.3. Response Codes .............................................3 + 1.4. Active Script ..............................................6 + 1.5. Quotas .....................................................6 + 1.6. Script Names ...............................................6 + 1.7. Capabilities ...............................................7 + 1.8. Transport ..................................................9 + 1.9. Conventions Used in This Document .........................10 + 2. Commands .......................................................10 + 2.1. AUTHENTICATE Command ......................................11 + 2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16 + 2.2. STARTTLS Command ..........................................16 + 2.2.1. Server Identity Check ..............................17 + 2.3. LOGOUT Command ............................................20 + 2.4. CAPABILITY Command ........................................20 + 2.5. HAVESPACE Command .........................................20 + 2.6. PUTSCRIPT Command .........................................21 + 2.7. LISTSCRIPTS Command .......................................23 + 2.8. SETACTIVE Command .........................................24 + 2.9. GETSCRIPT Command .........................................25 + 2.10. DELETESCRIPT Command .....................................25 + 2.11. RENAMESCRIPT Command .....................................26 + 2.12. CHECKSCRIPT Command ......................................27 + 2.13. NOOP Command .............................................28 + 2.14. Recommended Extensions ...................................28 + 2.14.1. UNAUTHENTICATE Command ............................28 + 3. Sieve URL Scheme ...............................................29 + 4. Formal Syntax ..................................................31 + 5. Security Considerations ........................................37 + 6. IANA Considerations ............................................38 + 6.1. ManageSieve Capability Registration Template ..............39 + 6.2. Registration of Initial ManageSieve Capabilities ..........39 + 6.3. ManageSieve Response Code Registration Template ...........41 + 6.4. Registration of Initial ManageSieve Response Codes ........41 + 7. Internationalization Considerations ............................46 + 8. Acknowledgements ...............................................46 + 9. References .....................................................47 + 9.1. Normative References ......................................47 + 9.2. Informative References ....................................48 + + + + + + + + +Melnikov & Martin Standards Track [Page 2] + +RFC 5804 ManageSieve July 2010 + + +1. Introduction + +1.1. Commands and Responses + + A ManageSieve connection consists of the establishment of a client/ + server network connection, an initial greeting from the server, and + client/server interactions. These client/server interactions consist + of a client command, server data, and a server completion result + response. + + All interactions transmitted by client and server are in the form of + lines, that is, strings that end with a CRLF. The protocol receiver + of a ManageSieve client or server is either reading a line or reading + a sequence of octets with a known count followed by a line. + +1.2. Syntax + + ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP], + which runs over TCP. There are three data types: atoms, numbers and + strings. Strings may be quoted or literal. See [ACAP] for detailed + descriptions of these types. + + Each command consists of an atom (the command name) followed by zero + or more strings and numbers terminated by CRLF. + + All client queries are replied to with either an OK, NO, or BYE + response. Each response may be followed by a response code (see + Section 1.3) and by a string consisting of human-readable text in the + local language (as returned by the LANGUAGE capability; see + Section 1.7), encoded in UTF-8 [UTF-8]. The contents of the string + SHOULD be shown to the user ,and implementations MUST NOT attempt to + parse the message for meaning. + + The BYE response SHOULD be used if the server wishes to close the + connection. A server may wish to do this because the client was idle + for too long or there were too many failed authentication attempts. + This response can be issued at any time and should be immediately + followed by a server hang-up of the connection. If a server has an + inactivity timeout resulting in client autologout, it MUST be no less + than 30 minutes after successful authentication. The inactivity + timeout MAY be less before authentication. + +1.3. Response Codes + + An OK, NO, or BYE response from the server MAY contain a response + code to describe the event in a more detailed machine-parsable + fashion. A response code consists of data inside parentheses in the + form of an atom, possibly followed by a space and arguments. + + + +Melnikov & Martin Standards Track [Page 3] + +RFC 5804 ManageSieve July 2010 + + + Response codes are defined when there is a specific action that a + client can take based upon the additional information. In order to + support future extension, the response code is represented as a + slash-separated (Solidus, %x2F) hierarchy with each level of + hierarchy representing increasing detail about the error. Response + codes MUST NOT start with the Solidus character. Clients MUST + tolerate additional hierarchical response code detail that they don't + understand. For example, if the client supports the "QUOTA" response + code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it + should treat "QUOTA/MAXSCRIPTS" as "QUOTA". + + Client implementations MUST tolerate (ignore) response codes that + they do not recognize. + + The currently defined response codes are the following: + + AUTH-TOO-WEAK + + This response code is returned in the NO or BYE response from an + AUTHENTICATE command. It indicates that site security policy forbids + the use of the requested mechanism for the specified authentication + identity. + + ENCRYPT-NEEDED + + This response code is returned in the NO or BYE response from an + AUTHENTICATE command. It indicates that site security policy + requires the use of a strong encryption mechanism for the specified + authentication identity and mechanism. + + QUOTA + + If this response code is returned in the NO/BYE response, it means + that the command would have placed the user above the site-defined + quota constraints. If this response code is returned in the OK + response, it can mean that the user's storage is near its quota, or + it can mean that the account exceeded its quota but that the + condition is being allowed by the server (the server supports + so-called soft quotas). The QUOTA response code has two more + detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user + scripts) and "QUOTA/MAXSIZE" (the maximum script size). + + REFERRAL + + This response code may be returned with a BYE result from any + command, and includes a mandatory parameter that indicates what + server to access to manage this user's Sieve scripts. The server + will be specified by a Sieve URL (see Section 3). The scriptname + + + +Melnikov & Martin Standards Track [Page 4] + +RFC 5804 ManageSieve July 2010 + + + portion of the URL MUST NOT be specified. The client should + authenticate to the specified server and use it for all further + commands in the current session. + + SASL + + This response code can occur in the OK response to a successful + AUTHENTICATE command and includes the optional final server response + data from the server as specified by [SASL]. + + TRANSITION-NEEDED + + This response code occurs in a NO response of an AUTHENTICATE + command. It indicates that the user name is valid, but the entry in + the authentication database needs to be updated in order to permit + authentication with the specified mechanism. This is typically done + by establishing a secure channel using TLS, verifying server identity + as specified in Section 2.2.1, and finally authenticating once using + the [PLAIN] authentication mechanism. The selected mechanism SHOULD + then work for authentications in subsequent sessions. + + This condition can happen if a user has an entry in a system + authentication database such as Unix /etc/passwd, but does not have + credentials suitable for use by the specified mechanism. + + TRYLATER + + A command failed due to a temporary server failure. The client MAY + continue using local information and try the command later. This + response code only makes sense when returned in a NO/BYE response. + + ACTIVE + + A command failed because it is not allowed on the active script, for + example, DELETESCRIPT on the active script. This response code only + makes sense when returned in a NO/BYE response. + + NONEXISTENT + + A command failed because the referenced script name doesn't exist. + This response code only makes sense when returned in a NO/BYE + response. + + ALREADYEXISTS + + A command failed because the referenced script name already exists. + This response code only makes sense when returned in a NO/BYE + response. + + + +Melnikov & Martin Standards Track [Page 5] + +RFC 5804 ManageSieve July 2010 + + + TAG + + This response code name is followed by a string specified in the + command. See Section 2.13 for a possible use case. + + WARNINGS + + This response code MAY be returned by the server in the OK response + (but it might be returned with the NO/BYE response as well) and + signals the client that even though the script is syntactically + valid, it might contain errors not intended by the script writer. + This response code is typically returned in response to PUTSCRIPT + and/or CHECKSCRIPT commands. A client seeing such response code + SHOULD present the returned warning text to the user. + +1.4. Active Script + + A user may have multiple Sieve scripts on the server, yet only one + script may be used for filtering of incoming messages. This is the + active script. Users may have zero or one active script and MUST use + the SETACTIVE command described below for changing the active script + or disabling Sieve processing. For example, users may have an + everyday script they normally use and a special script they use when + they go on vacation. Users can change which script is being used + without having to download and upload a script stored somewhere else. + +1.5. Quotas + + Servers SHOULD impose quotas to prevent malicious users from + overflowing available storage. If a command would place a user over + a quota setting, servers that impose such quotas MUST reply with a NO + response containing the QUOTA response code. Client implementations + MUST be able to handle commands failing because of quota + restrictions. + +1.6. Script Names + + A Sieve script name is a sequence of Unicode characters encoded in + UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition + (Section 2 of [NET-UNICODE]), with the additional restriction of + prohibiting the following Unicode characters: + + o 0000-001F; [CONTROL CHARACTERS] + + o 007F; DELETE + + o 0080-009F; [CONTROL CHARACTERS] + + + + +Melnikov & Martin Standards Track [Page 6] + +RFC 5804 ManageSieve July 2010 + + + o 2028; LINE SEPARATOR + + o 2029; PARAGRAPH SEPARATOR + + Sieve script names MUST be at least one octet (and hence Unicode + character) long. Zero octets script name has a special meaning (see + Section 2.8). Servers MUST allow names of up to 128 Unicode + characters in length (which can take up to 512 bytes when encoded in + UTF-8, not counting the terminating NUL), and MAY allow longer names. + A server that receives a script name longer than its internal limit + MUST reject the corresponding operation, in particular it MUST NOT + truncate the script name. + +1.7. Capabilities + + Server capabilities are sent automatically by the server upon a + client connection, or after successful STARTTLS and AUTHENTICATE + (which establishes a Simple Authentication and Security Layer (SASL)) + commands. Capabilities may change immediately after a successfully + completed STARTTLS command, and/or immediately after a successfully + completed AUTHENTICATE command, and/or after a successfully completed + UNAUTHENTICATE command (see Section 2.14.1). Capabilities MUST + remain static at all other times. + + Clients MAY request the capabilities at a later time by issuing the + CAPABILITY command described later. The capabilities consist of a + series of lines each with one or two strings. The first string is + the name of the capability, which is case-insensitive. The second + optional string is the value associated with that capability. Order + of capabilities is arbitrary, but each capability name can appear at + most once. + + The following capabilities are defined in this document: + + IMPLEMENTATION - Name of implementation and version. This capability + MUST always be returned by the server. + + SASL - List of SASL mechanisms supported by the server, each + separated by a space. This list can be empty if and only if STARTTLS + is also advertised. This means that the client must negotiate TLS + encryption with STARTTLS first, at which point the SASL capability + will list a non-empty list of SASL mechanisms. + + SIEVE - List of space-separated Sieve extensions (as listed in Sieve + "require" action [SIEVE]) supported by the Sieve engine. This + capability MUST always be returned by the server. + + + + + +Melnikov & Martin Standards Track [Page 7] + +RFC 5804 ManageSieve July 2010 + + + STARTTLS - If TLS [TLS] is supported by this implementation. Before + advertising this capability a server MUST verify to the best of its + ability that TLS can be successfully negotiated by a client with + common cipher suites. Specifically, a server should verify that a + server certificate has been installed and that the TLS subsystem has + successfully initialized. This capability SHOULD NOT be advertised + once STARTTLS or AUTHENTICATE command completes successfully. Client + and server implementations MUST implement the STARTTLS extension. + + MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" + actions a script can perform during a single evaluation. Note that + this is different from the total number of "redirect" actions a + script can contain. The value is a non-negative number represented + as a ManageSieve string. + + NOTIFY - A space-separated list of URI schema parts for supported + notification methods. This capability MUST be specified if the Sieve + implementation supports the "enotify" extension [NOTIFY]. + + LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently + used for human-readable error messages. If this capability is not + returned, the "i-default" [RFC2277] language is assumed. Note that + the current language MAY be per-user configurable (i.e., it MAY + change after authentication). + + OWNER - The canonical name of the logged-in user (SASL "authorization + identity") encoded in UTF-8. This capability MUST NOT be returned in + unauthenticated state and SHOULD be returned once the AUTHENTICATE + command succeeds. + + VERSION - This capability MUST be returned by servers compliant with + this document or its successor. For servers compliant with this + document, the capability value is the string "1.0". Lack of this + capability means that the server predates this specification and thus + doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT, + and NOOP. + + Section 2.14 defines some additional ManageSieve extensions and their + respective capabilities. + + A server implementation MUST return SIEVE, IMPLEMENTATION, and + VERSION capabilities. + + A client implementation MUST ignore any listed capabilities that it + does not understand. + + + + + + +Melnikov & Martin Standards Track [Page 8] + +RFC 5804 ManageSieve July 2010 + + + Example: + + S: "IMPlemENTATION" "Example1 ManageSieved v001" + S: "SASl" "DIGEST-MD5 GSSAPI" + S: "SIeVE" "fileinto vacation" + S: "StaRTTLS" + S: "NOTIFY" "xmpp mailto" + S: "MAXREdIRECTS" "5" + S: "VERSION" "1.0" + S: OK + + After successful authentication, this might look like this: + + Example: + + S: "IMPlemENTATION" "Example1 ManageSieved v001" + S: "SASl" "DIGEST-MD5 GSSAPI" + S: "SIeVE" "fileinto vacation" + S: "NOTIFY" "xmpp mailto" + S: "OWNER" "alexey@example.com" + S: "MAXREdIRECTS" "5" + S: "VERSION" "1.0" + S: OK + +1.8. Transport + + The ManageSieve protocol assumes a reliable data stream such as that + provided by TCP. When TCP is used, a ManageSieve server typically + listens on port 4190. + + Before opening the TCP connection, the ManageSieve client first MUST + resolve the Domain Name System (DNS) hostname associated with the + receiving entity and determine the appropriate TCP port for + communication with the receiving entity. The process is as follows: + + 1. Attempt to resolve the hostname using a [DNS-SRV] Service of + "sieve" and a Proto of "tcp" for the target domain (e.g., + "example.net"), resulting in resource records such as + "_sieve._tcp.example.net.". The result of the SRV lookup, if + successful, will be one or more combinations of a port and + hostname; the ManageSieve client MUST resolve the returned + hostnames to IPv4/IPv6 addresses according to returned SRV record + weight. IP addresses from the first successfully resolved + hostname (with the corresponding port number returned by SRV + lookup) are used to connect to the server. If connection using + one of the IP addresses fails, the next resolved IP address is + + + + + +Melnikov & Martin Standards Track [Page 9] + +RFC 5804 ManageSieve July 2010 + + + used to connect. If connection to all resolved IP addresses + fails, then the resolution/connect is repeated for the next + hostname returned by SRV lookup. + + 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or + IPv6 address record resolution to determine the IP address, where + the port used is the default ManageSieve port of 4190. + +1.9. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. Line breaks that do not start a new "C:" or + "S:" exist for editorial reasons. + + Examples of authentication in this document are using DIGEST-MD5 + [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms. + +2. Commands + + This section and its subsections describe valid ManageSieve commands. + Upon initial connection to the server, the client's session is in + non-authenticated state. Prior to successful authentication, only + the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section + 2.13) commands are valid. ManageSieve extensions MAY define other + commands that are valid in non-authenticated state. Servers MUST + reject all other commands with a NO response. Clients may pipeline + commands (send more than one command at a time without waiting for + completion of the first command). However, a group of commands sent + together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a + HAVESPACE command anywhere but the last command in the list. + + (*) - The only exception to this rule is when the AUTHENTICATE + command contains an initial response for a SASL mechanism that allows + clients to send data first, the mechanism is known to complete in one + round trip, and the mechanism doesn't negotiate a SASL security + layer. Two examples of such SASL mechanisms are PLAIN [PLAIN] and + EXTERNAL [SASL]. + + + + + + + + + + +Melnikov & Martin Standards Track [Page 10] + +RFC 5804 ManageSieve July 2010 + + +2.1. AUTHENTICATE Command + + Arguments: String - mechanism + String - initial data (optional) + + The AUTHENTICATE command indicates a SASL [SASL] authentication + mechanism to the server. If the server supports the requested + authentication mechanism, it performs an authentication protocol + exchange to identify and authenticate the user. Optionally, it also + negotiates a security layer for subsequent protocol interactions. If + the requested authentication mechanism is not supported, the server + rejects the AUTHENTICATE command by sending the NO response. + + The authentication protocol exchange consists of a series of server + challenges and client responses that are specific to the selected + authentication mechanism. A server challenge consists of a string + (quoted or literal) followed by a CRLF. The contents of the string + is a base-64 encoding [BASE64] of the SASL data. A client response + consists of a string (quoted or literal) with the base-64 encoding of + the SASL data followed by a CRLF. If the client wishes to cancel the + authentication exchange, it issues a string containing a single "*". + If the server receives such a response, it MUST reject the + AUTHENTICATE command by sending a NO reply. + + Note that an empty challenge/response is sent as an empty string. If + the mechanism dictates that the final response is sent by the server, + this data MAY be placed within the data portion of the SASL response + code to save a round trip. + + The optional initial-response argument to the AUTHENTICATE command is + used to save a round trip when using authentication mechanisms that + are defined to send no data in the initial challenge. When the + initial-response argument is used with such a mechanism, the initial + empty challenge is not sent to the client and the server uses the + data in the initial-response argument as if it were sent in response + to the empty challenge. If the initial-response argument to the + AUTHENTICATE command is used with a mechanism that sends data in the + initial challenge, the server MUST reject the AUTHENTICATE command by + sending the NO response. + + The service name specified by this protocol's profile of SASL is + "sieve". + + Reauthentication is not supported by ManageSieve protocol's profile + of SASL. That is, after a successfully completed AUTHENTICATE + command, no more AUTHENTICATE commands may be issued in the same + session. After a successful AUTHENTICATE command completes, a server + MUST reject any further AUTHENTICATE commands with a NO reply. + + + +Melnikov & Martin Standards Track [Page 11] + +RFC 5804 ManageSieve July 2010 + + + However, note that a server may implement the UNAUTHENTICATE + extension described in Section 2.14.1. + + If a security layer is negotiated through the SASL authentication + exchange, it takes effect immediately following the CRLF that + concludes the successful authentication exchange for the client, and + the CRLF of the OK response for the server. + + When a security layer takes effect, the ManageSieve protocol is reset + to the initial state (the state in ManageSieve after a client has + connected to the server). The server MUST discard any knowledge + obtained from the client that was not obtained from the SASL (or TLS) + negotiation itself. Likewise, the client MUST discard any knowledge + obtained from the server, such as the list of ManageSieve extensions, + that was not obtained from the SASL (and/or TLS) negotiation itself. + (Note that a client MAY compare the advertised SASL mechanisms before + and after authentication in order to detect an active down- + negotiation attack. See below.) + + Once a SASL security layer is established, the server MUST re-issue + the capability results, followed by an OK response. This is + necessary to protect against man-in-the-middle attacks that alter the + capabilities list prior to SASL negotiation. The capability results + MUST include all SASL mechanisms the server was capable of + negotiating with that client. This is done in order to allow the + client to detect an active down-negotiation attack. If a user- + oriented client detects such a down-negotiation attack, it SHOULD + either notify the user (it MAY give the user the opportunity to + continue with the ManageSieve session in this case) or close the + transport connection and indicate that a down-negotiation attack + might be in progress. If an automated client detects a down- + negotiation attack, it SHOULD return or log an error indicating that + a possible attack might be in progress and/or SHOULD close the + transport connection. + + When both [TLS] and SASL security layers are in effect, the TLS + encoding MUST be applied (when sending data) after the SASL encoding. + + Server implementations SHOULD support SASL proxy authentication so + that an administrator can administer a user's scripts. Proxy + authentication is when a user authenticates as herself/himself but + requests the server to act (authorize) as another user. + + The authorization identity generated by this [SASL] exchange is a + "simple username" (in the sense defined in [SASLprep]), and both + client and server MUST use the [SASLprep] profile of the [StringPrep] + algorithm to prepare these names for transmission or comparison. If + preparation of the authorization identity fails or results in an + + + +Melnikov & Martin Standards Track [Page 12] + +RFC 5804 ManageSieve July 2010 + + + empty string (unless it was transmitted as the empty string), the + server MUST fail the authentication. + + If an AUTHENTICATE command fails with a NO response, the client MAY + try another authentication mechanism by issuing another AUTHENTICATE + command. In other words, the client may request authentication types + in decreasing order of preference. + + Note that a failed (NO) response to the AUTHENTICATE command may + contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT- + NEEDED, or TRANSITION-NEEDED. See Section 1.3 for detailed + description of the relevant conditions. + + To ensure interoperability, both client and server implementations of + the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL + mechanism, as well as [PLAIN] over [TLS]. + + Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in + other email-related protocols; however, a longer-term goal is to + migrate email-related protocols from using PLAIN over TLS to SCRAM- + SHA-1 mechanism. + + Examples (Note that long lines are folded for readability and are not + part of protocol exchange): + + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "SASL" "DIGEST-MD5 GSSAPI" + S: "SIEVE" "fileinto vacation" + S: "STARTTLS" + S: "VERSION" "1.0" + S: OK + C: Authenticate "DIGEST-MD5" + S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik + 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz + cyxjaGFyc2V0PXV0Zi04" + C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 + QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo + aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX + N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy + ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 + A9YXV0aA==" + S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ + mZmZA==") + + + + + + + + +Melnikov & Martin Standards Track [Page 13] + +RFC 5804 ManageSieve July 2010 + + + A slightly different variant of the same authentication exchange is: + + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "SASL" "DIGEST-MD5 GSSAPI" + S: "SIEVE" "fileinto vacation" + S: "VERSION" "1.0" + S: "STARTTLS" + S: OK + C: Authenticate "DIGEST-MD5" + S: {136} + S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik + 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz + cyxjaGFyc2V0PXV0Zi04 + C: {300+} + C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2 + QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo + aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX + N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy + ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3 + A9YXV0aA== + S: {56} + S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== + C: "" + S: OK + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov & Martin Standards Track [Page 14] + +RFC 5804 ManageSieve July 2010 + + + Another example demonstrating use of SASL PLAIN mechanism under TLS + follows. This example also demonstrate use of SASL "initial + response" (the second parameter to the Authenticate command): + + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "VERSION" "1.0" + S: "SASL" "" + S: "SIEVE" "fileinto vacation" + S: "STARTTLS" + S: OK + C: STARTTLS + S: OK + <TLS negotiation, further commands are under TLS layer> + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "VERSION" "1.0" + S: "SASL" "PLAIN" + S: "SIEVE" "fileinto vacation" + S: OK + C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu" + S: NO + C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz" + S: NO + C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy" + S: BYE "Too many failed authentication attempts" + <Server closes connection> + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov & Martin Standards Track [Page 15] + +RFC 5804 ManageSieve July 2010 + + + The following example demonstrates use of SASL "initial response". + It also demonstrates that an empty response can be sent as a literal + and that negotiating a SASL security layer results in the server + re-issuing server capabilities: + + C: AUTHENTICATE "GSSAPI" {1488+} + C: YIIE[...1480 octets here ...]dA== + S: {208} + S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic + [...114 octets here ...] + /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6 + C: {0+} + C: + S: {44} + S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA= + C: {44+} + C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE= + S: OK + <Further commands/responses are under SASL security layer> + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "VERSION" "1.0" + S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" + S: "SIEVE" "fileinto vacation" + S: "LANGUAGE" "ru" + S: "MAXREDIRECTS" "3" + S: ok + +2.1.1. Use of SASL PLAIN Mechanism over TLS + + This section is normative for ManageSieve client implementations that + support SASL [PLAIN] over [TLS]. + + If a ManageSieve client is willing to use SASL PLAIN over TLS to + authenticate to the ManageSieve server, the client MUST verify the + server identity (see Section 2.2.1). If the server identity can't be + verified (e.g., the server has not provided any certificate, or if + the certificate verification fails), the client MUST NOT attempt to + authenticate using the SASL PLAIN mechanism. + +2.2. STARTTLS Command + + Support for STARTTLS command in servers is optional. Its + availability is advertised with "STARTTLS" capability as described in + Section 1.7. + + The STARTTLS command requests commencement of a TLS [TLS] + negotiation. The negotiation begins immediately after the CRLF in + the OK response. After a client issues a STARTTLS command, it MUST + + + +Melnikov & Martin Standards Track [Page 16] + +RFC 5804 ManageSieve July 2010 + + + NOT issue further commands until a server response is seen and the + TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. The + server remains in non-authenticated state, even if client credentials + are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL + mechanism MAY be used to authenticate once TLS client credentials are + successfully exchanged, but servers supporting the STARTTLS command + are not required to support the EXTERNAL mechanism. + + After the TLS layer is established, the server MUST re-issue the + capability results, followed by an OK response. This is necessary to + protect against man-in-the-middle attacks that alter the capabilities + list prior to STARTTLS. This capability result MUST NOT include the + STARTTLS capability. + + The client MUST discard cached capability information and replace it + with the new information. The server MAY advertise different + capabilities after STARTTLS. + + Example: + + C: StartTls + S: oK + <TLS negotiation, further commands are under TLS layer> + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "SASL" "PLAIN DIGEST-MD5 GSSAPI" + S: "SIEVE" "fileinto vacation" + S: "VERSION" "1.0" + S: "LANGUAGE" "fr" + S: ok + +2.2.1. Server Identity Check + + During the TLS negotiation, the ManageSieve client MUST check its + understanding of the server hostname/IP address against the server's + identity as presented in the server Certificate message, in order to + prevent man-in-the-middle attacks. In this section, the client's + understanding of the server's identity is called the "reference + identity". + + Checking is performed according to the following rules: + + o If the reference identity is a hostname: + + 1. If a subjectAltName extension of the SRVName [X509-SRV], + dNSName [X509] (in that order of preference) type is present + in the server's certificate, then it SHOULD be used as the + + + +Melnikov & Martin Standards Track [Page 17] + +RFC 5804 ManageSieve July 2010 + + + source of the server's identity. Matching is performed as + described in Section 2.2.1.1, with the exception that no + wildcard matching is allowed for SRVName type. If the + certificate contains multiple names (e.g., more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + + 2. The client MAY use other types of subjectAltName for + performing comparison. + + 3. The server's identity MAY also be verified by comparing the + reference identity to the Common Name (CN) [RFC4519] value in + the leaf Relative Distinguished Name (RDN) of the subjectName + field of the server's certificate. This comparison is + performed using the rules for comparison of DNS names in + Section 2.2.1.1, below. Although the use of the Common Name + value is existing practice, it is deprecated, and + Certification Authorities are encouraged to provide + subjectAltName values instead. Note that the TLS + implementation may represent DNs in certificates according to + X.500 or other conventions. For example, some X.500 + implementations order the RDNs in a DN using a left-to-right + (most significant to least significant) convention instead of + LDAP's right-to-left convention. + + o When the reference identity is an IP address, the iPAddress + subjectAltName SHOULD be used by the client for comparison. The + comparison is performed as described in Section 2.2.1.2. + + If the server identity check fails, user-oriented clients SHOULD + either notify the user (clients MAY give the user the opportunity to + continue with the ManageSieve session in this case) or close the + transport connection and indicate that the server's identity is + suspect. Automated clients SHOULD return or log an error indicating + that the server's identity is suspect and/or SHOULD close the + transport connection. Automated clients MAY provide a configuration + setting that disables this check, but MUST provide a setting that + enables it. + + Beyond the server identity check described in this section, clients + should be prepared to do further checking to ensure that the server + is authorized to provide the service it is requested to provide. The + client may need to make use of local policy information in making + this determination. + + + + + + + +Melnikov & Martin Standards Track [Page 18] + +RFC 5804 ManageSieve July 2010 + + +2.2.1.1. Comparison of DNS Names + + If the reference identity is an internationalized domain name, + conforming implementations MUST convert it to the ASCII Compatible + Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] + before comparison with subjectAltName values of type dNSName. + Specifically, conforming implementations MUST perform the conversion + operation specified in Section 4 of [RFC3490] as follows: + + o in step 1, the domain name SHALL be considered a "stored string"; + + o in step 3, set the flag called "UseSTD3ASCIIRules"; + + o in step 4, process each label with the "ToASCII" operation; and + + o in step 5, change all label separators to U+002E (full stop). + + After performing the "to-ASCII" conversion, the DNS labels and names + MUST be compared for equality according to the rules specified in + Section 3 of [RFC3490]; i.e., once all label separators are replaced + with U+002E (dot) they are compared in the case-insensitive manner. + + The '*' (ASCII 42) wildcard character is allowed in subjectAltName + values of type dNSName, and then only as the left-most (least + significant) DNS label in that value. This wildcard matches any + left-most DNS label in the server name. That is, the subject + *.example.com matches the server names a.example.com and + b.example.com, but does not match example.com or a.b.example.com. + +2.2.1.2. Comparison of IP Addresses + + When the reference identity is an IP address, the identity MUST be + converted to the "network byte order" octet string representation + [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the + octet string will contain exactly four octets. For IP Version 6, as + specified in RFC 2460, the octet string will contain exactly sixteen + octets. This octet string is then compared against subjectAltName + values of type iPAddress. A match occurs if the reference identity + octet string and value octet strings are identical. + +2.2.1.3. Comparison of Other subjectName Types + + Client implementations MAY support matching against subjectAltName + values of other types as described in other documents. + + + + + + + +Melnikov & Martin Standards Track [Page 19] + +RFC 5804 ManageSieve July 2010 + + +2.3. LOGOUT Command + + The client sends the LOGOUT command when it is finished with a + connection and wishes to terminate it. The server MUST reply with an + OK response. The server MUST ignore commands issued by the client + after the LOGOUT command. + + The client SHOULD wait for the OK response before closing the + connection. This avoids the TCP connection going into the TIME_WAIT + state on the server. In order to avoid going into the TIME_WAIT TCP + state, the server MAY wait for a short while for the client to close + the TCP connection first. Whether or not the server waits for the + client to close the connection, it MUST then close the connection + itself. + + Example: + + C: Logout + S: Ok + <connection is terminated> + +2.4. CAPABILITY Command + + The CAPABILITY command requests the server capabilities as described + earlier in this document. It has no parameters. + + Example: + + C: CAPABILITY + S: "IMPLEMENTATION" "Example1 ManageSieved v001" + S: "VERSION" "1.0" + S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI" + S: "SIEVE" "fileinto vacation" + S: "STARTTLS" + S: OK + +2.5. HAVESPACE Command + + Arguments: String - name + Number - script size + + The HAVESPACE command is used to query the server for available + space. Clients specify the name they wish to save the script as and + its size in octets. Both parameters can be used by the server to see + if the script with the specified name and size is within a user's + quota(s). For example, the server MAY use the script name to check + if a script would be replaced or a new one would be created. Servers + respond with a NO if storing a script with that name and size would + + + +Melnikov & Martin Standards Track [Page 20] + +RFC 5804 ManageSieve July 2010 + + + fail or OK otherwise. Clients SHOULD issue this command before + attempting to place a script on the server. + + Note that the OK response from the HAVESPACE command does not + constitute a guarantee of success as server disk space conditions + could change between the client issuing the HAVESPACE and the client + issuing the PUTSCRIPT commands. A QUOTA response code (see + Section 1.3) remains a possible (albeit unlikely) response to a + subsequent PUTSCRIPT with the same name and size. + + Example: + + C: HAVESPACE "myscript" 999999 + S: NO (QUOTA/MAXSIZE) "Quota exceeded" + + C: HAVESPACE "foobar" 435 + S: OK + +2.6. PUTSCRIPT Command + + Arguments: String - Script name + String - Script content + + The PUTSCRIPT command is used by the client to submit a Sieve script + to the server. + + If the script already exists, upon success the old script will be + overwritten. The old script MUST NOT be overwritten if PUTSCRIPT + fails in any way. A script of zero length SHOULD be disallowed. + + This command places the script on the server. It does not affect + whether the script is processed on incoming mail, unless it replaces + the script that is already active. The SETACTIVE command is used to + mark a script as active. + + When submitting large scripts, clients SHOULD use the HAVESPACE + command beforehand to query if the server is willing to accept a + script of that size. + + The server MUST check the submitted script for validity, which + includes checking that the script complies with the Sieve grammar + [SIEVE] and that all Sieve extensions mentioned in the script's + "require" statement(s) are supported by the Sieve interpreter. (Note + that if the Sieve interpreter supports the Sieve "ihave" extension + [I-HAVE], any unrecognized/unsupported extension mentioned in the + "ihave" test MUST NOT cause the validation failure.) Other checks + such as validating the supplied command arguments for each command + MAY be performed. Essentially, the performed validation SHOULD be + + + +Melnikov & Martin Standards Track [Page 21] + +RFC 5804 ManageSieve July 2010 + + + the same as performed when compiling the script for execution. + Implementations that use a binary representation to store compiled + scripts can extend the validation to a full compilation, in order to + avoid validating uploaded scripts multiple times. + + If the script fails the validation, the server MUST reply with a NO + response. Any script that fails the validity test MUST NOT be stored + on the server. The message given with a NO response MUST be human + readable and SHOULD contain a specific error message giving the line + number of the first error. Implementors should strive to produce + helpful error messages similar to those given by programming language + compilers. Client implementations should note that this may be a + multiline literal string with more than one error message separated + by CRLFs. The human-readable message is in the language returned in + the latest LANGUAGE capability (or in "i-default"; see Section 1.7), + encoded in UTF-8 [UTF-8]. + + An OK response MAY contain the WARNINGS response code. In such a + case the human-readable message that follows the OK response SHOULD + contain a specific warning message (or messages) giving the line + number(s) in the script that might contain errors not intended by the + script writer. The human-readable message is in the language + returned in the latest LANGUAGE capability (or in "i-default"; see + Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a + response code SHOULD present the message to the user. + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov & Martin Standards Track [Page 22] + +RFC 5804 ManageSieve July 2010 + + + Examples: + + C: Putscript "foo" {31+} + C: #comment + C: InvalidSieveCommand + C: + S: NO "line 2: Syntax error" + + C: Putscript "mysievescript" {110+} + C: require ["fileinto"]; + C: + C: if envelope :contains "to" "tmartin+sent" { + C: fileinto "INBOX.sent"; + C: } + S: OK + + C: Putscript "myforwards" {190+} + C: redirect "111@example.net"; + C: + C: if size :under 10k { + C: redirect "mobile@cell.example.com"; + C: } + C: + C: if envelope :contains "to" "tmartin+lists" { + C: redirect "lists@groups.example.com"; + C: } + S: OK (WARNINGS) "line 8: server redirect action + limit is 2, this redirect might be ignored" + +2.7. LISTSCRIPTS Command + + This command lists the scripts the user has on the server. Upon + success, a list of CRLF-separated script names (each represented as a + quoted or literal string) is returned followed by an OK response. If + there exists an active script, the atom ACTIVE is appended to the + corresponding script name. The atom ACTIVE MUST NOT appear on more + than one response line. + + + + + + + + + + + + + + +Melnikov & Martin Standards Track [Page 23] + +RFC 5804 ManageSieve July 2010 + + + Example: + + C: Listscripts + S: "summer_script" + S: "vacation_script" + S: {13} + S: clever"script + S: "main_script" ACTIVE + S: OK + + C: listscripts + S: "summer_script" + S: "main_script" active + S: OK + +2.8. SETACTIVE Command + + Arguments: String - script name + + This command sets a script active. If the script name is the empty + string (i.e., ""), then any active script is disabled. Disabling an + active script when there is no script active is not an error and MUST + result in an OK reply. + + If the script does not exist on the server, then the server MUST + reply with a NO response. Such a reply SHOULD contain the + NONEXISTENT response code. + + Examples: + + C: Setactive "vacationscript" + S: Ok + + C: Setactive "" + S: Ok + + C: Setactive "baz" + S: No (NONEXISTENT) "There is no script by that name" + + C: Setactive "baz" + S: No (NONEXISTENT) {31} + S: There is no script by that name + + + + + + + + + +Melnikov & Martin Standards Track [Page 24] + +RFC 5804 ManageSieve July 2010 + + +2.9. GETSCRIPT Command + + Arguments: String - script name + + This command gets the contents of the specified script. If the + script does not exist, the server MUST reply with a NO response. + Such a reply SHOULD contain the NONEXISTENT response code. + + Upon success, a string with the contents of the script is returned + followed by an OK response. + + Example: + + C: Getscript "myscript" + S: {54} + S: #this is my wonderful script + S: reject "I reject all"; + S: + S: OK + +2.10. DELETESCRIPT Command + + Arguments: String - script name + + This command is used to delete a user's Sieve script. Servers MUST + reply with a NO response if the script does not exist. Such + responses SHOULD include the NONEXISTENT response code. + + The server MUST NOT allow the client to delete an active script, so + the server MUST reply with a NO response if attempted. Such a + response SHOULD contain the ACTIVE response code. If a client wishes + to delete an active script, it should use the SETACTIVE command to + disable the script first. + + Example: + + C: Deletescript "foo" + S: Ok + + C: Deletescript "baz" + S: No (ACTIVE) "You may not delete an active script" + + + + + + + + + + +Melnikov & Martin Standards Track [Page 25] + +RFC 5804 ManageSieve July 2010 + + +2.11. RENAMESCRIPT Command + + Arguments: String - Old Script name + String - New Script name + + This command is used to rename a user's Sieve script. Servers MUST + reply with a NO response if the old script does not exist (in which + case the NONEXISTENT response code SHOULD be included), or a script + with the new name already exists (in which case the ALREADYEXISTS + response code SHOULD be included). Renaming the active script is + allowed; the renamed script remains active. + + Example: + + C: Renamescript "foo" "bar" + S: Ok + + C: Renamescript "baz" "bar" + S: No "bar already exists" + + If the server doesn't support the RENAMESCRIPT command, the client + can emulate it by performing the following steps: + + 1. List available scripts with LISTSCRIPTS. If the script with the + new script name exists, then the client should ask the user + whether to abort the operation, to replace the script (by issuing + the DELETESCRIPT <newname> after that), or to choose a different + name. + + 2. Download the old script with GETSCRIPT <oldname>. + + 3. Upload the old script with the new name: PUTSCRIPT <newname>. + + 4. If the old script was active (as reported by LISTSCRIPTS in step + 1), then make the new script active: SETACTIVE <newname>. + + 5. Delete the old script: DELETESCRIPT <oldname>. + + Note that these steps don't describe how to handle various other + error conditions (for example, NO response containing QUOTA response + code in step 3). Error handling is left as an exercise for the + reader. + + + + + + + + + +Melnikov & Martin Standards Track [Page 26] + +RFC 5804 ManageSieve July 2010 + + +2.12. CHECKSCRIPT Command + + Arguments: String - Script content + + The CHECKSCRIPT command is used by the client to verify Sieve script + validity without storing the script on the server. + + The server MUST check the submitted script for syntactic validity, + which includes checking that all Sieve extensions mentioned in Sieve + script "require" statement(s) are supported by the Sieve interpreter. + (Note that if the Sieve interpreter supports the Sieve "ihave" + extension [I-HAVE], any unrecognized/unsupported extension mentioned + in the "ihave" test MUST NOT cause the syntactic validation failure.) + If the script fails this test, the server MUST reply with a NO + response. The message given with a NO response MUST be human + readable and SHOULD contain a specific error message giving the line + number of the first error. Implementors should strive to produce + helpful error messages similar to those given by programming language + compilers. Client implementations should note that this may be a + multiline literal string with more than one error message separated + by CRLFs. The human-readable message is in the language returned in + the latest LANGUAGE capability (or in "i-default"; see Section 1.7), + encoded in UTF-8 [UTF-8]. + + Examples: + + C: CheckScript {31+} + C: #comment + C: InvalidSieveCommand + C: + S: NO "line 2: Syntax error" + + A ManageSieve server supporting this command MUST NOT check if the + script will put the current user over its quota limit. + + An OK response MAY contain the WARNINGS response code. In such a + case, the human-readable message that follows the OK response SHOULD + contain a specific warning message (or messages) giving the line + number(s) in the script that might contain errors not intended by the + script writer. The human-readable message is in the language + returned in the latest LANGUAGE capability (or in "i-default"; see + Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a + response code SHOULD present the message to the user. + + + + + + + + +Melnikov & Martin Standards Track [Page 27] + +RFC 5804 ManageSieve July 2010 + + +2.13. NOOP Command + + Arguments: String - tag to echo back (optional) + + The NOOP command does nothing, beyond returning a response to the + client. It may be used by clients for protocol re-synchronization or + to reset any inactivity auto-logout timer on the server. + + The response to the NOOP command is always OK, followed by the TAG + response code together with the supplied string. If no string was + supplied in the NOOP command, the TAG response code MUST NOT be + included. + + Examples: + + C: NOOP + S: OK "NOOP completed" + + C: NOOP "STARTTLS-SYNC-42" + S: OK (TAG {16} + S: STARTTLS-SYNC-42) "Done" + +2.14. Recommended Extensions + + The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" + capability with no parameters) defines a new UNAUTHENTICATE command, + which allows a client to return the server to non-authenticated + state. Support for this extension is RECOMMENDED. + +2.14.1. UNAUTHENTICATE Command + + The UNAUTHENTICATE command returns the server to the + non-authenticated state. It doesn't affect any previously + established TLS [TLS] or SASL (Section 2.1) security layer. + + The UNAUTHENTICATE command is only valid in authenticated state. If + issued in a wrong state, the server MUST reject it with a NO + response. + + The UNAUTHENTICATE command has no parameters. + + When issued in the authenticated state, the UNAUTHENTICATE command + MUST NOT fail (i.e., it must never return anything other than OK or + BYE). + + + + + + + +Melnikov & Martin Standards Track [Page 28] + +RFC 5804 ManageSieve July 2010 + + +3. Sieve URL Scheme + + URI scheme name: sieve + + Status: permanent + + URI scheme syntax: Described using ABNF [ABNF]. Some ABNF + productions not defined below are from [URI-GEN]. + + sieveurl = sieveurl-server / sieveurl-list-scripts / + sieveurl-script + + sieveurl-server = "sieve://" authority + + sieveurl-list-scripts = "sieve://" authority ["/"] + + sieveurl-script = "sieve://" authority "/" + [owner "/"] scriptname + + authority = <defined in [URI-GEN]> + + owner = *ochar + ;; %-encoded version of [SASL] authorization + ;; identity (script owner) or "userid". + ;; + ;; Empty owner is used to reference + ;; global scripts. + ;; + ;; Note that ASCII characters such as " ", ";", + ;; "&", "=", "/" and "?" must be %-encoded + ;; as per rule specified in [URI-GEN]. + + scriptname = 1*ochar + ;; %-encoded version of UTF-8 representation + ;; of the script name. + ;; Note that ASCII characters such as " ", ";", + ;; "&", "=", "/" and "?" must be %-encoded + ;; as per rule specified in [URI-GEN]. + + ochar = unreserved / pct-encoded / sub-delims-sh / + ":" / "@" + ;; Same as [URI-GEN] 'pchar', + ;; but without ";", "&" and "=". + + unreserved = <defined in [URI-GEN]> + + pct-encoded = <defined in [URI-GEN]> + + + + +Melnikov & Martin Standards Track [Page 29] + +RFC 5804 ManageSieve July 2010 + + + sub-delims-sh = "!" / "$" / "'" / "(" / ")" / + "*" / "+" / "," + ;; Same as [URI-GEN] sub-delims, + ;; but without ";", "&" and "=". + + URI scheme semantics: + + A Sieve URL identifies a Sieve server or a Sieve script on a Sieve + server. The latter form is associated with the application/sieve + MIME type defined in [SIEVE]. There is no MIME type associated + with the former form of Sieve URI. + + The server form is used in the REFERRAL response code (see Section + 1.3) in order to designate another server where the client should + perform its operations. + + The script form allows to retrieve (GETSCRIPT), update + (PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the + named script; however, the most typical action would be to + retrieve the script. If the script name is empty (omitted), the + URI requests that the client lists available scripts using the + LISTSCRIPTS command. + + Encoding considerations: + + The script name and/or the owner, if present, is in UTF-8. Non-- + US-ASCII UTF-8 octets MUST be percent-encoded as described in + [URI-GEN]. US-ASCII characters such as " " (space), ";", "&", + "=", "/" and "?" MUST be %-encoded as described in [URI-GEN]. + Note that "&" and "?" are in this list in order to allow for + future extensions. + + Note that the empty owner (e.g., sieve://example.com//script) is + different from the missing owner (e.g., + sieve://example.com/script) and is reserved for referencing global + scripts. + + The user name (in the "authority" part), if present, is in UTF-8. + Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in + [URI-GEN]. + + Applications/protocols that use this URI scheme name: + ManageSieve [RFC5804] clients and servers. Clients that can store + user preferences in protocols such as [LDAP] or [ACAP]. + + Interoperability considerations: None. + + + + + +Melnikov & Martin Standards Track [Page 30] + +RFC 5804 ManageSieve July 2010 + + + Security considerations: + The <scriptname> part of a ManageSieve URL might potentially disclose + some confidential information about the author of the script or, + depending on a ManageSieve implementation, about configuration of the + mail system. The latter might be used to prepare for a more complex + attack on the mail system. + + Clients resolving ManageSieve URLs that wish to achieve data + confidentiality and/or integrity SHOULD use the STARTTLS command (if + supported by the server) before starting authentication, or use a + SASL mechanism, such as GSSAPI, that provides a confidentiality + security layer. + + Contact: Alexey Melnikov <alexey.melnikov@isode.com> + + Author/Change controller: IESG. + + References: This document and RFC 5228 [SIEVE]. + +4. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form (BNF) notation as specified in [ABNF]. This uses the ABNF core + rules as specified in Appendix A of the ABNF specification [ABNF]. + "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8]. + + Except as noted otherwise, all alphabetic characters are case- + insensitive. The use of upper- or lowercase characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B / + %x5D-7F + ;; any TEXT-CHAR except QUOTED-SPECIALS + + QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS + + QUOTED-SPECIALS = DQUOTE / "\" + + SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4 + ;; <UTF8-2>, <UTF8-3>, and <UTF8-4> + ;; are defined in [UTF-8]. + + ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E + ;; Any CHAR except ATOM-SPECIALS + + ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS + + + + +Melnikov & Martin Standards Track [Page 31] + +RFC 5804 ManageSieve July 2010 + + + NZDIGIT = %x31-39 + ;; 1-9 + + atom = 1*1024ATOM-CHAR + + iana-token = atom + ;; MUST be registered with IANA + + auth-type = DQUOTE auth-type-name DQUOTE + + auth-type-name = iana-token + ;; as defined in SASL [SASL] + + command = (command-any / command-auth / + command-nonauth) CRLF + ;; Modal based on state + + command-any = command-capability / command-logout / + command-noop + ;; Valid in all states + + command-auth = command-getscript / command-setactive / + command-listscripts / command-deletescript / + command-putscript / command-checkscript / + command-havespace / + command-renamescript / + command-unauthenticate + ;; Valid only in Authenticated state + + command-nonauth = command-authenticate / command-starttls + ;; Valid only when in Non-Authenticated + ;; state + + command-authenticate = "AUTHENTICATE" SP auth-type [SP string] + *(CRLF string) + + command-capability = "CAPABILITY" + + command-deletescript = "DELETESCRIPT" SP sieve-name + + command-getscript = "GETSCRIPT" SP sieve-name + + command-havespace = "HAVESPACE" SP sieve-name SP number + + command-listscripts = "LISTSCRIPTS" + + command-noop = "NOOP" [SP string] + + + + +Melnikov & Martin Standards Track [Page 32] + +RFC 5804 ManageSieve July 2010 + + + command-logout = "LOGOUT" + + command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script + + command-checkscript = "CHECKSCRIPT" SP sieve-script + + sieve-script = string + + command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP + new-sieve-name + + old-sieve-name = sieve-name + + new-sieve-name = sieve-name + + command-setactive = "SETACTIVE" SP active-sieve-name + + command-starttls = "STARTTLS" + + command-unauthenticate= "UNAUTHENTICATE" + + extend-token = atom + ;; MUST be defined by a Standards Track or + ;; IESG-approved experimental protocol + ;; extension + + extension-data = extension-item *(SP extension-item) + + extension-item = extend-token / string / number / + "(" [extension-data] ")" + + literal-c2s = "{" number "+}" CRLF *OCTET + ;; The number represents the number of + ;; octets. + ;; This type of literal can only be sent + ;; from the client to the server. + + literal-s2c = "{" number "}" CRLF *OCTET + ;; Almost identical to literal-c2s, + ;; but with no '+' character. + ;; The number represents the number of + ;; octets. + ;; This type of literal can only be sent + ;; from the server to the client. + + + + + + + +Melnikov & Martin Standards Track [Page 33] + +RFC 5804 ManageSieve July 2010 + + + number = (NZDIGIT *DIGIT) / "0" + ;; A 32-bit unsigned number + ;; with no extra leading zeros. + ;; (0 <= n < 4,294,967,296) + + number-str = string + ;; <number> encoded as a <string>. + + quoted = DQUOTE *1024QUOTED-CHAR DQUOTE + ;; limited to 1024 octets between the <">s + + resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA" + ["/" ("MAXSCRIPTS" / "MAXSIZE")] / + resp-code-sasl / + resp-code-referral / + "TRANSITION-NEEDED" / "TRYLATER" / + "ACTIVE" / "NONEXISTENT" / + "ALREADYEXISTS" / "WARNINGS" / + "TAG" SP string / + resp-code-ext + + resp-code-referral = "REFERRAL" SP sieveurl + + resp-code-sasl = "SASL" SP string + + resp-code-name = iana-token + ;; The response code name is hierarchical, + ;; separated by '/'. + ;; The response code name MUST NOT start + ;; with '/'. + + resp-code-ext = resp-code-name [SP extension-data] + ;; unknown response codes MUST be tolerated + ;; by the client. + + response = response-authenticate / + response-logout / + response-getscript / + response-setactive / + response-listscripts / + response-deletescript / + response-putscript / + response-checkscript / + response-capability / + response-havespace / + response-starttls / + response-renamescript / + response-noop / + + + +Melnikov & Martin Standards Track [Page 34] + +RFC 5804 ManageSieve July 2010 + + + response-unauthenticate + + response-authenticate = *(string CRLF) + ((response-ok [response-capability]) / + response-nobye) + ;; <response-capability> is REQUIRED if a + ;; SASL security layer was negotiated and + ;; MUST be omitted otherwise. + + response-capability = *(single-capability) response-oknobye + + single-capability = capability-name [SP string] CRLF + + capability-name = string + + ;; Note that literal-s2c is allowed. + + initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / + DQUOTE "SASL" DQUOTE SP sasl-mechs / + DQUOTE "SIEVE" DQUOTE SP sieve-extensions / + DQUOTE "MAXREDIRECTS" DQUOTE SP number-str / + DQUOTE "NOTIFY" DQUOTE SP notify-mechs / + DQUOTE "STARTTLS" DQUOTE / + DQUOTE "LANGUAGE" DQUOTE SP language / + DQUOTE "VERSION" DQUOTE SP version / + DQUOTE "OWNER" DQUOTE SP string + ;; Each capability conforms to + ;; the syntax for single-capability. + ;; Also, note that the capability name + ;; can be returned as either literal-s2c + ;; or quoted, even though only "quoted" + ;; string is shown above. + + version = ( DQUOTE "1.0" DQUOTE ) / version-ext + + version-ext = DQUOTE ver-major "." ver-minor DQUOTE + ; Future versions specified in updates + ; to this document. An increment to + ; the ver-major means a backward-incompatible + ; change to the protocol, e.g., "3.5" (ver-major "3") + ; is not backward-compatible with any "2.X" version. + ; Any version "Z.W" MUST be backward compatible + ; with any version "Z.Q", where Q < W. + ; For example, version "2.4" is backward compatible + ; with version "2.0", "2.1", "2.2", and "2.3". + + ver-major = number + + + + +Melnikov & Martin Standards Track [Page 35] + +RFC 5804 ManageSieve July 2010 + + + ver-minor = number + + sasl-mechs = string + ; Space-separated list of SASL mechanisms, + ; each SASL mechanism name complies with rules + ; specified in [SASL]. + ; Can be empty. + + sieve-extensions = string + ; Space-separated list of supported SIEVE extensions. + ; Can be empty. + + language = string + ; Contains <Language-Tag> from [RFC5646]. + + + notify-mechs = string + ; Space-separated list of URI schema parts + ; for supported notification [NOTIFY] methods. + ; MUST NOT be empty. + + response-deletescript = response-oknobye + + response-getscript = (sieve-script CRLF response-ok) / + response-nobye + + response-havespace = response-oknobye + + response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF) + response-oknobye + ;; ACTIVE may only occur with one sieve-name + + response-logout = response-oknobye + + response-unauthenticate= response-oknobye + ;; "NO" response can only be returned when + ;; the command is issued in a wrong state + ;; or has a wrong number of parameters + + response-ok = "OK" [SP "(" resp-code ")"] + [SP string] CRLF + ;; The string contains human-readable text + ;; encoded as UTF-8. + + response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"] + [SP string] CRLF + ;; The string contains human-readable text + ;; encoded as UTF-8. + + + +Melnikov & Martin Standards Track [Page 36] + +RFC 5804 ManageSieve July 2010 + + + response-oknobye = response-ok / response-nobye + + response-noop = response-ok + + response-putscript = response-oknobye + + response-checkscript = response-oknobye + + response-renamescript = response-oknobye + + response-setactive = response-oknobye + + response-starttls = (response-ok response-capability) / + response-nobye + + sieve-name = string + ;; See Section 1.6 for the full list of + ;; prohibited characters. + ;; Empty string is not allowed. + + active-sieve-name = string + ;; See Section 1.6 for the full list of + ;; prohibited characters. + ;; This is similar to <sieve-name>, but + ;; empty string is allowed and has a special + ;; meaning. + + string = quoted / literal-c2s / literal-s2c + ;; literal-c2s is only allowed when sent + ;; from the client to the server. + ;; literal-s2c is only allowed when sent + ;; from the server to the client. + ;; quoted is allowed in either direction. + +5. Security Considerations + + The AUTHENTICATE command uses SASL [SASL] to provide authentication + and authorization services. Integrity and privacy services can be + provided by [SASL] and/or [TLS]. When a SASL mechanism is used, the + security considerations for that mechanism apply. + + This protocol's transactions are susceptible to passive observers or + man-in-the-middle attacks that alter the data, unless the optional + encryption and integrity services of the SASL (via the AUTHENTICATE + command) and/or [TLS] (via the STARTTLS command) are enabled, or an + external security mechanism is used for protection. It may be useful + to allow configuration of both clients and servers to refuse to + transfer sensitive information in the absence of strong encryption. + + + +Melnikov & Martin Standards Track [Page 37] + +RFC 5804 ManageSieve July 2010 + + + If an implementation supports SASL mechanisms that are vulnerable to + passive eavesdropping attacks (such as [PLAIN]), then the + implementation MUST support at least one configuration where these + SASL mechanisms are not advertised or used without the presence of an + external security layer such as [TLS]. + + Some response codes returned on failed AUTHENTICATE command may + disclose whether or not the username is valid (e.g., TRANSITION- + NEEDED), so server implementations SHOULD provide the ability to + disable these features (or make them not conditional on a per-user + basis) for sites concerned about such disclosure. In the case of + ENCRYPT-NEEDED, if it is applied to all identities then no extra + information is disclosed, but if it is applied on a per-user basis it + can disclose information. + + A compromised or malicious server can use the TRANSITION-NEEDED + response code to force the client that is configured to use a + mechanism that does not disclose the user's password to the server + (e.g., Kerberos), to send the bare password to the server. Clients + SHOULD have the ability to disable the password transition feature, + or disclose that risk to the user and offer the user an option of how + to proceed. + +6. IANA Considerations + + IANA has reserved TCP port number 4190 for use with the ManageSieve + protocol described in this document. + + IANA has registered the "sieve" URI scheme defined in Section 3 of + this document. + + IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service + Names" registry. + + IANA has created a new registry for ManageSieve capabilities. The + registration template for ManageSieve capabilities is specified in + Section 6.1. ManageSieve protocol capabilities MUST be specified in + a Standards-Track or IESG-approved Experimental RFC. + + IANA has created a new registry for ManageSieve response codes. The + registration template for ManageSieve response codes is specified in + Section 6.3. ManageSieve protocol response codes MUST be specified + in a Standards-Track or IESG-approved Experimental RFC. + + + + + + + + +Melnikov & Martin Standards Track [Page 38] + +RFC 5804 ManageSieve July 2010 + + +6.1. ManageSieve Capability Registration Template + + To: iana@iana.org + Subject: ManageSieve Capability Registration + + Please register the following ManageSieve capability: + + Capability name: + Description: + Relevant publications: + Person & email address to contact for further information: + Author/Change controller: + +6.2. Registration of Initial ManageSieve Capabilities + + To: iana@iana.org + Subject: ManageSieve Capability Registration + + Please register the following ManageSieve capabilities: + + Capability name: IMPLEMENTATION + Description: Its value contains the name of the server + implementation and its version. + Relevant publications: this RFC, Section 1.7. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Capability name: SASL + Description: Its value contains a space-separated list of SASL + mechanisms supported by the server. + Relevant publications: this RFC, Sections 1.7 and 2.1. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Capability name: SIEVE + Description: Its value contains a space-separated list of supported + SIEVE extensions. + Relevant publications: this RFC, Section 1.7. Also [SIEVE]. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + + + +Melnikov & Martin Standards Track [Page 39] + +RFC 5804 ManageSieve July 2010 + + + Capability name: STARTTLS + Description: This capability is returned if the server supports TLS + (STARTTLS command). + Relevant publications: this RFC, Sections 1.7 and 2.2. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Capability name: NOTIFY + Description: This capability is returned if the server supports the + 'enotify' [NOTIFY] Sieve extension. + Relevant publications: this RFC, Section 1.7. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Capability name: MAXREDIRECTS + Description: This capability returns the limit on the number of + Sieve "redirect" actions a script can perform during a + single evaluation. The value is a non-negative number + represented as a ManageSieve string. + Relevant publications: this RFC, Section 1.7. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Capability name: LANGUAGE + Description: The language (<Language-Tag> from [RFC5646]) currently + used for human-readable error messages. + Relevant publications: this RFC, Section 1.7. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Capability name: OWNER + Description: Its value contains the UTF-8-encoded name of the + currently logged-in user ("authorization identity" + according to RFC 4422). + Relevant publications: this RFC, Section 1.7. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + + + + +Melnikov & Martin Standards Track [Page 40] + +RFC 5804 ManageSieve July 2010 + + + Capability name: VERSION + Description: This capability is returned if the server is compliant + with RFC 5804; i.e., that it supports RENAMESCRIPT, + CHECKSCRIPT, and NOOP commands. + Relevant publications: this RFC, Sections 2.11, 2.12, and 2.13. + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + +6.3. ManageSieve Response Code Registration Template + + To: iana@iana.org + Subject: ManageSieve Response Code Registration + + Please register the following ManageSieve response code: + + Response Code: + Arguments (use ABNF to specify syntax, or the word NONE if none + can be specified): + Purpose: + Published Specification(s): + Person & email address to contact for further information: + Author/Change controller: + +6.4. Registration of Initial ManageSieve Response Codes + + To: iana@iana.org + Subject: ManageSieve Response Code Registration + + Please register the following ManageSieve response codes: + + Response Code: AUTH-TOO-WEAK + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: This response code is returned in the NO response from + an AUTHENTICATE command. It indicates that site + security policy forbids the use of the requested + mechanism for the specified authentication identity. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + + + + +Melnikov & Martin Standards Track [Page 41] + +RFC 5804 ManageSieve July 2010 + + + Response Code: ENCRYPT-NEEDED + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: This response code is returned in the NO response from + an AUTHENTICATE command. It indicates that site + security policy requires the use of a strong + encryption mechanism for the specified authentication + identity and mechanism. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: QUOTA + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: If this response code is returned in the NO/BYE + response, it means that the command would have placed + the user above the site-defined quota constraints. If + this response code is returned in the OK response, it + can mean that the user is near its quota or that the + user exceeded its quota, but the server supports soft + quotas. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: QUOTA/MAXSCRIPTS + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: If this response code is returned in the NO/BYE + response, it means that the command would have placed + the user above the site-defined limit on the number of + Sieve scripts. If this response code is returned in + the OK response, it can mean that the user is near its + quota or that the user exceeded its quota, but the + server supports soft quotas. This response code is a + more specific version of the QUOTA response code. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + + + +Melnikov & Martin Standards Track [Page 42] + +RFC 5804 ManageSieve July 2010 + + + Response Code: QUOTA/MAXSIZE + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: If this response code is returned in the NO/BYE + response, it means that the command would have placed + the user above the site-defined maximum script size. + If this response code is returned in the OK response, + it can mean that the user is near its quota or that + the user exceeded its quota, but the server supports + soft quotas. This response code is a more specific + version of the QUOTA response code. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: REFERRAL + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): <sieveurl> + Purpose: This response code may be returned with a BYE result + from any command, and includes a mandatory parameter + that indicates what server to access to manage this + user's Sieve scripts. The server will be specified by + a Sieve URL (see Section 3). The scriptname portion + of the URL MUST NOT be specified. The client should + authenticate to the specified server and use it for + all further commands in the current session. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: SASL + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): <string> + Purpose: This response code can occur in the OK response to a + successful AUTHENTICATE command and includes the + optional final server response data from the server as + specified by [SASL]. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + + + +Melnikov & Martin Standards Track [Page 43] + +RFC 5804 ManageSieve July 2010 + + + Response Code: TRANSITION-NEEDED + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: This response code occurs in a NO response of an + AUTHENTICATE command. It indicates that the user name + is valid, but the entry in the authentication database + needs to be updated in order to permit authentication + with the specified mechanism. This is typically done + by establishing a secure channel using TLS, followed + by authenticating once using the [PLAIN] + authentication mechanism. The selected mechanism + SHOULD then work for authentications in subsequent + sessions. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: TRYLATER + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: A command failed due to a temporary server failure. + The client MAY continue using local information and + try the command later. This response code only make + sense when returned in a NO/BYE response. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: ACTIVE + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: A command failed because it is not allowed on the + active script, for example, DELETESCRIPT on the active + script. This response code only makes sense when + returned in a NO/BYE response. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + + + + + +Melnikov & Martin Standards Track [Page 44] + +RFC 5804 ManageSieve July 2010 + + + Response Code: NONEXISTENT + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: A command failed because the referenced script name + doesn't exist. This response code only makes sense + when returned in a NO/BYE response. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: ALREADYEXISTS + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: A command failed because the referenced script name + already exists. This response code only makes sense + when returned in a NO/BYE response. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: WARNINGS + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): NONE + Purpose: This response code MAY be returned by the server in + the OK response (but it might be returned with the NO/ + BYE response as well) and signals the client that even + though the script is syntactically valid, it might + contain errors not intended by the script writer. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + Response Code: TAG + Arguments (use ABNF to specify syntax, or the word NONE if none can + be specified): string + Purpose: This response code name is followed by a string + specified in the command that caused this response. + It is typically used for client state synchronization. + Published Specification(s): [RFC5804] + Person & email address to contact for further information: + Alexey Melnikov <alexey.melnikov@isode.com> + Author/Change controller: IESG. + + + + + + +Melnikov & Martin Standards Track [Page 45] + +RFC 5804 ManageSieve July 2010 + + +7. Internationalization Considerations + + The LANGUAGE capability (see Section 1.7) allows a client to discover + the current language used in all human-readable responses that might + be returned at the end of any OK/NO/BYE response. Human-readable + text in OK responses typically doesn't need to be shown to the user, + unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT + command that also contains the WARNINGS response code (Section 1.3). + Human-readable text from NO/BYE responses is intended be shown to the + user, unless the client can automatically handle failure of the + command that caused such a response. Clients SHOULD use response + codes (Section 1.3) for automatic error handling. Response codes MAY + also be used by the client to present error messages in a language + understood by the user, for example, if the LANGUAGE capability + doesn't return a language understood by the user. + + Note that the human-readable text from OK (WARNINGS) or NO/BYE + responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced + users that understand Sieve language. Such advanced users are often + sophisticated enough to be able to handle whatever language the + server is using, even if it is not their preferred language, and will + want to see error/warning text no matter what language the server + puts it in. + + A client that generates Sieve script automatically, for example, if + the script is generated without user intervention or from a UI that + presents an abstract list of conditions and corresponding actions, + SHOULD NOT present warning/error messages to the user, because the + user might not even be aware that the client is using Sieve + underneath. However, if the client has a debugging mode, such + warnings/errors SHOULD be available in the debugging mode. + + Note that this document doesn't provide a way to modify the currently + used language. It is expected that a future extension will address + that. + +8. Acknowledgements + + Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris + Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, + Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil + Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan + Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick + Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus + Westerlund, Tim Polk, and Julien Coloos for help with this document. + Special thank you to Phil Pennock for providing text for the NOOP + command, as well as finding various bugs in the document. + + + + +Melnikov & Martin Standards Track [Page 46] + +RFC 5804 ManageSieve July 2010 + + +9. References + +9.1. Normative References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November + 1997. + + [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for + Network Interchange", RFC 5198, March 2008. + + [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, + "Sieve Email Filtering: Extension for Notifications", + RFC 5435, January 2009. + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", BCP 18, RFC 2277, January 1998. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications + (IDNA)", RFC 3490, March 2003. + + [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol + (LDAP): Schema for User Applications", RFC 4519, June + 2006. + + [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying + Languages", BCP 47, RFC 5646, September 2009. + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + + + +Melnikov & Martin Standards Track [Page 47] + +RFC 5804 ManageSieve July 2010 + + + [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication + and Security Layer (SASL)", RFC 4422, June 2006. + + [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User + Names and Passwords", RFC 4013, February 2005. + + [SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N. + Williams, "Salted Challenge Response Authentication + Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC + 5802, July 2010. + + [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email + Filtering Language", RFC 5228, January 2008. + + [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", RFC 3454, + December 2002. + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, August + 2008. + + [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate Revocation + List (CRL) Profile", RFC 5280, May 2008. + + [X509-SRV] Santesson, S., "Internet X.509 Public Key + Infrastructure Subject Alternative Name for Expression + of Service Name", RFC 4985, August 2007. + +9.2. Informative References + + [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication + as a SASL Mechanism", RFC 2831, May 2000. + + [GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple + Authentication and Security Layer (SASL) Mechanism", + RFC 4752, November 2006. + + + + + +Melnikov & Martin Standards Track [Page 48] + +RFC 5804 ManageSieve July 2010 + + + [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension", + RFC 5463, March 2009. + + [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - + VERSION 4rev1", RFC 3501, March 2003. + + [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, + June 2006. + + [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and + Security Layer (SASL) Mechanism", RFC 4616, August + 2006. + +Authors' Addresses + + Alexey Melnikov (editor) + Isode Limited + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex TW12 2BX + UK + + EMail: Alexey.Melnikov@isode.com + + + Tim Martin + BeThereBeSquare, Inc. + 672 Haight st. + San Francisco, CA 94117 + USA + + Phone: +1 510 260-4175 + EMail: timmartin@alumni.cmu.edu + + + + + + + + + + + + + + + + + +Melnikov & Martin Standards Track [Page 49] +