tAdd sieve RFCs and fix example sieve script. - rohrpost - A commandline mail client to change the world as we see it.
(HTM) git clone git://r-36.net/rohrpost
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) LICENSE
---
(DIR) commit c1cd5dd02d6645c597a81f5f1efb681af9f59095
(DIR) parent c742105bf1e76f07544ee3d56300eff2b31934ca
(HTM) 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(-)
---
(DIR) diff --git a/proto/sieve.example b/proto/sieve.example
t@@ -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";
(DIR) diff --git a/proto/sieve/rfc3028.txt b/proto/sieve/rfc3028.txt
t@@ -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]
+
(DIR) diff --git a/proto/sieve/rfc3431.txt b/proto/sieve/rfc3431.txt
t@@ -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]
+
(DIR) diff --git a/proto/sieve/rfc5231.txt b/proto/sieve/rfc5231.txt
t@@ -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]
+
(DIR) diff --git a/proto/sieve/rfc5260.txt b/proto/sieve/rfc5260.txt
t@@ -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]
+
(DIR) diff --git a/proto/sieve/rfc5437.txt b/proto/sieve/rfc5437.txt
t@@ -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><juliet@example.com> 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]
+
(DIR) diff --git a/proto/sieve/rfc5804.txt b/proto/sieve/rfc5804.txt
t@@ -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]
+