dovecot-2.0-pigeonhole: Updated ManageSieve specification.
pigeonhole at rename-it.nl
pigeonhole at rename-it.nl
Tue Jul 13 21:08:33 EEST 2010
details: http://hg.rename-it.nl/dovecot-2.0-pigeonhole/rev/cec28cc5d4bf
changeset: 1330:cec28cc5d4bf
user: Stephan Bosch <stephan at rename-it.nl>
date: Tue Jul 13 20:08:24 2010 +0200
description:
Updated ManageSieve specification.
diffstat:
doc/rfc/draft-ietf-sieve-managesieve-09.txt | 2913 --------------------------------
doc/rfc/managesieve.rfc5804.txt | 2747 ++++++++++++++++++++++++++++++
2 files changed, 2747 insertions(+), 2913 deletions(-)
diffs (truncated from 5668 to 300 lines):
diff -r 6942c0718e29 -r cec28cc5d4bf doc/rfc/draft-ietf-sieve-managesieve-09.txt
--- a/doc/rfc/draft-ietf-sieve-managesieve-09.txt Tue Jul 13 18:15:44 2010 +0200
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,2913 +0,0 @@
-
-
-
-Sieve Working Group A. Melnikov, Ed.
-Internet-Draft Isode Limited
-Intended status: Standards Track T. Martin
-Expires: July 21, 2009 BeThereBeSquare Inc.
- January 17, 2009
-
-
- A Protocol for Remotely Managing Sieve Scripts
- draft-ietf-sieve-managesieve-09
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 21, 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
-
- Sieve scripts allow users to filter incoming email. Message stores
-
-
-
-Melnikov & Martin Expires July 21, 2009 [Page 1]
-
-Internet-Draft ManageSieve January 2009
-
-
- are commonly sealed servers so users cannot log into them, yet users
- must be able to update their scripts on them. This document
- describes a protocol "ManageSieve" for securely managing Sieve
- scripts on a remote server. This protocol allows a user to have
- multiple scripts, and also alerts a user to syntactically flawed
- scripts.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Expires July 21, 2009 [Page 2]
-
-Internet-Draft ManageSieve January 2009
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.1. Conventions used in this document . . . . . . . . . . . . 5
- 1.2. Commands and Responses . . . . . . . . . . . . . . . . . . 5
- 1.3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.4. Response Codes . . . . . . . . . . . . . . . . . . . . . . 6
- 1.5. Active Script . . . . . . . . . . . . . . . . . . . . . . 8
- 1.6. Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 1.7. Script Names . . . . . . . . . . . . . . . . . . . . . . . 9
- 1.8. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 9
- 1.9. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11
-
- 2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . . . . 12
- 2.1.1. Use of SASL PLAIN mechanism over TLS . . . . . . . . . . . 17
- 2.2. STARTTLS Command . . . . . . . . . . . . . . . . . . . . . 17
- 2.2.1. Server Identity Check . . . . . . . . . . . . . . . . . . 18
- 2.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . . . . 21
- 2.4. CAPABILITY Command . . . . . . . . . . . . . . . . . . . . 21
- 2.5. HAVESPACE Command . . . . . . . . . . . . . . . . . . . . 21
- 2.6. PUTSCRIPT Command . . . . . . . . . . . . . . . . . . . . 22
- 2.7. LISTSCRIPTS Command . . . . . . . . . . . . . . . . . . . 24
- 2.8. SETACTIVE Command . . . . . . . . . . . . . . . . . . . . 25
- 2.9. GETSCRIPT Command . . . . . . . . . . . . . . . . . . . . 25
- 2.10. DELETESCRIPT Command . . . . . . . . . . . . . . . . . . . 26
- 2.11. RENAMESCRIPT Command . . . . . . . . . . . . . . . . . . . 26
- 2.12. CHECKSCRIPT Command . . . . . . . . . . . . . . . . . . . 27
- 2.13. NOOP Command . . . . . . . . . . . . . . . . . . . . . . . 28
- 2.14. Recommended extensions . . . . . . . . . . . . . . . . . . 29
- 2.14.1. UNAUTHENTICATE Command . . . . . . . . . . . . . . . . . . 29
-
- 3. Sieve URL Scheme . . . . . . . . . . . . . . . . . . . . . 29
-
- 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 32
-
- 5. Security Considerations . . . . . . . . . . . . . . . . . 38
-
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 39
- 6.1. ManageSieve Capability Registration Template . . . . . . . 39
- 6.2. Registration of Initial ManageSieve capabilities . . . . . 40
- 6.3. ManageSieve Response Code Registration Template . . . . . 42
- 6.4. Registration of Initial ManageSieve Response Codes . . . . 43
-
- 7. Internationalization Considerations . . . . . . . . . . . 48
-
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 49
-
-
-
-
-Melnikov & Martin Expires July 21, 2009 [Page 3]
-
-Internet-Draft ManageSieve January 2009
-
-
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . 49
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 49
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 51
-
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . 51
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Melnikov & Martin Expires July 21, 2009 [Page 4]
-
-Internet-Draft ManageSieve January 2009
-
-
-1. Introduction
-
-1.1. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KEYWORDS].
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively. Line breaks that do not start a new "C:" or
- "S:" exist for editorial reasons.
-
-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
-
- ManageSieve is a line oriented protocol much like [IMAP] or [ACAP],
- which runs over TCP. There are three data types: atoms, numbers and
- strings. Strings may be quoted or literal. See [ACAP] for detailed
- descriptions of these types.
-
- Each command consists of an atom (the command name) followed by zero
- or more strings and numbers terminated by CRLF.
-
- All client queries are replied to with either an OK, NO, or BYE
- response. Each response may be followed by a response code (see
- Section 1.4) and by a string consisting of human readable text in the
- local language (as returned by the LANGUAGE capability, see
- 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
- the message for meaning.
-
- The BYE response SHOULD be used if the server wishes to close the
- connection. A server may wish to do this because the client was idle
- for too long or there were too many failed authentication attempts.
- This response can be issued at any time and should be immediately
- followed by a server hang-up of the connection. If a server has an
-
-
-
-Melnikov & Martin Expires July 21, 2009 [Page 5]
-
-Internet-Draft ManageSieve January 2009
-
-
- inactivity timeout resulting in client autologout it MUST be no less
- than 30 minutes after successful authentication. The inactivity
- timeout MAY be less before authentication.
-
-1.4. Response Codes
-
- An OK, NO, or BYE response from the server MAY contain a response
- code to describe the event in a more detailed machine parsable
- fashion. A response code consists of data inside parentheses in the
- form of an atom, possibly followed by a space and arguments.
- Response codes are defined when there is a specific action that a
- client can take based upon the additional information. In order to
- support future extension, the response code is represented as a
More information about the dovecot-cvs
mailing list