draft-ietf-sieve-managesieve-00.txt   draft-ietf-sieve-managesieve-01.txt 
Sieve Working Group A. Melnikov, Ed. Sieve Working Group A. Melnikov, Ed.
Internet-Draft Isode Limited Internet-Draft Isode Limited
Intended status: Standards Track T. Martin Intended status: Standards Track T. Martin
Expires: April 23, 2009 BeThereBeSquare Inc. Expires: May 5, 2009 BeThereBeSquare Inc.
October 20, 2008 November 1, 2008
A Protocol for Remotely Managing Sieve Scripts A Protocol for Remotely Managing Sieve Scripts
draft-ietf-sieve-managesieve-00 draft-ietf-sieve-managesieve-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2009. This Internet-Draft will expire on May 5, 2009.
Abstract Abstract
Sieve scripts allow users to filter incoming email. Message stores Sieve scripts allow users to filter incoming email. Message stores
are commonly sealed servers so users cannot log into them, yet users are commonly sealed servers so users cannot log into them, yet users
must be able to update their scripts on them. This document must be able to update their scripts on them. This document
describes a protocol "ManageSieve" for securely managing Sieve describes a protocol "ManageSieve" for securely managing Sieve
scripts on a remote server. This protocol allows a user to have scripts on a remote server. This protocol allows a user to have
multiple scripts, and also alerts a user to syntactically flawed multiple scripts, and also alerts a user to syntactically flawed
scripts. scripts.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Response Codes . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Response Codes . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Active Script . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Active Script . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6. Script Names . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Script Names . . . . . . . . . . . . . . . . . . . . . . . 7
1.7. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8 1.7. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8
1.8. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 9 1.8. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 10 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 11
2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 15 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 16
2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 15 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 16
2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 16 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 17
2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 19 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 19
2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 19 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 20
2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 19 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 20
2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 20 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 20
2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 21 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 22
2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 22 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 23
2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 23
2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 23 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 24
2.11. Recommended extensions . . . . . . . . . . . . . . . . . . 23 2.11. Recommended extensions . . . . . . . . . . . . . . . . . . 24
2.11.1. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 24 2.11.1. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 25
2.11.2. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 25 2.11.2. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 26
2.11.3. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 25 2.11.3. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 27
2.11.4. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 27
3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 25
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 27 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 28
5. Security Considerations . . . . . . . . . . . . . . . . . 33 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 33 5. Security Considerations . . . . . . . . . . . . . . . . . 35
6.1. Manage Sieve Capability Registration Template . . . . . . 34
6.2. Registration of Initial Manage Sieve capabilities . . . . 34
6.3. Manage Sieve Response Code Registration Template . . . . . 36
6.4. Registration of Initial Manage Sieve Response Codes . . . 36
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 36
6.1. Manage Sieve Capability Registration Template . . . . . . 37
6.2. Registration of Initial Manage Sieve capabilities . . . . 37
6.3. Manage Sieve Response Code Registration Template . . . . . 39
6.4. Registration of Initial Manage Sieve Response Codes . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . 41 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . 44
8.2. Informative References . . . . . . . . . . . . . . . . . . 43 8.1. Normative References . . . . . . . . . . . . . . . . . . . 44
8.2. Informative References . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . 48
1. Introduction 1. Introduction
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
skipping to change at page 6, line 50 skipping to change at page 6, line 50
ALREADYEXISTS ALREADYEXISTS
A command failed because the references script name already exists. A command failed because the references script name already exists.
This response code only makes sense when returned in a NO/BYE This response code only makes sense when returned in a NO/BYE
response. response.
TAG TAG
This response code name is followed by a string specified in the This response code name is followed by a string specified in the
command. See Section 2.11.2 for a possible use case. command. See Section 2.11.3 for a possible use case.
WARNINGS WARNINGS
This response code MAY be returned by the server in the OK response 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 (but it might be returned with the NO/BYE response as well) and
signals the client that even though the script is syntactically signals the client that even though the script is syntactically
valid, it might contain errors not indended by the script writer. valid, it might contain errors not indended by the script writer.
This response code is typically returned in response to PUTSCRIPT This response code is typically returned in response to PUTSCRIPT
command. A client seeing such response code SHOULD present the and/or CHECKSCRIPT commands. A client seeing such response code
returned warning text to the user. SHOULD present the returned warning text to the user.
1.4. Active Script 1.4. Active Script
A user may have multiple Sieve scripts on the server, yet only one 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 script may be used for filtering of incoming messages. This is the
active script. Users may have zero or one active scripts and MUST active script. Users may have zero or one active scripts and MUST
use the SETACTIVE command described below for changing the active use the SETACTIVE command described below for changing the active
script or disabling Sieve processing. For example, a user may have script or disabling Sieve processing. For example, a user may have
an everyday script they normally use and a special script they use an everyday script they normally use and a special script they use
when they go on vacation. Users can change which script is being when they go on vacation. Users can change which script is being
skipping to change at page 8, line 32 skipping to change at page 8, line 32
Clients MAY request the capabilities at a later time by issuing the Clients MAY request the capabilities at a later time by issuing the
CAPABILITY command described later. The capabilities consist of a CAPABILITY command described later. The capabilities consist of a
series of lines each with one or two strings. The first string is series of lines each with one or two strings. The first string is
the name of the capability, which is case-insensitive. The second the name of the capability, which is case-insensitive. The second
optional string is the value associated with that capability. Order optional string is the value associated with that capability. Order
of capabilities is arbitrary, but each capability name can appear at of capabilities is arbitrary, but each capability name can appear at
most once. most once.
The following capabilities are defined in this document: The following capabilities are defined in this document:
IMPLEMENTATION - Name of implementation and version. 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 SASL - List of SASL mechanisms supported by the server, each
separated by a space. This list can be empty if and only if STARTTLS 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 is also advertised. This means that the client must negotiate TLS
encryption with STARTTLS first, at which point the SASL capability encryption with STARTTLS first, at which point the SASL capability
will list a non empty list of SASL mechanisms. will list a non empty list of SASL mechanisms.
SIEVE - List of space separated Sieve extensions (as listed in Sieve SIEVE - List of space separated Sieve extensions (as listed in Sieve
"require" action [SIEVE]) supported by the Sieve engine. "require" action [SIEVE]) supported by the Sieve engine. This
capability MUST always be returned by the server.
STARTTLS - If TLS [TLS] is supported by this implementation. Before STARTTLS - If TLS [TLS] is supported by this implementation. Before
advertising this capability a server MUST verify to the best of its advertising this capability a server MUST verify to the best of its
ability that TLS can be successfully negotiated by a client with ability that TLS can be successfully negotiated by a client with
common cipher suites. Specifically, a server should verify that a common cipher suites. Specifically, a server should verify that a
server certificate has be installed and that the TLS subsystem has server certificate has be installed and that the TLS subsystem has
successfully initialized. successfully initialized.
MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect" MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
actions a script can perform during a single evaluation. Note, that actions a script can perform during a single evaluation. Note, that
skipping to change at page 9, line 18 skipping to change at page 9, line 21
NOTIFY - A space separated list of URI schema parts for supported NOTIFY - A space separated list of URI schema parts for supported
notification methods. This capability MUST be specified if the Sieve notification methods. This capability MUST be specified if the Sieve
implementation supports the "enotify" extension [NOTIFY]. implementation supports the "enotify" extension [NOTIFY].
LANGUAGE - The language (<Language-Tag> from [RFC4646]) currently LANGUAGE - The language (<Language-Tag> from [RFC4646]) currently
used for human readable error messages. If this capability is not used for human readable error messages. If this capability is not
returned, the "i-default" [RFC2277] language is assumed. Note that returned, the "i-default" [RFC2277] language is assumed. Note that
the current language MAY be per-user configurable (i.e. it MAY change the current language MAY be per-user configurable (i.e. it MAY change
after authentication). 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.
Section 2.11 defines some additional ManageSieve extensions and their Section 2.11 defines some additional ManageSieve extensions and their
respective capabilities. respective capabilities.
A server implementation MUST return SIEVE and IMPLEMENTATION A server implementation MUST return SIEVE and IMPLEMENTATION
capabilities. capabilities.
A client implementation MUST ignore any listed capabilities that it A client implementation MUST ignore any listed capabilities that it
does not understand. does not understand.
Example: Example:
S: "IMPlemENTATION" "Example1 ManageSieved v001" S: "IMPlemENTATION" "Example1 ManageSieved v001"
S: "SASl" "DIGEST-MD5 GSSAPI" S: "SASl" "DIGEST-MD5 GSSAPI"
S: "SIeVE" "fileinto vacation" S: "SIeVE" "fileinto vacation"
S: "StaRTTLS" S: "StaRTTLS"
S: "NOTIFY" "xmpp mailto" S: "NOTIFY" "xmpp mailto"
S: "MAXREdIRECTS" "5" S: "MAXREdIRECTS" "5"
S: OK 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: "StaRTTLS"
S: "NOTIFY" "xmpp mailto"
S: "OWNER" "alexey@example.com"
S: "MAXREdIRECTS" "5"
S: OK
1.8. Link Level 1.8. Link Level
The ManageSieve protocol assumes a reliable data stream such as that The ManageSieve protocol assumes a reliable data stream such as that
provided by TCP. When TCP is used, a ManageSieve server typically provided by TCP. When TCP is used, a ManageSieve server typically
listens on port 2000. [[anchor6: IANA registration of port 2000 is listens on port 2000. [[anchor6: IANA registration of port 2000 is
pending.]] pending.]]
Before opening the TCP connection, the ManageSieve client first MUST Before opening the TCP connection, the ManageSieve client first MUST
resolve the Domain Name System (DNS) hostname associated with the resolve the Domain Name System (DNS) hostname associated with the
receiving entity and determine the appropriate TCP port for receiving entity and determine the appropriate TCP port for
skipping to change at page 10, line 26 skipping to change at page 11, line 5
2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
IPv6 address record resolution to determine the IP address, where IPv6 address record resolution to determine the IP address, where
the port used is the default ManageSieve port of 2000. the port used is the default ManageSieve port of 2000.
2. Commands 2. Commands
This section and its subsections describes valid ManageSieve This section and its subsections describes valid ManageSieve
commands. Upon initial connection to the server the client's session commands. Upon initial connection to the server the client's session
is in non-authenticated state. Prior to successful authentication is in non-authenticated state. Prior to successful authentication
only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see only the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT and NOOP (see
Section 2.11.2) commands are valid. ManageSieve extensions MAY Section 2.11.3) commands are valid. ManageSieve extensions MAY
define other commands which are valid in non-authenticated state. define other commands which are valid in non-authenticated state.
Servers MUST reject all other commands with a NO response. Clients Servers MUST reject all other commands with a NO response. Clients
may pipeline commands (send more than one command at a time without may pipeline commands (send more than one command at a time without
waiting for completion of the first command ). However, a group of waiting for completion of the first command ). However, a group of
commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS commands sent together MUST NOT have an AUTHENTICATE (*), a STARTTLS
or a HAVESPACE command anywhere but the last command in the list. or a HAVESPACE command anywhere but the last command in the list.
(*) - The only exception to this rule is when the AUTHENTICATE (*) - The only exception to this rule is when the AUTHENTICATE
command contains an initial response for a SASL mechanism that allows command contains an initial response for a SASL mechanism that allows
clients to send data first, the mechanism is known to complete in one clients to send data first, the mechanism is known to complete in one
skipping to change at page 11, line 43 skipping to change at page 12, line 21
The service name specified by this protocol's profile of SASL is The service name specified by this protocol's profile of SASL is
"sieve". "sieve".
Reauthentication is not supported by ManageSieve protocol's profile Reauthentication is not supported by ManageSieve protocol's profile
of SASL. I.e. after a successfully completed AUTHENTICATE command, of SASL. I.e. after a successfully completed AUTHENTICATE command,
no more AUTHENTICATE commands may be issued in the same session. no more AUTHENTICATE commands may be issued in the same session.
After a successful AUTHENTICATE command completes, a server MUST After a successful AUTHENTICATE command completes, a server MUST
reject any further AUTHENTICATE commands with a NO reply. However reject any further AUTHENTICATE commands with a NO reply. However
note that a server may implement UNAUTHENTICATE extension described note that a server may implement UNAUTHENTICATE extension described
in Section 2.11.3. in Section 2.11.4.
If a security layer is negotiated through the SASL authentication If a security layer is negotiated through the SASL authentication
exchange, it takes effect immediately following the CRLF that exchange, it takes effect immediately following the CRLF that
concludes the successful authentication exchange for the client, and concludes the successful authentication exchange for the client, and
the CRLF of the OK response for the server. the CRLF of the OK response for the server.
When a security layer takes effect, the ManageSieve protocol is reset When a security layer takes effect, the ManageSieve protocol is reset
to the initial state (the state in ManageSieve after a client has to the initial state (the state in ManageSieve after a client has
connected to the server). The server MUST discard any knowledge connected to the server). The server MUST discard any knowledge
obtained from the client which was not obtained from the SASL (or obtained from the client which was not obtained from the SASL (or
skipping to change at page 13, line 7 skipping to change at page 13, line 33
NEEDED or TRANSITION-NEEDED. See Section 1.3 for detailed NEEDED or TRANSITION-NEEDED. See Section 1.3 for detailed
description of the relevant conditions. description of the relevant conditions.
To ensure interoperability, client and server implementations of this To ensure interoperability, client and server implementations of this
extension MUST implement the [SCRAM] SASL mechanism. extension MUST implement the [SCRAM] SASL mechanism.
Implementations MAY advertise the ANONYMOUS SASL mechanism Implementations MAY advertise the ANONYMOUS SASL mechanism
[SASL-ANON]. This indicates that the server supports ANONYMOUS SIEVE [SASL-ANON]. This indicates that the server supports ANONYMOUS SIEVE
script syntax verification. Only the CAPABILITY, PUTSCRIPT and script syntax verification. Only the CAPABILITY, PUTSCRIPT and
LOGOUT commands are available to the anonymous user. All other LOGOUT commands are available to the anonymous user. All other
commands MUST give NO responses. Furthermore the PUTSCRIPT command commands defined in the base ManageSieve protocol MUST give NO
MUST NOT persistently store any data. In this mode a positive responses, however ManageSieve extensions MAY allow other commands in
response to the PUTSCRIPT command indicates that the given script the ANONYMOUS Sieve script verification mode. Furthermore the
does not have any syntax errors. PUTSCRIPT command MUST NOT persistently store any data. In this mode
a positive response to the PUTSCRIPT command indicates that the given
script does not have any syntax errors.
Examples (Note that long lines are folded for readability and are not Examples (Note that long lines are folded for readability and are not
part of protocol exchange): part of protocol exchange):
S: "IMPLEMENTATION" "Example1 ManageSieved v001" S: "IMPLEMENTATION" "Example1 ManageSieved v001"
S: "SASL" "DIGEST-MD5 GSSAPI" S: "SASL" "DIGEST-MD5 GSSAPI"
S: "SIEVE" "fileinto vacation" S: "SIEVE" "fileinto vacation"
S: "STARTTLS" S: "STARTTLS"
S: OK S: OK
C: Authenticate "DIGEST-MD5" C: Authenticate "DIGEST-MD5"
skipping to change at page 20, line 38 skipping to change at page 21, line 21
the script which is already active. The SETACTIVE command is used to the script which is already active. The SETACTIVE command is used to
mark a script as active. mark a script as active.
When submitting large scripts clients SHOULD use the HAVESPACE When submitting large scripts clients SHOULD use the HAVESPACE
command beforehand to query if the server is willing to accept a command beforehand to query if the server is willing to accept a
script of that size. script of that size.
The server MUST check the submitted script for syntactic validity, The server MUST check the submitted script for syntactic validity,
which includes checking that all Sieve extensions mentioned in Sieve which includes checking that all Sieve extensions mentioned in Sieve
script "require" statement(s) are supported by the Sieve interpreter. 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 If the script fails this test the server MUST reply with a NO
response. Any script that fails the validity test MUST NOT be stored 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 on the server. The message given with a NO response MUST be human
readable and SHOULD contain a specific error message giving the line readable and SHOULD contain a specific error message giving the line
number of the first error. Implementors should strive to produce number of the first error. Implementors should strive to produce
helpful error messages similar to those given by programming language helpful error messages similar to those given by programming language
compilers. Client implementations should note that this may be a compilers. Client implementations should note that this may be a
multiline literal string with more than one error message separated multiline literal string with more than one error message separated
by CRLFs. The human readable message is in the language returned in by CRLFs. The human readable message is in the language returned in
the latest LANGUAGE capability (or in "i-default", see Section 1.7), the latest LANGUAGE capability (or in "i-default", see Section 1.7),
skipping to change at page 24, line 5 skipping to change at page 25, line 5
S: No (ACTIVE) "You may not delete an active script" S: No (ACTIVE) "You may not delete an active script"
2.11. Recommended extensions 2.11. Recommended extensions
This Section defines several extensions support for which is This Section defines several extensions support for which is
RECOMMENDED. RECOMMENDED.
The RENAME extension (advertised as the "RENAME" capability with no The RENAME extension (advertised as the "RENAME" capability with no
parameters) defines a new RENAMESCRIPT command. parameters) defines a new RENAMESCRIPT command.
The CHECKSCRIPT extension (advertised as the "CHECKSCRIPT" capability
with no parameters) defines a new CHECKSCRIPT command.
The NOOP extension (advertised as the "NOOP" capability with no The NOOP extension (advertised as the "NOOP" capability with no
parameters) defines a new NOOP command. parameters) defines a new NOOP command.
The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE" The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE"
capability with no parameters) defines a new UNAUTHENTICATE command, capability with no parameters) defines a new UNAUTHENTICATE command,
which allows a client to return the server to non-authenticated which allows a client to return the server to non-authenticated
state. state.
2.11.1. RENAMESCRIPT Command 2.11.1. RENAMESCRIPT Command
skipping to change at page 24, line 48 skipping to change at page 26, line 4
whether to abort the operation, to replace the script (by issuing whether to abort the operation, to replace the script (by issuing
the DELETESCRIPT <newname> after that) or to chose a different the DELETESCRIPT <newname> after that) or to chose a different
name. name.
2. Download the old script with GETSCRIPT <oldname>. 2. Download the old script with GETSCRIPT <oldname>.
3. Upload the old script with the new name: PUTSCRIPT <newname>. 3. Upload the old script with the new name: PUTSCRIPT <newname>.
4. If the old script was active (as reported by LISTSCRIPTS in step 4. If the old script was active (as reported by LISTSCRIPTS in step
1), then make the new script active: SETACTIVE <newname> 1), then make the new script active: SETACTIVE <newname>
5. Delete the old script: DELETESCRIPT <oldname> 5. Delete the old script: DELETESCRIPT <oldname>
Note that these steps don't describe how to handle various other Note that these steps don't describe how to handle various other
error conditions (for example NO response containing QUOTA response error conditions (for example NO response containing QUOTA response
code in step 3). Error handling is left as an excercise for the code in step 3). Error handling is left as an excercise for the
reader. reader.
2.11.2. NOOP Command 2.11.2. 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 case
the 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 indended by the script writer. A
client seeing such response code SHOULD present the message to the
user.
The CHECKSCRIPT command is available in the ANONYMOUS Sieve script
verification mode.
2.11.3. NOOP Command
Arguments: String - tag to echo back (optional) Arguments: String - tag to echo back (optional)
The NOOP command does nothing, beyond returning a response to the The NOOP command does nothing, beyond returning a response to the
client. It may be used by clients for protocol re-synchronisation or client. It may be used by clients for protocol re-synchronisation or
to reset any inactivity auto-logout timer on the server. to reset any inactivity auto-logout timer on the server.
The NOOP command is available in the ANONYMOUS Sieve script
verification mode.
The response to the NOOP command is always OK, followed by the TAG The response to the NOOP command is always OK, followed by the TAG
response code together with the supplied string; if no string was response code together with the supplied string; if no string was
supplied in the NOOP command, the TAG response code MUST NOT be supplied in the NOOP command, the TAG response code MUST NOT be
included. included.
Older servers may not understand the NOOP client and robust clients Older servers may not understand the NOOP client and robust clients
SHOULD be prepared to receive a NO response. SHOULD be prepared to receive a NO response.
Examples: Examples:
C: NOOP C: NOOP
S: OK "NOOP completed" S: OK "NOOP completed"
C: NOOP "STARTTLS-SYNC-42" C: NOOP "STARTTLS-SYNC-42"
S: OK (TAG {16} S: OK (TAG {16}
S: STARTTLS-SYNC-42) "Done" S: STARTTLS-SYNC-42) "Done"
2.11.3. UNAUTHENTICATE Command 2.11.4. UNAUTHENTICATE Command
The UNAUTHENTICATE command returns the server to the non- The UNAUTHENTICATE command returns the server to the non-
authenticated state. It doesn't affect any previously established authenticated state. It doesn't affect any previously established
TLS [TLS] or SASL (Section 2.1) security layer. TLS [TLS] or SASL (Section 2.1) security layer.
The UNAUTHENTICATE command is only valid in authenticated state. If The UNAUTHENTICATE command is only valid in authenticated state. If
issued in a wrong state, the server MUST reject it with a NO issued in a wrong state, the server MUST reject it with a NO
response. response.
The UNAUTHENTICATE command has no parameters. The UNAUTHENTICATE command has no parameters.
skipping to change at page 26, line 17 skipping to change at page 28, line 22
Described using ABNF [ABNF] and ABNF entities from [URI-GEN]. Described using ABNF [ABNF] and ABNF entities from [URI-GEN].
sieveurl = sieveurl-server / sieveurl-list-scripts / sieveurl = sieveurl-server / sieveurl-list-scripts /
sieveurl-script sieveurl-script
sieveurl-server = "sieve://" authority sieveurl-server = "sieve://" authority
sieveurl-list-scripts = "sieve://" [ authority ] ["/"] sieveurl-list-scripts = "sieve://" [ authority ] ["/"]
sieveurl-script = "sieve://" [ authority ] "/" scriptname sieveurl-script = "sieve://" [ authority ] "/"
[owner "/"] scriptname
scriptname = 1*pchar sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
uchar = unreserved / pct-encoded / sub-delims-sh
;; Same as [URI-GEN]
;; 'unreserved / pct-encoded / sub-delims',
;; but without ";", "&" and "=".
ochar = uchar / ":" / "@"
;; Same as [URI-GEN] 'pchar'
;; but without ";", "&" and "=".
owner = 1*ochar
;; %-encoded version of [IMAP4] authorization
;; identity (owner) or "userid".
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" MUST be %-encoded.
scriptname = 1*ochar
;; %-encoded version of UTF-8 representation
;; of the script name.
;; Note that ASCII characters such as " ", ";",
;; "&", "=", "/" and "?" MUST be %-encoded.
URI scheme semantics: URI scheme semantics:
A Sieve URL identifies a Sieve server or a Sieve script on a Sieve A Sieve URL identifies a Sieve server or a Sieve script on a Sieve
server. The latter form is associated with the application/sieve server. The latter form is associated with the application/sieve
MIME type defined in [SIEVE]. There is no MIME type associated MIME type defined in [SIEVE]. There is no MIME type associated
with the former form of Sieve URI. with the former form of Sieve URI.
The server form is used in the REFERRAL response code in order to The server form is used in the REFERRAL response code in order to
designate another server where the client should perform its designate another server where the client should perform its
operations. operations.
The script form allows to retrieve (GETSCRIPT), update The script form allows to retrieve (GETSCRIPT), update
(PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the (PUTSCRIPT), delete (DELETESCRIPT) or activate (SETACTIVE) the
named script, however the most typical action would be to retrieve named script, however the most typical action would be to retrieve
the script. If the script name is empty (omitted), the URI the script. If the script name is empty (omitted), the URI
requests that the client lists available scripts using the requests that the client lists available scripts using the
LISTSCRIPTS command. LISTSCRIPTS command.
Encoding considerations: The script name, if present, is in UTF-8. Encoding considerations: The script name or the owner, if present, is
Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in 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]. [URI-GEN].
The user name (in the "authority" part), if present, is in UTF-8. 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 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in
[URI-GEN]. [URI-GEN].
Applications/protocols that use this URI scheme name: Applications/protocols that use this URI scheme name:
ManageSieve [RFC XXXX] clients and servers. Clients that can store ManageSieve [RFC XXXX] clients and servers. Clients that can store
user preferences in protocols such as [LDAP] or [ACAP]. user preferences in protocols such as [LDAP] or [ACAP].
Interoperability considerations: None. Interoperability considerations: None.
Security considerations: Security considerations:
The <scriptname> part of a ManageSieve URL might potentially disclose The <scriptname> part of a ManageSieve URL might potentially disclose
some confidential information about the author of the script or, some confidential information about the author of the script or,
depending on a ManageSieve implementation, about configuration of the depending on a ManageSieve implementation, about configuration of the
mail server. The latter might be used to prepare for a more complex mail system. The latter might be used to prepare for a more complex
attack on the mail system. attack on the mail system.
Clients resolving ManageSieve URLs that wish to achieve data Clients resolving ManageSieve URLs that wish to achieve data
confidentiality and/or integrity SHOULD use the STARTTLS command (if confidentiality and/or integrity SHOULD use the STARTTLS command (if
supported by the server) before starting authentication, or use a supported by the server) before starting authentication, or use a
SASL mechanism, such as GSSAPI, that provides a confidentiality SASL mechanism, such as GSSAPI, that provides a confidentiality
security layer. security layer.
Contact: Alexey Melnikov <alexey.melnikov@isode.com> Contact: Alexey Melnikov <alexey.melnikov@isode.com>
skipping to change at page 28, line 21 skipping to change at page 31, line 4
;; MUST be registered with IANA ;; MUST be registered with IANA
auth-type = DQUOTE auth-type-name DQUOTE auth-type = DQUOTE auth-type-name DQUOTE
auth-type-name = iana-token auth-type-name = iana-token
;; as defined in SASL [SASL] ;; as defined in SASL [SASL]
command = (command-any / command-auth / command = (command-any / command-auth /
command-nonauth) CRLF command-nonauth) CRLF
;; Modal based on state ;; Modal based on state
command-any = command-capability / command-logout / command-any = command-capability / command-logout /
command-noop command-noop
;; Valid in all states ;; Valid in all states
command-auth = command-getscript / command-setactive / command-auth = command-getscript / command-setactive /
command-listscripts / command-deletescript / command-listscripts / command-deletescript /
command-putscript / command-putscript / command-checkscript /
command-havespace / / command-havespace / /
command-renamescript / command-renamescript /
command-unauthenticate command-unauthenticate
;; Valid only in Authenticated state ;; Valid only in Authenticated state
command-nonauth = command-authenticate / command-starttls command-nonauth = command-authenticate / command-starttls
;; Valid only when in Non-Authenticated ;; Valid only when in Non-Authenticated
;; state ;; state
command-authenticate = "AUTHENTICATE" SP auth-type [SP string] command-authenticate = "AUTHENTICATE" SP auth-type [SP string]
skipping to change at page 29, line 4 skipping to change at page 31, line 34
command-deletescript = "DELETESCRIPT" SP sieve-name command-deletescript = "DELETESCRIPT" SP sieve-name
command-getscript = "GETSCRIPT" SP sieve-name command-getscript = "GETSCRIPT" SP sieve-name
command-havespace = "HAVESPACE" SP sieve-name SP number command-havespace = "HAVESPACE" SP sieve-name SP number
command-listscripts = "LISTSCRIPTS" command-listscripts = "LISTSCRIPTS"
command-noop = "NOOP" [SP string] command-noop = "NOOP" [SP string]
command-logout = "LOGOUT" command-logout = "LOGOUT"
command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
command-checkscript = "CHECKSCRIPT" SP sieve-script
sieve-script = string sieve-script = string
command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
new-sieve-name new-sieve-name
old-sieve-name = sieve-name old-sieve-name = sieve-name
new-sieve-name = sieve-name new-sieve-name = sieve-name
command-setactive = "SETACTIVE" SP sieve-name command-setactive = "SETACTIVE" SP active-sieve-name
command-starttls = "STARTTLS" command-starttls = "STARTTLS"
command-unauthenticate= "UNAUTHENTICATE" command-unauthenticate= "UNAUTHENTICATE"
extend-token = atom extend-token = atom
;; MUST be defined by a standards track or ;; MUST be defined by a standards track or
;; IESG approved experimental protocol ;; IESG approved experimental protocol
;; extension ;; extension
extension-data = extension-item *(SP extension-item) extension-data = extension-item *(SP extension-item)
skipping to change at page 30, line 39 skipping to change at page 33, line 23
;; unknown response codes MUST be tolerated ;; unknown response codes MUST be tolerated
;; by the client. ;; by the client.
response = response-authenticate / response = response-authenticate /
response-logout / response-logout /
response-getscript / response-getscript /
response-setactive / response-setactive /
response-listscripts / response-listscripts /
response-deletescript / response-deletescript /
response-putscript / response-putscript /
response-checkscript /
response-capability / response-capability /
response-havespace / response-havespace /
response-starttls / response-starttls /
response-renamescript / response-renamescript /
response-noop / response-noop /
response-unauthenticate response-unauthenticate
response-authenticate = *(string CRLF) response-authenticate = *(string CRLF)
((response-ok [response-capability]) / ((response-ok [response-capability]) /
response-nobye) response-nobye)
skipping to change at page 31, line 15 skipping to change at page 33, line 48
response-capability = *(single-capability) response-oknobye response-capability = *(single-capability) response-oknobye
single-capability = capability-name [SP string] CRLF single-capability = capability-name [SP string] CRLF
capability-name = string capability-name = string
;; Note that literal-s2c is allowed. ;; Note that literal-s2c is allowed.
initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string / initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
DQUOTE "SASL" DQUOTE SP sasl-mechs / DQUOTE "SASL" DQUOTE SP sasl-mechs /
DQUOTE "SIEVE" DQUOTE SP sieve-extensions / DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
DQUOTE "MAXREDIRECTS" DQUOTE SP number-str DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
DQUOTE "NOTIFY" DQUOTE SP notify-mechs / DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
DQUOTE "STARTTLS" DQUOTE / DQUOTE "STARTTLS" DQUOTE /
DQUOTE "LANGUAGE" DQUOTE SP language / DQUOTE "LANGUAGE" DQUOTE SP language /
DQUOTE "RENAME" DQUOTE / DQUOTE "RENAME" DQUOTE /
DQUOTE "NOOP" DQUOTE DQUOTE "CHECKSCRIPT" DQUOTE /
DQUOTE "NOOP" DQUOTE /
DQUOTE "OWNER" DQUOTE SP string
;; Each capability conforms to ;; Each capability conforms to
;; the syntax for single-capability. ;; the syntax for single-capability.
;; Also note that the capability name ;; Also note that the capability name
;; can be returned as either literal-s2c ;; can be returned as either literal-s2c
;; or quoted, even though only "quoted" ;; or quoted, even though only "quoted"
;; string is shown above. ;; string is shown above.
sasl-mechs = string sasl-mechs = string
; space separated list of SASL mechanisms, ; space separated list of SASL mechanisms,
; each SASL mechanism name complies with rules ; each SASL mechanism name complies with rules
skipping to change at page 32, line 31 skipping to change at page 35, line 19
[SP string] CRLF [SP string] CRLF
;; The string contains human readable text ;; The string contains human readable text
;; encoded as UTF-8. ;; encoded as UTF-8.
response-oknobye = response-ok / response-nobye response-oknobye = response-ok / response-nobye
response-noop = response-ok response-noop = response-ok
response-putscript = response-oknobye response-putscript = response-oknobye
response-checkscript = response-oknobye
response-renamescript = response-oknobye response-renamescript = response-oknobye
response-setactive = response-oknobye response-setactive = response-oknobye
response-starttls = (response-ok response-capability) / response-starttls = (response-ok response-capability) /
response-nobye response-nobye
sieve-name = string sieve-name = string
;; See Section 1.6 for the full list of ;; See Section 1.6 for the full list of
;; prohibited characters. ;; 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 string = quoted / literal-c2s / literal-s2c
;; literal-c2s is only allowed when sent ;; literal-c2s is only allowed when sent
;; from the client to the server. ;; from the client to the server.
;; literal-s2c is only allowed when sent ;; literal-s2c is only allowed when sent
;; from the server to the client. ;; from the server to the client.
;; quoted is allowed in either direction. ;; quoted is allowed in either direction.
5. Security Considerations 5. Security Considerations
skipping to change at page 35, line 35 skipping to change at page 38, line 34
Description: This capability is returned if server supports Description: This capability is returned if server supports
'enotify' [NOTIFY] Sieve extension. 'enotify' [NOTIFY] Sieve extension.
Relevant publications: this RFC, Section 1.7. Relevant publications: this RFC, Section 1.7.
Person & email address to contact for further information: Alexey Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com> Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG. Author/Change controller: IESG.
Capability name: OWNER
Description: Its value contains 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.
Capability name: RENAME Capability name: RENAME
Description: This capability is returned if the server supports Description: This capability is returned if the server supports
the RENAMESCRIPT command. the RENAMESCRIPT command.
Relevant publications: this RFC, Section 2.11.1. Relevant publications: this RFC, Section 2.11.1.
Person & email address to contact for further information: Alexey Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com> Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG. Author/Change controller: IESG.
Capability name: CHECKSCRIPT
Description: This capability is returned if the server supports
the CHECKSCRIPT command.
Relevant publications: this RFC, Section 2.11.1.
Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG.
Capability name: NOOP Capability name: NOOP
Description: This capability is returned if the server supports Description: This capability is returned if the server supports
the NOOP command. the NOOP command.
Relevant publications: this RFC, Section 2.11.2. Relevant publications: this RFC, Section 2.11.3.
Person & email address to contact for further information: Alexey Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com> Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG. Author/Change controller: IESG.
6.3. Manage Sieve Response Code Registration Template 6.3. Manage Sieve Response Code Registration Template
To: iana@iana.org To: iana@iana.org
Subject: Manage Sieve Response Code Registration Subject: Manage Sieve Response Code Registration
skipping to change at page 41, line 14 skipping to change at page 44, line 34
Person & email address to contact for further information: Alexey Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com> Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG. Author/Change controller: IESG.
7. Acknowledgements 7. Acknowledgements
Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong, Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dave Cridland Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
and Robert Burrell Donkin for help with this document. Special thank Palauzov, Dave Cridland, Aaron Stone and Robert Burrell Donkin for
you to Phil Pennock for providing text for the NOOP command, as well help with this document. Special thank you to Phil Pennock for
as finding various bugs in the document. providing text for the NOOP command, as well as finding various bugs
in the document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008. Specifications: ABNF", RFC 5234, January 2008.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
skipping to change at page 43, line 24 skipping to change at page 46, line 45
Santesson, S., "Internet X.509 Public Key Infrastructure Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name", Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007. RFC 4985, August 2007.
8.2. Informative References 8.2. Informative References
[DIGEST-MD5] [DIGEST-MD5]
Leach, P. and C. Newman, "Using Digest Authentication as a Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000. SASL Mechanism", RFC 2831, May 2000.
[I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
draft-freed-sieve-ihave-03.txt (work in progress),
October 2008.
[IANA-GUIDELINES] [IANA-GUIDELINES]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[IMAP4rev1] [IMAP4rev1]
Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[LDAP] Zeilenga, K., "Lightweight Directory Access Protocol [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
 End of changes. 47 change blocks. 
64 lines changed or deleted 210 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/