draft-ietf-sieve-managesieve-06.txt   draft-ietf-sieve-managesieve-07.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: July 5, 2009 BeThereBeSquare Inc. Expires: July 19, 2009 BeThereBeSquare Inc.
January 1, 2009 January 15, 2009
A Protocol for Remotely Managing Sieve Scripts A Protocol for Remotely Managing Sieve Scripts
draft-ietf-sieve-managesieve-06 draft-ietf-sieve-managesieve-07
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 July 5, 2009. This Internet-Draft will expire on July 19, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 11 skipping to change at page 3, line 5
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.
Changes since draft-martin-managesieve-09
o TBD.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions used in this document . . . . . . . . . . . . 5 1.1. Conventions used in this document . . . . . . . . . . . . 5
1.2. Commands and Responses . . . . . . . . . . . . . . . . . . 5 1.2. Commands and Responses . . . . . . . . . . . . . . . . . . 5
1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . 8
1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . 9 1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . 9
1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 9 1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 9
1.9. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 11 1.9. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 12 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 12
2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 17 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 17
2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 17 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 17
2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 18 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 18
2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 21 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 21
2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 21 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 21
2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 21 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 21
2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 46 skipping to change at page 3, line 46
3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 29 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 29
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 32 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . 38 5. Security Considerations . . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 38 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 38
6.1. ManageSieve Capability Registration Template . . . . . . . 39 6.1. ManageSieve Capability Registration Template . . . . . . . 39
6.2. Registration of Initial ManageSieve capabilities . . . . . 39 6.2. Registration of Initial ManageSieve capabilities . . . . . 39
6.3. ManageSieve Response Code Registration Template . . . . . 41 6.3. ManageSieve Response Code Registration Template . . . . . 42
6.4. Registration of Initial ManageSieve Response Codes . . . . 41 6.4. Registration of Initial ManageSieve Response Codes . . . . 42
7. Internationalization Considerations . . . . . . . . . . . 47 7. Internationalization Considerations . . . . . . . . . . . 47
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 47 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Normative References . . . . . . . . . . . . . . . . . . . 48 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48
9.2. Informative References . . . . . . . . . . . . . . . . . . 49 9.2. Informative References . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 51
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 5, line 32 skipping to change at page 5, line 32
of a client command, server data, and a server completion result of a client command, server data, and a server completion result
response. response.
All interactions transmitted by client and server are in the form of All interactions transmitted by client and server are in the form of
lines, that is, strings that end with a CRLF. The protocol receiver lines, that is, strings that end with a CRLF. The protocol receiver
of a ManageSieve client or server is either reading a line, or is of a ManageSieve client or server is either reading a line, or is
reading a sequence of octets with a known count followed by a line. reading a sequence of octets with a known count followed by a line.
1.3. Syntax 1.3. Syntax
This a line oriented protocol much like [IMAP] or [ACAP]. There are ManageSieve is a line oriented protocol much like [IMAP] or [ACAP],
three data types: atoms, numbers and strings. Strings may be quoted which runs over TCP. There are three data types: atoms, numbers and
or literal. See [ACAP] for detailed descriptions of these types. 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 Each command consists of an atom (the command name) followed by zero
or more strings and numbers terminated by CRLF. or more strings and numbers terminated by CRLF.
All client queries are replied to with either an OK, NO, or BYE All client queries are replied to with either an OK, NO, or BYE
response. Each response may be followed by a response code (see response. Each response may be followed by a response code (see
Section 1.4) and by a string consisting of human readable text in the Section 1.4) and by a string consisting of human readable text in the
local language (as returned by the LANGUAGE capability, see local language (as returned by the LANGUAGE capability, see
Section 1.8), encoded in [UTF-8]. The contents of the string SHOULD Section 1.8), encoded in [UTF-8]. The contents of the string SHOULD
be shown to the user and implementations MUST NOT attempt to parse be shown to the user and implementations MUST NOT attempt to parse
skipping to change at page 11, line 38 skipping to change at page 11, line 38
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: "NOTIFY" "xmpp mailto" S: "NOTIFY" "xmpp mailto"
S: "OWNER" "alexey@example.com" S: "OWNER" "alexey@example.com"
S: "MAXREdIRECTS" "5" S: "MAXREdIRECTS" "5"
S: "VERSION" "1.0" S: "VERSION" "1.0"
S: OK S: OK
1.9. Link Level 1.9. Transport
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. [[anchor7: IANA registration of port 2000 is listens on port [[anchor7: To-be-assigned by IANA]].
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
communication with the receiving entity. The process is as follows: communication with the receiving entity. The process is as follows:
1. Attempt to resolve the hostname using a [DNS-SRV] Service of 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
"sieve" and a Proto of "tcp" for the target domain (e.g. "sieve" and a Proto of "tcp" for the target domain (e.g.
"example.net"), resulting in resource records such as "example.net"), resulting in resource records such as
"_sieve._tcp.example.net.". The result of the SRV lookup, if "_sieve._tcp.example.net.". The result of the SRV lookup, if
skipping to change at page 12, line 18 skipping to change at page 12, line 17
weight. IP addresses from the first successfully resolved weight. IP addresses from the first successfully resolved
hostname (with the corresponding port number returned by SRV hostname (with the corresponding port number returned by SRV
lookup) are used to connect to the server. If connection using lookup) are used to connect to the server. If connection using
one of the IP addresses fails, the next resolved IP address is one of the IP addresses fails, the next resolved IP address is
used to connect. If connection to all resolved IP addresses used to connect. If connection to all resolved IP addresses
fails, then the resolution/connect is repeated for the next fails, then the resolution/connect is repeated for the next
hostname returned by SRV lookup. hostname returned by SRV lookup.
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 [[anchor8: To-
be-assigned by IANA]].
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.13) commands are valid. ManageSieve extensions MAY define Section 2.13) commands are valid. ManageSieve extensions MAY define
other commands which are valid in non-authenticated state. Servers other commands which are valid in non-authenticated state. Servers
MUST reject all other commands with a NO response. Clients may MUST reject all other commands with a NO response. Clients may
skipping to change at page 19, line 19 skipping to change at page 19, line 19
considered acceptable. considered acceptable.
2. The client MAY use other types of subjectAltName for 2. The client MAY use other types of subjectAltName for
performing comparison. performing comparison.
3. The server's identity MAY also be verified by comparing the 3. The server's identity MAY also be verified by comparing the
reference identity to the Common Name (CN) [RFC4519] value in reference identity to the Common Name (CN) [RFC4519] value in
the leaf Relative Distinguished Name (RDN) of the subjectName the leaf Relative Distinguished Name (RDN) of the subjectName
field of the server's certificate. This comparison is field of the server's certificate. This comparison is
performed using the rules for comparison of DNS names in performed using the rules for comparison of DNS names in
Section 2.2.1.1, below, with the exception that no wildcard Section 2.2.1.1, below. Although the use of the Common Name
matching is allowed. [[anchor9: Chris Newman says that such value is existing practice, it is deprecated, and
prohibition of wildcards doesn't match existing practice.]] Certification Authorities are encouraged to provide
Although the use of the Common Name value is existing subjectAltName values instead. Note that the TLS
practice, it is deprecated, and Certification Authorities are implementation may represent DNs in certificates according to
encouraged to provide subjectAltName values instead. Note X.500 or other conventions. For example, some X.500
that the TLS implementation may represent DNs in certificates implementations order the RDNs in a DN using a left-to-right
according to X.500 or other conventions. For example, some (most significant to least significant) convention instead of
X.500 implementations order the RDNs in a DN using a left-to- LDAP's right- to-left convention.
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 o When the reference identity is an IP address, the iPAddress
subjectAltName SHOULD be used by the client for comparison. The subjectAltName SHOULD be used by the client for comparison. The
comparison is performed as described in Section 2.2.1.2. comparison is performed as described in Section 2.2.1.2.
o In either case the client MAY map the reference identity to a o In either case the client MAY map the reference identity to a
different type prior to performing a comparison. Mappings may be different type prior to performing a comparison. Mappings may be
performed for all available subjectAltName types to which the performed for all available subjectAltName types to which the
reference identity can be mapped; however, the reference identity reference identity can be mapped; however, the reference identity
should only be mapped to types for which the mapping is either should only be mapped to types for which the mapping is either
skipping to change at page 33, line 20 skipping to change at page 33, line 20
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-checkscript / 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]
*(CRLF string) *(CRLF string)
skipping to change at page 34, line 42 skipping to change at page 34, line 42
literal-s2c = "{" number "}" CRLF *OCTET literal-s2c = "{" number "}" CRLF *OCTET
;; Almost identical to literal-c2s, ;; Almost identical to literal-c2s,
;; but with no '+' character. ;; but with no '+' character.
;; The number represents the number of ;; The number represents the number of
;; octets. ;; octets.
;; This type of literal can only be sent ;; This type of literal can only be sent
;; from the server to the client. ;; from the server to the client.
number = 1*DIGIT number = 1*DIGIT
;; A 32-bit unsigned number. ;; A 32-bit unsigned number
;; with no extra leading zeros.
;; (0 <= n < 4,294,967,296) ;; (0 <= n < 4,294,967,296)
number-str = string number-str = string
;; <number> encoded as a <string>. ;; <number> encoded as a <string>.
quoted = DQUOTE *1024QUOTED-CHAR DQUOTE quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
;; limited to 1024 octets between the <">s ;; limited to 1024 octets between the <">s
resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" /
"QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] / "QUOTA" ["/" ("MAXSCRIPTS" / "MAXSIZE")] /
resp-code-sasl / resp-code-sasl /
resp-code-referral / resp-code-referral /
"TRANSITION-NEEDED" / "TRYLATER" / "TRANSITION-NEEDED" / "TRYLATER" /
"ACTIVE" / "NONEXISTENT" / "ACTIVE" / "NONEXISTENT" /
"ALREADYEXISTS" / "WARNINGS" / "ALREADYEXISTS" / "WARNINGS" /
"TAG" SP string / "TAG" SP string /
resp-code-ext resp-code-ext
skipping to change at page 36, line 22 skipping to change at page 36, line 24
DQUOTE "STARTTLS" DQUOTE / DQUOTE "STARTTLS" DQUOTE /
DQUOTE "LANGUAGE" DQUOTE SP language / DQUOTE "LANGUAGE" DQUOTE SP language /
DQUOTE "VERSION" DQUOTE SP version / DQUOTE "VERSION" DQUOTE SP version /
DQUOTE "OWNER" DQUOTE SP string 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.
version = DQUOTE "1.0" DQUOTE
version = ( DQUOTE "1.0" DQUOTE ) / version-ext
version-ext = DQUOTE number "." number DQUOTE
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
; specified in [SASL]. ; specified in [SASL].
; Can be empty. ; Can be empty.
sieve-extensions = string sieve-extensions = string
; space separated list of supported SIEVE extensions, ; space separated list of supported SIEVE extensions,
; can be empty. ; can be empty.
skipping to change at page 38, line 29 skipping to change at page 38, line 35
to allow configuration of both clients and servers to refuse to to allow configuration of both clients and servers to refuse to
transfer sensitive information in the absence of strong encryption. transfer sensitive information in the absence of strong encryption.
If an implementation supports SASL mechanisms that are vulnerable to If an implementation supports SASL mechanisms that are vulnerable to
passive eavesdropping attacks (such as [PLAIN]), then the passive eavesdropping attacks (such as [PLAIN]), then the
implementation MUST support at least one configuration where these implementation MUST support at least one configuration where these
SASL mechanisms are not advertised or used without the presence of an SASL mechanisms are not advertised or used without the presence of an
external security layer such as [TLS]. external security layer such as [TLS].
Some response codes returned on failed AUTHENTICATE command may Some response codes returned on failed AUTHENTICATE command may
disclose whether or not the username is valid, so server disclose whether or not the username is valid (e.g. TRANSITION-
implementations SHOULD provide the ability to disable these features NEEDED), so server implementations SHOULD provide the ability to
(or make them not conditional on a per-user basis) for sites disable these features (or make them not conditional on a per-user
concerned about such disclosure. In the case of ENCRYPT-NEEDED, if basis) for sites concerned about such disclosure. In the case of
it is applied to all identities then no extra information is ENCRYPT-NEEDED, if it is applied to all identities then no extra
disclosed, but if it is applied on a per-user basis it can disclose information is disclosed, but if it is applied on a per-user basis it
information. can disclose information.
6. IANA Considerations 6. IANA Considerations
IANA is requested to reserve TCP port number 2000 for use with the IANA is requested to reserve a TCP port number for use with the
ManageSieve protocol described in this document. ManageSieve protocol described in this document.
IANA is requested to register the "sieve" URI scheme defined in IANA is requested to register the "sieve" URI scheme defined in
Section 3 of this document. Section 3 of this document.
IANA is requested to register "sieve" in the "GSSAPI/Kerberos/SASL
Service Names" registry.
IANA is requested to create a new registry for ManageSieve IANA is requested to create a new registry for ManageSieve
capabilities. The registration template for ManageSieve capabilities capabilities. The registration template for ManageSieve capabilities
is specified in Section 6.1. ManageSieve protocol capabilities MUST is specified in Section 6.1. ManageSieve protocol capabilities MUST
be specified in a standards track or IESG approved experimental RFC. be specified in a standards track or IESG approved experimental RFC.
IANA is requested to create a new registry for ManageSieve response IANA is requested to create a new registry for ManageSieve response
codes. The registration template for ManageSieve response codes is codes. The registration template for ManageSieve response codes is
specified in Section 6.3. ManageSieve protocol response codes MUST specified in Section 6.3. ManageSieve protocol response codes MUST
be specified in a standards track or IESG approved experimental RFC. be specified in a standards track or IESG approved experimental RFC.
skipping to change at page 40, line 41 skipping to change at page 40, line 48
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.8. Relevant publications: this RFC, Section 1.8.
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: 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.8.
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 [RFC4646])
currently used for human readable error messages.
Relevant publications: this RFC, Section 1.8.
Person & email address to contact for further information: Alexey
Melnikov <alexey.melnikov@isode.com>
Author/Change controller: IESG.
Capability name: OWNER Capability name: OWNER
Description: Its value contains UTF-8 encoded name of the Description: Its value contains UTF-8 encoded name of the
currently logged in user ("authorization identity" according to currently logged in user ("authorization identity" according to
RFC 4422). RFC 4422).
Relevant publications: this RFC, Section 1.8. Relevant publications: this RFC, Section 1.8.
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>
 End of changes. 22 change blocks. 
44 lines changed or deleted 71 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/