draft-ietf-sieve-managesieve-05.txt   draft-ietf-sieve-managesieve-06.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: June 19, 2009 BeThereBeSquare Inc. Expires: July 5, 2009 BeThereBeSquare Inc.
December 16, 2008 January 1, 2009
A Protocol for Remotely Managing Sieve Scripts A Protocol for Remotely Managing Sieve Scripts
draft-ietf-sieve-managesieve-05 draft-ietf-sieve-managesieve-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 June 19, 2009. This Internet-Draft will expire on July 5, 2009.
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 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 4 skipping to change at page 2, line 12
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 Changes since draft-martin-managesieve-09
o TBD. o TBD.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions used in this document . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 5
1.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Commands and Responses . . . . . . . . . . . . . . . . . . 5
1.3. Response Codes . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Active Script . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 6
1.5. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . 8
1.6. Script Names . . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 8 1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . 9
1.8. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 10 1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 9
1.9. Link Level . . . . . . . . . . . . . . . . . . . . . . . . 11
2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 11 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 12
2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 16 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 17
2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 16 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 17
2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 17 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 18
2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 19 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 21
2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 20 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 21
2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 20 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 21
2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 21 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22
2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 22 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 24
2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 23 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 25
2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 23 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 25
2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 24 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 26
2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 24 2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 26
2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 25 2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 27
2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 26 2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 28
2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 27 2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 29
2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 27 2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 29
3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 27 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 29
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 30 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . 36 5. Security Considerations . . . . . . . . . . . . . . . . . 38
6. IANA Considerations . . . . . . . . . . . . . . . . . . . 36 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 38
6.1. ManageSieve Capability Registration Template . . . . . . . 37 6.1. ManageSieve Capability Registration Template . . . . . . . 39
6.2. Registration of Initial ManageSieve capabilities . . . . . 37 6.2. Registration of Initial ManageSieve capabilities . . . . . 39
6.3. ManageSieve Response Code Registration Template . . . . . 39 6.3. ManageSieve Response Code Registration Template . . . . . 41
6.4. Registration of Initial ManageSieve Response Codes . . . . 39 6.4. Registration of Initial ManageSieve Response Codes . . . . 41
7. Internationalization Considerations . . . . . . . . . . . 45 7. Internationalization Considerations . . . . . . . . . . . 47
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 45
9. References . . . . . . . . . . . . . . . . . . . . . . . . 46 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 47
9.1. Normative References . . . . . . . . . . . . . . . . . . . 46 9. References . . . . . . . . . . . . . . . . . . . . . . . . 48
9.2. Informative References . . . . . . . . . . . . . . . . . . 47 9.1. Normative References . . . . . . . . . . . . . . . . . . . 48
9.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . 49
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
server respectively. Line breaks that do not start a new "C:" or server respectively. Line breaks that do not start a new "C:" or
"S:" exist for editorial reasons. "S:" exist for editorial reasons.
1.2. Syntax 1.2. 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 is
reading a sequence of octets with a known count followed by a line.
1.3. Syntax
This a line oriented protocol much like [IMAP] or [ACAP]. There are This a line oriented protocol much like [IMAP] or [ACAP]. There are
three data types: atoms, numbers and strings. Strings may be quoted three data types: atoms, numbers and strings. Strings may be quoted
or literal. See [ACAP] for detailed descriptions of these types. 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.3) 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.7), 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
the message for meaning. the message for meaning.
The BYE response SHOULD be used if the server wishes to close the 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 connection. A server may wish to do this because the client was idle
for too long or there were too many failed authentication attempts. for too long or there were too many failed authentication attempts.
This response can be issued at any time and should be immediately 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 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 inactivity timeout resulting in client autologout it MUST be no less
than 30 minutes after successful authentication. The inactivity than 30 minutes after successful authentication. The inactivity
timeout MAY be less before authentication. timeout MAY be less before authentication.
1.3. Response Codes 1.4. Response Codes
An OK, NO, or BYE response from the server MAY contain a response An OK, NO, or BYE response from the server MAY contain a response
code to describe the event in a more detailed machine parsable code to describe the event in a more detailed machine parsable
fashion. A response code consists of data inside parentheses in the fashion. A response code consists of data inside parentheses in the
form of an atom, possibly followed by a space and arguments. form of an atom, possibly followed by a space and arguments.
Response codes are defined when there is a specific action that a Response codes are defined when there is a specific action that a
client can take based upon the additional information. In order to client can take based upon the additional information. In order to
support future extension, the response code is represented as a support future extension, the response code is represented as a
slash-separated (Solidus, %x2F) hierarchy with each level of slash-separated (Solidus, %x2F) hierarchy with each level of
hierarchy representing increasing detail about the error. Response hierarchy representing increasing detail about the error. Response
skipping to change at page 7, line 16 skipping to change at page 8, line 29
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 intended by the script writer. valid, it might contain errors not intended by the script writer.
This response code is typically returned in response to PUTSCRIPT This response code is typically returned in response to PUTSCRIPT
and/or CHECKSCRIPT commands. A client seeing such response code and/or CHECKSCRIPT commands. A client seeing such response code
SHOULD present the returned warning text to the user. SHOULD present the returned warning text to the user.
1.4. Active Script 1.5. 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
used without having to download and upload a script stored somewhere used without having to download and upload a script stored somewhere
else. else.
1.5. Quotas 1.6. Quotas
Servers SHOULD impose quotas to prevent malicious users from Servers SHOULD impose quotas to prevent malicious users from
overflowing available storage. If a command would place a user over overflowing available storage. If a command would place a user over
a quota setting, servers that impose such quotas MUST reply with a NO a quota setting, servers that impose such quotas MUST reply with a NO
response containing the QUOTA response code. Client implementations response containing the QUOTA response code. Client implementations
MUST be able to handle commands failing because of quota MUST be able to handle commands failing because of quota
restrictions. restrictions.
1.6. Script Names 1.7. Script Names
A Sieve script name is a sequence of Unicode characters encoded in 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 UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition
(Section 2 of [NET-UNICODE]), with the additional restriction of (Section 2 of [NET-UNICODE]), with the additional restriction of
prohibiting the following Unicode characters: prohibiting the following Unicode characters:
o 0000-001F; [CONTROL CHARACTERS] o 0000-001F; [CONTROL CHARACTERS]
o 007F; DELETE o 007F; DELETE
skipping to change at page 8, line 4 skipping to change at page 9, line 19
(Section 2 of [NET-UNICODE]), with the additional restriction of (Section 2 of [NET-UNICODE]), with the additional restriction of
prohibiting the following Unicode characters: prohibiting the following Unicode characters:
o 0000-001F; [CONTROL CHARACTERS] o 0000-001F; [CONTROL CHARACTERS]
o 007F; DELETE o 007F; DELETE
o 0080-009F; [CONTROL CHARACTERS] o 0080-009F; [CONTROL CHARACTERS]
o 2028; LINE SEPARATOR o 2028; LINE SEPARATOR
o 2029; PARAGRAPH SEPARATOR o 2029; PARAGRAPH SEPARATOR
Sieve script names MUST be at least one octet (and hense Unicode Sieve script names MUST be at least one octet (and hense Unicode
character) long. Zero octets script name has a special meaning (see character) long. Zero octets script name has a special meaning (see
Section 2.8). Servers MUST allow names of up to 128 Unicode 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 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. UTF-8, not counting the terminating NUL), and MAY allow longer names.
A server that receives a script name longer than its internal limit A server that receives a script name longer than its internal limit
MUST rejects the corresponding operation, in particular it MUST NOT MUST reject the corresponding operation, in particular it MUST NOT
truncate the script name. truncate the script name.
1.7. Capabilities 1.8. Capabilities
Server capabilities are sent automatically by the server upon a Server capabilities are sent automatically by the server upon a
client connection, or after successful STARTTLS and AUTHENTICATE client connection, or after successful STARTTLS and AUTHENTICATE
(which establishes a SASL security layer) commands. Capabilities may (which establishes a SASL security layer) commands. Capabilities may
change immediately after a successfully completed STARTTLS command, change immediately after a successfully completed STARTTLS command,
and/or immediately after a successfully completed AUTHENTICATE and/or immediately after a successfully completed AUTHENTICATE
command, and/or after a successfully completed UNAUTHENTICATE command command, and/or after a successfully completed UNAUTHENTICATE command
(see Section 2.14.1). Capabilities MUST remain static at all other (see Section 2.14.1). Capabilities MUST remain static at all other
times. times.
skipping to change at page 10, line 29 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.8. Link Level 1.9. 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. [[anchor7: 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
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
skipping to change at page 12, line 47 skipping to change at page 14, line 8
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
TLS) negotiation itself. Likewise, the client MUST discard any TLS) negotiation itself. Likewise, the client MUST discard any
knowledge obtained from the server, such as the list of ManageSieve knowledge obtained from the server, such as the list of ManageSieve
extensions, which was not obtained from the SASL (or TLS) negotiation extensions, which was not obtained from the SASL (and/or TLS)
itself. (Note that a client MAY compare the advertised SASL negotiation itself. (Note that a client MAY compare the advertised
mechanisms before and after authentication in order to detect an SASL mechanisms before and after authentication in order to detect an
active down-negotiation attack. See below.) active down-negotiation attack. See below.)
Once a SASL security layer is established, the server MUST re-issue Once a SASL security layer is established, the server MUST re-issue
the capability results, followed by an OK response. This is the capability results, followed by an OK response. This is
necessary to protect against man-in-the-middle attacks which alter necessary to protect against man-in-the-middle attacks which alter
the capabilities list prior to SASL negotiation. The capability the capabilities list prior to SASL negotiation. The capability
results MUST include all SASL mechanisms the server was capable of results MUST include all SASL mechanisms the server was capable of
negotiating with that client. This is done in order to allow the negotiating with that client. This is done in order to allow the
client to detect active down-negotiation attack. client to detect active down-negotiation attack. If a user-oriented
client detects such 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 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 When both [TLS] and SASL security layers are in effect, the TLS
encoding MUST be applied (when sending data) after the SASL encoding. encoding MUST be applied (when sending data) after the SASL encoding.
Server implementations SHOULD support SASL proxy authentication so Server implementations SHOULD support SASL proxy authentication so
that an administrator can administer a user's scripts. Proxy that an administrator can administer a user's scripts. Proxy
authentication is when a user authenticates as herself/himself but authentication is when a user authenticates as herself/himself but
requests the server to act (authorize) as another user. requests the server to act (authorize) as another user.
The authorization identity generated by this [SASL] exchange is a The authorization identity generated by this [SASL] exchange is a
skipping to change at page 13, line 35 skipping to change at page 14, line 51
empty string (unless it was transmitted as the empty string), the empty string (unless it was transmitted as the empty string), the
server MUST fail the authentication. server MUST fail the authentication.
If an AUTHENTICATE command fails with a NO response, the client MAY If an AUTHENTICATE command fails with a NO response, the client MAY
try another authentication mechanism by issuing another AUTHENTICATE try another authentication mechanism by issuing another AUTHENTICATE
command. In other words, the client may request authentication types command. In other words, the client may request authentication types
in decreasing order of preference. in decreasing order of preference.
Note that a failed (NO) response to the AUTHENTICATE command may Note that a failed (NO) response to the AUTHENTICATE command may
contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT- contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-
NEEDED or TRANSITION-NEEDED. See Section 1.3 for detailed NEEDED or TRANSITION-NEEDED. See Section 1.4 for detailed
description of the relevant conditions. description of the relevant conditions.
To ensure interoperability, both client and server implementations of To ensure interoperability, both client and server implementations of
the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM] the ManageSieve protocol MUST implement the SCRAM-HMAC-SHA-1 [SCRAM]
SASL mechanism, as well as [PLAIN] over [TLS]. SASL mechanism, as well as [PLAIN] over [TLS].
Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in 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 other email related protocols, however a longer term goal is to
migrate email related protocols from using PLAIN over TLS to SCRAM- migrate email related protocols from using PLAIN over TLS to SCRAM-
HMAC-SHA-1 mechanism. HMAC-SHA-1 mechanism.
skipping to change at page 16, line 21 skipping to change at page 17, line 47
authenticate to the ManageSieve server, the client MUST verify the authenticate to the ManageSieve server, the client MUST verify the
server identity (see Section 2.2.1). If the server identity can't be 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 verified (e.g. the server has not provided any certificate, or if the
certificate verification fails) the client MUST NOT attempt to certificate verification fails) the client MUST NOT attempt to
authenticate using the SASL PLAIN mechanism. authenticate using the SASL PLAIN mechanism.
2.2. STARTTLS Command 2.2. STARTTLS Command
Support for STARTTLS command in servers is optional. Its Support for STARTTLS command in servers is optional. Its
availability is advertised with "STARTTLS" capability as described in availability is advertised with "STARTTLS" capability as described in
Section 1.7. Section 1.8.
The STARTTLS command requests commencement of a TLS [TLS] The STARTTLS command requests commencement of a TLS [TLS]
negotiation. The negotiation begins immediately after the CRLF in negotiation. The negotiation begins immediately after the CRLF in
the OK response. After a client issues a STARTTLS command, it MUST the OK response. After a client issues a STARTTLS command, it MUST
NOT issue further commands until a server response is seen and the NOT issue further commands until a server response is seen and the
TLS negotiation is complete. TLS negotiation is complete.
The STARTTLS command is only valid in non-authenticated state. The The STARTTLS command is only valid in non-authenticated state. The
server remains in non-authenticated state, even if client credentials server remains in non-authenticated state, even if client credentials
are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL
skipping to change at page 17, line 49 skipping to change at page 19, line 20
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, with the exception that no wildcard
matching is allowed. [[anchor8: Chris Newman says that such matching is allowed. [[anchor9: Chris Newman says that such
prohibition of wildcards doesn't match existing practice.]] prohibition of wildcards doesn't match existing practice.]]
Although the use of the Common Name value is existing Although the use of the Common Name value is existing
practice, it is deprecated, and Certification Authorities are practice, it is deprecated, and Certification Authorities are
encouraged to provide subjectAltName values instead. Note encouraged to provide subjectAltName values instead. Note
that the TLS implementation may represent DNs in certificates that the TLS implementation may represent DNs in certificates
according to X.500 or other conventions. For example, some according to X.500 or other conventions. For example, some
X.500 implementations order the RDNs in a DN using a left-to- X.500 implementations order the RDNs in a DN using a left-to-
right (most significant to least significant) convention right (most significant to least significant) convention
instead of LDAP's right- to-left convention. instead of LDAP's right- to-left convention.
skipping to change at page 20, line 39 skipping to change at page 22, line 9
quota(s), for example the server MAY use the script name to check if 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 a script would be replaced or a new one would be created. Servers
respond with an NO if storing a script with that name and size would respond with an NO if storing a script with that name and size would
fail or OK otherwise. Clients SHOULD issue this command before fail or OK otherwise. Clients SHOULD issue this command before
attempting to place a script on the server. attempting to place a script on the server.
Note that the OK response from the HAVESPACE command does not Note that the OK response from the HAVESPACE command does not
constitute a guarantee of success as server disk space conditions constitute a guarantee of success as server disk space conditions
could change between the client issuing the HAVESPACE and the client could change between the client issuing the HAVESPACE and the client
issuing the PUTSCRIPT commands. A QUOTA response code (see issuing the PUTSCRIPT commands. A QUOTA response code (see
Section 1.3) remains a possible (albeit unlikely) response to a Section 1.4) remains a possible (albeit unlikely) response to a
subsequent PUTSCRIPT with the same name and size. subsequent PUTSCRIPT with the same name and size.
Example: Example:
C: HAVESPACE "myscript" 999999 C: HAVESPACE "myscript" 999999
S: NO (QUOTA/MAXSIZE) "Quota exceeded" S: NO (QUOTA/MAXSIZE) "Quota exceeded"
C: HAVESPACE "foobar" 435 C: HAVESPACE "foobar" 435
S: OK S: OK
skipping to change at page 21, line 28 skipping to change at page 22, line 43
whether the script is processed on incoming mail, unless it replaces whether the script is processed on incoming mail, unless it replaces
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 validity, which The server MUST check the submitted script for validity, which
includes checking that the script complies with the Sieve grammar includes checking that the script complies with the Sieve grammar
[SIEVE], that all Sieve extensions mentioned in script's "require" [SIEVE], and that all Sieve extensions mentioned in script's
statement(s) are supported by the Sieve interpreter. (Note that if "require" statement(s) are supported by the Sieve interpreter. (Note
the Sieve interpreter supports the Sieve "ihave" extension [I-HAVE], that if the Sieve interpreter supports the Sieve "ihave" extension
any unrecognized/unsupported extension mentioned in the "ihave" test [I-HAVE], any unrecognized/unsupported extension mentioned in the
MUST NOT cause the validation failure.) Other checks such as "ihave" test MUST NOT cause the validation failure.) Other checks
validating the supplied command arguments for each command MAY be such as validating the supplied command arguments for each command
performed. Essentially, the performed validation SHOULD be the same MAY be performed. Essentially, the performed validation SHOULD be
as performed when compiling the script for execution. the same as performed when compiling the script for execution.
Implementations that use a binary representation to store compiled Implementations that use a binary representation to store compiled
scripts can extend the validation to a full compilation, in order to scripts can extend the validation to a full compilation, in order to
avoid validating uploaded scripts multiple times. avoid validating uploaded scripts multiple times.
If the script fails the validation the server MUST reply with a NO 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 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.8),
encoded in UTF-8 [UTF-8]. encoded in UTF-8 [UTF-8].
An OK response MAY contain the WARNINGS response code. In such case An OK response MAY contain the WARNINGS response code. In such case
the human readable message that follows the OK response SHOULD the human readable message that follows the OK response SHOULD
contain a specific warning message (or messages) giving the line contain a specific warning message (or messages) giving the line
number(s) in the script that might contain errors not intended by the number(s) in the script that might contain errors not intended by the
script writer. The human readable message is in the language script writer. The human readable message is in the language
returned in the latest LANGUAGE capability (or in "i-default", see returned in the latest LANGUAGE capability (or in "i-default", see
Section 1.7), encoded in UTF-8 [UTF-8] A client seeing such response Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response
code SHOULD present the message to the user. code SHOULD present the message to the user.
Examples: Examples:
C: Putscript "foo" {31+} C: Putscript "foo" {31+}
C: #comment C: #comment
C: InvalidSieveCommand C: InvalidSieveCommand
C: C:
S: NO "line 2: Syntax error" S: NO "line 2: Syntax error"
skipping to change at page 26, line 12 skipping to change at page 28, line 12
extension [I-HAVE], any unrecognized/unsupported extension mentioned extension [I-HAVE], any unrecognized/unsupported extension mentioned
in the "ihave" test MUST NOT cause the syntactic validation failure.) 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. The message given with a NO response MUST be human response. 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.8),
encoded in UTF-8 [UTF-8]. encoded in UTF-8 [UTF-8].
Examples: Examples:
C: CheckScript {31+} C: CheckScript {31+}
C: #comment C: #comment
C: InvalidSieveCommand C: InvalidSieveCommand
C: C:
S: NO "line 2: Syntax error" S: NO "line 2: Syntax error"
A ManageSieve server supporting this command MUST NOT check if the A ManageSieve server supporting this command MUST NOT check if the
script will put the current user over its quota limit. script will put the current user over its quota limit.
An OK response MAY contain the WARNINGS response code. In such case An OK response MAY contain the WARNINGS response code. In such case
the human readable message that follows the OK response SHOULD the human readable message that follows the OK response SHOULD
contain a specific warning message (or messages) giving the line contain a specific warning message (or messages) giving the line
number(s) in the script that might contain errors not intended by the number(s) in the script that might contain errors not intended by the
script writer. The human readable message is in the language script writer. The human readable message is in the language
returned in the latest LANGUAGE capability (or in "i-default", see returned in the latest LANGUAGE capability (or in "i-default", see
Section 1.7), encoded in UTF-8 [UTF-8] A client seeing such response Section 1.8), encoded in UTF-8 [UTF-8] A client seeing such response
code SHOULD present the message to the user. code SHOULD present the message to the user.
2.13. NOOP Command 2.13. 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.
skipping to change at page 29, line 13 skipping to change at page 31, line 13
;; but without ";", "&" and "=". ;; but without ";", "&" and "=".
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 (see The server form is used in the REFERRAL response code (see
Section 1.3 in order to designate another server where the client Section 1.4 in order to designate another server where the client
should perform its operations. should perform its 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: Encoding considerations:
skipping to change at page 37, line 34 skipping to change at page 39, line 34
To: iana@iana.org To: iana@iana.org
Subject: ManageSieve Capability Registration Subject: ManageSieve Capability Registration
Please register the following ManageSieve Capabilities: Please register the following ManageSieve Capabilities:
Capability name: IMPLEMENTATION Capability name: IMPLEMENTATION
Description: Its value contains name of server implementation and Description: Its value contains name of server implementation and
its version. its version.
Relevant publications: this RFC, Section 1.7. 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: SASL Capability name: SASL
Description: Its value contains a space separated list of SASL Description: Its value contains a space separated list of SASL
mechanisms supported by server. mechanisms supported by server.
Relevant publications: this RFC, Section 1.7 and Section 2.1. Relevant publications: this RFC, Section 1.8 and Section 2.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: SIEVE Capability name: SIEVE
Description: Its value contains a space separated list of Description: Its value contains a space separated list of
supported SIEVE extensions supported SIEVE extensions
Relevant publications: this RFC, Section 1.7. Also [SIEVE]. Relevant publications: this RFC, Section 1.8. Also [SIEVE].
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: STARTTLS Capability name: STARTTLS
Description: This capability is returned if server supports TLS Description: This capability is returned if server supports TLS
(STARTTLS command). (STARTTLS command).
Relevant publications: this RFC, Section 1.7 and Section 2.2. Relevant publications: this RFC, Section 1.8 and Section 2.2.
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: NOTIFY Capability name: NOTIFY
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.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: 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.7. 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: VERSION Capability name: VERSION
Description: This capability is returned if the server is Description: This capability is returned if the server is
compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT, compliant with RFCXXXX, i.e. that it supports RENAMESCRIPT,
CHECKSCRIPT and NOOP commands. CHECKSCRIPT and NOOP commands.
skipping to change at page 45, line 11 skipping to change at page 47, line 11
for client state synchronization. for client state synchronization.
Published Specification(s): [RFCXXXX] Published Specification(s): [RFCXXXX]
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. Internationalization Considerations 7. Internationalization Considerations
The LANGUAGE capability (see Section 1.7) allows a client to discover The LANGUAGE capability (see Section 1.8) allows a client to discover
the current language used in all human readable responses that might the current language used in all human readable responses that might
be returned at the end of any OK/NO/BYE response. Human readable 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, text in OK responses typically doesn't need to be shown to the user,
unless it is returned in response to PUTSCRIPT or CHECKSCRIPT command unless it is returned in response to PUTSCRIPT or CHECKSCRIPT command
that also contain the WARNINGS response code Section 1.3. Human that also contain the WARNINGS response code Section 1.4. Human
readable text from NO/BYE responses is intended be shown to the user, readable text from NO/BYE responses is intended be shown to the user,
unless the client can automatically handle failure of the command unless the client can automatically handle failure of the command
that caused such response. Clients SHOULD use response codes that caused such response. Clients SHOULD use response codes
(Section 1.3) for automatic error handling. Response codes MAY also (Section 1.4) for automatic error handling. Response codes MAY also
be used by the client to present error messages in a language be used by the client to present error messages in a language
understood by the user, for example if the LANGUAGE capability understood by the user, for example if the LANGUAGE capability
doesn't return a language understood by the user. doesn't return a language understood by the user.
Note that the human readable text from OK (WARNINGS) or NO/BYE Note that the human readable text from OK (WARNINGS) or NO/BYE
responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced
users that understand Sieve language. Such advanced users are often users that understand Sieve language. Such advanced users are often
sophisticated enough to be able to handle whatever language the sophisticated enough to be able to handle whatever language the
server is using, even if it is not their preferred language, and will 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 want to see error/warning text no matter what language the server
skipping to change at page 47, line 29 skipping to change at page 49, line 29
[SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email [SIEVE] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Filtering Language", RFC 5228, January 2008. Filtering Language", RFC 5228, January 2008.
[StringPrep] [StringPrep]
Hoffman, P. and M. Blanchet, "Preparation of Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454, Internationalized Strings ("stringprep")", RFC 3454,
December 2002. December 2002.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 5280,
April 2002. May 2008.
[X509-SRV] [X509-SRV]
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.
9.2. Informative References 9.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", [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
draft-freed-sieve-ihave-03.txt (work in progress), draft-freed-sieve-ihave-03.txt (work in progress),
October 2008. October 2008.
[IANA-GUIDELINES]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [IMAP] 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
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. June 2006.
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006. Security Layer (SASL) Mechanism", RFC 4616, August 2006.
skipping to change at page 49, line 4 skipping to change at line 2225
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Tim Martin Tim Martin
BeThereBeSquare Inc. BeThereBeSquare Inc.
672 Haight st. 672 Haight st.
San Francisco, CA 94117 San Francisco, CA 94117
US US
Phone: +1 510 260-4175 Phone: +1 510 260-4175
Email: timmartin@alumni.cmu.edu Email: timmartin@alumni.cmu.edu
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.
 End of changes. 52 change blocks. 
99 lines changed or deleted 127 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/