7Internet Engineering Task Force (IETF) A. Melnikov, Ed.
8Request for Comments: 5804 Isode Limited
9Category: Standards Track T. Martin
10ISSN: 2070-1721 BeThereBeSquare, Inc.
14 A Protocol for Remotely Managing Sieve Scripts
18 Sieve scripts allow users to filter incoming email. Message stores
19 are commonly sealed servers so users cannot log into them, yet users
20 must be able to update their scripts on them. This document
21 describes a protocol "ManageSieve" for securely managing Sieve
22 scripts on a remote server. This protocol allows a user to have
23 multiple scripts, and also alerts a user to syntactically flawed
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc5804.
42 Copyright (c) 2010 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58Melnikov & Martin Standards Track [Page 1]
60RFC 5804 ManageSieve July 2010
65 1. Introduction ....................................................3
66 1.1. Commands and Responses .....................................3
67 1.2. Syntax .....................................................3
68 1.3. Response Codes .............................................3
69 1.4. Active Script ..............................................6
70 1.5. Quotas .....................................................6
71 1.6. Script Names ...............................................6
72 1.7. Capabilities ...............................................7
73 1.8. Transport ..................................................9
74 1.9. Conventions Used in This Document .........................10
75 2. Commands .......................................................10
76 2.1. AUTHENTICATE Command ......................................11
77 2.1.1. Use of SASL PLAIN Mechanism over TLS ...............16
78 2.2. STARTTLS Command ..........................................16
79 2.2.1. Server Identity Check ..............................17
80 2.3. LOGOUT Command ............................................20
81 2.4. CAPABILITY Command ........................................20
82 2.5. HAVESPACE Command .........................................20
83 2.6. PUTSCRIPT Command .........................................21
84 2.7. LISTSCRIPTS Command .......................................23
85 2.8. SETACTIVE Command .........................................24
86 2.9. GETSCRIPT Command .........................................25
87 2.10. DELETESCRIPT Command .....................................25
88 2.11. RENAMESCRIPT Command .....................................26
89 2.12. CHECKSCRIPT Command ......................................27
90 2.13. NOOP Command .............................................28
91 2.14. Recommended Extensions ...................................28
92 2.14.1. UNAUTHENTICATE Command ............................28
93 3. Sieve URL Scheme ...............................................29
94 4. Formal Syntax ..................................................31
95 5. Security Considerations ........................................37
96 6. IANA Considerations ............................................38
97 6.1. ManageSieve Capability Registration Template ..............39
98 6.2. Registration of Initial ManageSieve Capabilities ..........39
99 6.3. ManageSieve Response Code Registration Template ...........41
100 6.4. Registration of Initial ManageSieve Response Codes ........41
101 7. Internationalization Considerations ............................46
102 8. Acknowledgements ...............................................46
103 9. References .....................................................47
104 9.1. Normative References ......................................47
105 9.2. Informative References ....................................48
114Melnikov & Martin Standards Track [Page 2]
116RFC 5804 ManageSieve July 2010
1211.1. Commands and Responses
123 A ManageSieve connection consists of the establishment of a client/
124 server network connection, an initial greeting from the server, and
125 client/server interactions. These client/server interactions consist
126 of a client command, server data, and a server completion result
129 All interactions transmitted by client and server are in the form of
130 lines, that is, strings that end with a CRLF. The protocol receiver
131 of a ManageSieve client or server is either reading a line or reading
132 a sequence of octets with a known count followed by a line.
136 ManageSieve is a line-oriented protocol much like [IMAP] or [ACAP],
137 which runs over TCP. There are three data types: atoms, numbers and
138 strings. Strings may be quoted or literal. See [ACAP] for detailed
139 descriptions of these types.
141 Each command consists of an atom (the command name) followed by zero
142 or more strings and numbers terminated by CRLF.
144 All client queries are replied to with either an OK, NO, or BYE
145 response. Each response may be followed by a response code (see
146 Section 1.3) and by a string consisting of human-readable text in the
147 local language (as returned by the LANGUAGE capability; see
148 Section 1.7), encoded in UTF-8 [UTF-8]. The contents of the string
149 SHOULD be shown to the user ,and implementations MUST NOT attempt to
150 parse the message for meaning.
152 The BYE response SHOULD be used if the server wishes to close the
153 connection. A server may wish to do this because the client was idle
154 for too long or there were too many failed authentication attempts.
155 This response can be issued at any time and should be immediately
156 followed by a server hang-up of the connection. If a server has an
157 inactivity timeout resulting in client autologout, it MUST be no less
158 than 30 minutes after successful authentication. The inactivity
159 timeout MAY be less before authentication.
163 An OK, NO, or BYE response from the server MAY contain a response
164 code to describe the event in a more detailed machine-parsable
165 fashion. A response code consists of data inside parentheses in the
166 form of an atom, possibly followed by a space and arguments.
170Melnikov & Martin Standards Track [Page 3]
172RFC 5804 ManageSieve July 2010
175 Response codes are defined when there is a specific action that a
176 client can take based upon the additional information. In order to
177 support future extension, the response code is represented as a
178 slash-separated (Solidus, %x2F) hierarchy with each level of
179 hierarchy representing increasing detail about the error. Response
180 codes MUST NOT start with the Solidus character. Clients MUST
181 tolerate additional hierarchical response code detail that they don't
182 understand. For example, if the client supports the "QUOTA" response
183 code, but doesn't understand the "QUOTA/MAXSCRIPTS" response code, it
184 should treat "QUOTA/MAXSCRIPTS" as "QUOTA".
186 Client implementations MUST tolerate (ignore) response codes that
187 they do not recognize.
189 The currently defined response codes are the following:
193 This response code is returned in the NO or BYE response from an
194 AUTHENTICATE command. It indicates that site security policy forbids
195 the use of the requested mechanism for the specified authentication
200 This response code is returned in the NO or BYE response from an
201 AUTHENTICATE command. It indicates that site security policy
202 requires the use of a strong encryption mechanism for the specified
203 authentication identity and mechanism.
207 If this response code is returned in the NO/BYE response, it means
208 that the command would have placed the user above the site-defined
209 quota constraints. If this response code is returned in the OK
210 response, it can mean that the user's storage is near its quota, or
211 it can mean that the account exceeded its quota but that the
212 condition is being allowed by the server (the server supports
213 so-called soft quotas). The QUOTA response code has two more
214 detailed variants: "QUOTA/MAXSCRIPTS" (the maximum number of per-user
215 scripts) and "QUOTA/MAXSIZE" (the maximum script size).
219 This response code may be returned with a BYE result from any
220 command, and includes a mandatory parameter that indicates what
221 server to access to manage this user's Sieve scripts. The server
222 will be specified by a Sieve URL (see Section 3). The scriptname
226Melnikov & Martin Standards Track [Page 4]
228RFC 5804 ManageSieve July 2010
231 portion of the URL MUST NOT be specified. The client should
232 authenticate to the specified server and use it for all further
233 commands in the current session.
237 This response code can occur in the OK response to a successful
238 AUTHENTICATE command and includes the optional final server response
239 data from the server as specified by [SASL].
243 This response code occurs in a NO response of an AUTHENTICATE
244 command. It indicates that the user name is valid, but the entry in
245 the authentication database needs to be updated in order to permit
246 authentication with the specified mechanism. This is typically done
247 by establishing a secure channel using TLS, verifying server identity
248 as specified in Section 2.2.1, and finally authenticating once using
249 the [PLAIN] authentication mechanism. The selected mechanism SHOULD
250 then work for authentications in subsequent sessions.
252 This condition can happen if a user has an entry in a system
253 authentication database such as Unix /etc/passwd, but does not have
254 credentials suitable for use by the specified mechanism.
258 A command failed due to a temporary server failure. The client MAY
259 continue using local information and try the command later. This
260 response code only makes sense when returned in a NO/BYE response.
264 A command failed because it is not allowed on the active script, for
265 example, DELETESCRIPT on the active script. This response code only
266 makes sense when returned in a NO/BYE response.
270 A command failed because the referenced script name doesn't exist.
271 This response code only makes sense when returned in a NO/BYE
276 A command failed because the referenced script name already exists.
277 This response code only makes sense when returned in a NO/BYE
282Melnikov & Martin Standards Track [Page 5]
284RFC 5804 ManageSieve July 2010
289 This response code name is followed by a string specified in the
290 command. See Section 2.13 for a possible use case.
294 This response code MAY be returned by the server in the OK response
295 (but it might be returned with the NO/BYE response as well) and
296 signals the client that even though the script is syntactically
297 valid, it might contain errors not intended by the script writer.
298 This response code is typically returned in response to PUTSCRIPT
299 and/or CHECKSCRIPT commands. A client seeing such response code
300 SHOULD present the returned warning text to the user.
304 A user may have multiple Sieve scripts on the server, yet only one
305 script may be used for filtering of incoming messages. This is the
306 active script. Users may have zero or one active script and MUST use
307 the SETACTIVE command described below for changing the active script
308 or disabling Sieve processing. For example, users may have an
309 everyday script they normally use and a special script they use when
310 they go on vacation. Users can change which script is being used
311 without having to download and upload a script stored somewhere else.
315 Servers SHOULD impose quotas to prevent malicious users from
316 overflowing available storage. If a command would place a user over
317 a quota setting, servers that impose such quotas MUST reply with a NO
318 response containing the QUOTA response code. Client implementations
319 MUST be able to handle commands failing because of quota
324 A Sieve script name is a sequence of Unicode characters encoded in
325 UTF-8 [UTF-8]. A script name MUST comply with Net-Unicode Definition
326 (Section 2 of [NET-UNICODE]), with the additional restriction of
327 prohibiting the following Unicode characters:
329 o 0000-001F; [CONTROL CHARACTERS]
333 o 0080-009F; [CONTROL CHARACTERS]
338Melnikov & Martin Standards Track [Page 6]
340RFC 5804 ManageSieve July 2010
343 o 2028; LINE SEPARATOR
345 o 2029; PARAGRAPH SEPARATOR
347 Sieve script names MUST be at least one octet (and hence Unicode
348 character) long. Zero octets script name has a special meaning (see
349 Section 2.8). Servers MUST allow names of up to 128 Unicode
350 characters in length (which can take up to 512 bytes when encoded in
351 UTF-8, not counting the terminating NUL), and MAY allow longer names.
352 A server that receives a script name longer than its internal limit
353 MUST reject the corresponding operation, in particular it MUST NOT
354 truncate the script name.
358 Server capabilities are sent automatically by the server upon a
359 client connection, or after successful STARTTLS and AUTHENTICATE
360 (which establishes a Simple Authentication and Security Layer (SASL))
361 commands. Capabilities may change immediately after a successfully
362 completed STARTTLS command, and/or immediately after a successfully
363 completed AUTHENTICATE command, and/or after a successfully completed
364 UNAUTHENTICATE command (see Section 2.14.1). Capabilities MUST
365 remain static at all other times.
367 Clients MAY request the capabilities at a later time by issuing the
368 CAPABILITY command described later. The capabilities consist of a
369 series of lines each with one or two strings. The first string is
370 the name of the capability, which is case-insensitive. The second
371 optional string is the value associated with that capability. Order
372 of capabilities is arbitrary, but each capability name can appear at
375 The following capabilities are defined in this document:
377 IMPLEMENTATION - Name of implementation and version. This capability
378 MUST always be returned by the server.
380 SASL - List of SASL mechanisms supported by the server, each
381 separated by a space. This list can be empty if and only if STARTTLS
382 is also advertised. This means that the client must negotiate TLS
383 encryption with STARTTLS first, at which point the SASL capability
384 will list a non-empty list of SASL mechanisms.
386 SIEVE - List of space-separated Sieve extensions (as listed in Sieve
387 "require" action [SIEVE]) supported by the Sieve engine. This
388 capability MUST always be returned by the server.
394Melnikov & Martin Standards Track [Page 7]
396RFC 5804 ManageSieve July 2010
399 STARTTLS - If TLS [TLS] is supported by this implementation. Before
400 advertising this capability a server MUST verify to the best of its
401 ability that TLS can be successfully negotiated by a client with
402 common cipher suites. Specifically, a server should verify that a
403 server certificate has been installed and that the TLS subsystem has
404 successfully initialized. This capability SHOULD NOT be advertised
405 once STARTTLS or AUTHENTICATE command completes successfully. Client
406 and server implementations MUST implement the STARTTLS extension.
408 MAXREDIRECTS - Specifies the limit on the number of Sieve "redirect"
409 actions a script can perform during a single evaluation. Note that
410 this is different from the total number of "redirect" actions a
411 script can contain. The value is a non-negative number represented
412 as a ManageSieve string.
414 NOTIFY - A space-separated list of URI schema parts for supported
415 notification methods. This capability MUST be specified if the Sieve
416 implementation supports the "enotify" extension [NOTIFY].
418 LANGUAGE - The language (<Language-Tag> from [RFC5646]) currently
419 used for human-readable error messages. If this capability is not
420 returned, the "i-default" [RFC2277] language is assumed. Note that
421 the current language MAY be per-user configurable (i.e., it MAY
422 change after authentication).
424 OWNER - The canonical name of the logged-in user (SASL "authorization
425 identity") encoded in UTF-8. This capability MUST NOT be returned in
426 unauthenticated state and SHOULD be returned once the AUTHENTICATE
429 VERSION - This capability MUST be returned by servers compliant with
430 this document or its successor. For servers compliant with this
431 document, the capability value is the string "1.0". Lack of this
432 capability means that the server predates this specification and thus
433 doesn't support the following commands: RENAMESCRIPT, CHECKSCRIPT,
436 Section 2.14 defines some additional ManageSieve extensions and their
437 respective capabilities.
439 A server implementation MUST return SIEVE, IMPLEMENTATION, and
440 VERSION capabilities.
442 A client implementation MUST ignore any listed capabilities that it
450Melnikov & Martin Standards Track [Page 8]
452RFC 5804 ManageSieve July 2010
457 S: "IMPlemENTATION" "Example1 ManageSieved v001"
458 S: "SASl" "DIGEST-MD5 GSSAPI"
459 S: "SIeVE" "fileinto vacation"
461 S: "NOTIFY" "xmpp mailto"
462 S: "MAXREdIRECTS" "5"
466 After successful authentication, this might look like this:
470 S: "IMPlemENTATION" "Example1 ManageSieved v001"
471 S: "SASl" "DIGEST-MD5 GSSAPI"
472 S: "SIeVE" "fileinto vacation"
473 S: "NOTIFY" "xmpp mailto"
474 S: "OWNER" "alexey@example.com"
475 S: "MAXREdIRECTS" "5"
481 The ManageSieve protocol assumes a reliable data stream such as that
482 provided by TCP. When TCP is used, a ManageSieve server typically
483 listens on port 4190.
485 Before opening the TCP connection, the ManageSieve client first MUST
486 resolve the Domain Name System (DNS) hostname associated with the
487 receiving entity and determine the appropriate TCP port for
488 communication with the receiving entity. The process is as follows:
490 1. Attempt to resolve the hostname using a [DNS-SRV] Service of
491 "sieve" and a Proto of "tcp" for the target domain (e.g.,
492 "example.net"), resulting in resource records such as
493 "_sieve._tcp.example.net.". The result of the SRV lookup, if
494 successful, will be one or more combinations of a port and
495 hostname; the ManageSieve client MUST resolve the returned
496 hostnames to IPv4/IPv6 addresses according to returned SRV record
497 weight. IP addresses from the first successfully resolved
498 hostname (with the corresponding port number returned by SRV
499 lookup) are used to connect to the server. If connection using
500 one of the IP addresses fails, the next resolved IP address is
506Melnikov & Martin Standards Track [Page 9]
508RFC 5804 ManageSieve July 2010
511 used to connect. If connection to all resolved IP addresses
512 fails, then the resolution/connect is repeated for the next
513 hostname returned by SRV lookup.
515 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or
516 IPv6 address record resolution to determine the IP address, where
517 the port used is the default ManageSieve port of 4190.
5191.9. Conventions Used in This Document
521 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
522 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
523 document are to be interpreted as described in [KEYWORDS].
525 In examples, "C:" and "S:" indicate lines sent by the client and
526 server respectively. Line breaks that do not start a new "C:" or
527 "S:" exist for editorial reasons.
529 Examples of authentication in this document are using DIGEST-MD5
530 [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
534 This section and its subsections describe valid ManageSieve commands.
535 Upon initial connection to the server, the client's session is in
536 non-authenticated state. Prior to successful authentication, only
537 the AUTHENTICATE, CAPABILITY, STARTTLS, LOGOUT, and NOOP (see Section
538 2.13) commands are valid. ManageSieve extensions MAY define other
539 commands that are valid in non-authenticated state. Servers MUST
540 reject all other commands with a NO response. Clients may pipeline
541 commands (send more than one command at a time without waiting for
542 completion of the first command). However, a group of commands sent
543 together MUST NOT have an AUTHENTICATE (*), a STARTTLS, or a
544 HAVESPACE command anywhere but the last command in the list.
546 (*) - The only exception to this rule is when the AUTHENTICATE
547 command contains an initial response for a SASL mechanism that allows
548 clients to send data first, the mechanism is known to complete in one
549 round trip, and the mechanism doesn't negotiate a SASL security
550 layer. Two examples of such SASL mechanisms are PLAIN [PLAIN] and
562Melnikov & Martin Standards Track [Page 10]
564RFC 5804 ManageSieve July 2010
5672.1. AUTHENTICATE Command
569 Arguments: String - mechanism
570 String - initial data (optional)
572 The AUTHENTICATE command indicates a SASL [SASL] authentication
573 mechanism to the server. If the server supports the requested
574 authentication mechanism, it performs an authentication protocol
575 exchange to identify and authenticate the user. Optionally, it also
576 negotiates a security layer for subsequent protocol interactions. If
577 the requested authentication mechanism is not supported, the server
578 rejects the AUTHENTICATE command by sending the NO response.
580 The authentication protocol exchange consists of a series of server
581 challenges and client responses that are specific to the selected
582 authentication mechanism. A server challenge consists of a string
583 (quoted or literal) followed by a CRLF. The contents of the string
584 is a base-64 encoding [BASE64] of the SASL data. A client response
585 consists of a string (quoted or literal) with the base-64 encoding of
586 the SASL data followed by a CRLF. If the client wishes to cancel the
587 authentication exchange, it issues a string containing a single "*".
588 If the server receives such a response, it MUST reject the
589 AUTHENTICATE command by sending a NO reply.
591 Note that an empty challenge/response is sent as an empty string. If
592 the mechanism dictates that the final response is sent by the server,
593 this data MAY be placed within the data portion of the SASL response
594 code to save a round trip.
596 The optional initial-response argument to the AUTHENTICATE command is
597 used to save a round trip when using authentication mechanisms that
598 are defined to send no data in the initial challenge. When the
599 initial-response argument is used with such a mechanism, the initial
600 empty challenge is not sent to the client and the server uses the
601 data in the initial-response argument as if it were sent in response
602 to the empty challenge. If the initial-response argument to the
603 AUTHENTICATE command is used with a mechanism that sends data in the
604 initial challenge, the server MUST reject the AUTHENTICATE command by
605 sending the NO response.
607 The service name specified by this protocol's profile of SASL is
610 Reauthentication is not supported by ManageSieve protocol's profile
611 of SASL. That is, after a successfully completed AUTHENTICATE
612 command, no more AUTHENTICATE commands may be issued in the same
613 session. After a successful AUTHENTICATE command completes, a server
614 MUST reject any further AUTHENTICATE commands with a NO reply.
618Melnikov & Martin Standards Track [Page 11]
620RFC 5804 ManageSieve July 2010
623 However, note that a server may implement the UNAUTHENTICATE
624 extension described in Section 2.14.1.
626 If a security layer is negotiated through the SASL authentication
627 exchange, it takes effect immediately following the CRLF that
628 concludes the successful authentication exchange for the client, and
629 the CRLF of the OK response for the server.
631 When a security layer takes effect, the ManageSieve protocol is reset
632 to the initial state (the state in ManageSieve after a client has
633 connected to the server). The server MUST discard any knowledge
634 obtained from the client that was not obtained from the SASL (or TLS)
635 negotiation itself. Likewise, the client MUST discard any knowledge
636 obtained from the server, such as the list of ManageSieve extensions,
637 that was not obtained from the SASL (and/or TLS) negotiation itself.
638 (Note that a client MAY compare the advertised SASL mechanisms before
639 and after authentication in order to detect an active down-
640 negotiation attack. See below.)
642 Once a SASL security layer is established, the server MUST re-issue
643 the capability results, followed by an OK response. This is
644 necessary to protect against man-in-the-middle attacks that alter the
645 capabilities list prior to SASL negotiation. The capability results
646 MUST include all SASL mechanisms the server was capable of
647 negotiating with that client. This is done in order to allow the
648 client to detect an active down-negotiation attack. If a user-
649 oriented client detects such a down-negotiation attack, it SHOULD
650 either notify the user (it MAY give the user the opportunity to
651 continue with the ManageSieve session in this case) or close the
652 transport connection and indicate that a down-negotiation attack
653 might be in progress. If an automated client detects a down-
654 negotiation attack, it SHOULD return or log an error indicating that
655 a possible attack might be in progress and/or SHOULD close the
656 transport connection.
658 When both [TLS] and SASL security layers are in effect, the TLS
659 encoding MUST be applied (when sending data) after the SASL encoding.
661 Server implementations SHOULD support SASL proxy authentication so
662 that an administrator can administer a user's scripts. Proxy
663 authentication is when a user authenticates as herself/himself but
664 requests the server to act (authorize) as another user.
666 The authorization identity generated by this [SASL] exchange is a
667 "simple username" (in the sense defined in [SASLprep]), and both
668 client and server MUST use the [SASLprep] profile of the [StringPrep]
669 algorithm to prepare these names for transmission or comparison. If
670 preparation of the authorization identity fails or results in an
674Melnikov & Martin Standards Track [Page 12]
676RFC 5804 ManageSieve July 2010
679 empty string (unless it was transmitted as the empty string), the
680 server MUST fail the authentication.
682 If an AUTHENTICATE command fails with a NO response, the client MAY
683 try another authentication mechanism by issuing another AUTHENTICATE
684 command. In other words, the client may request authentication types
685 in decreasing order of preference.
687 Note that a failed (NO) response to the AUTHENTICATE command may
688 contain one of the following response codes: AUTH-TOO-WEAK, ENCRYPT-
689 NEEDED, or TRANSITION-NEEDED. See Section 1.3 for detailed
690 description of the relevant conditions.
692 To ensure interoperability, both client and server implementations of
693 the ManageSieve protocol MUST implement the SCRAM-SHA-1 [SCRAM] SASL
694 mechanism, as well as [PLAIN] over [TLS].
696 Note: use of PLAIN over TLS reflects current use of PLAIN over TLS in
697 other email-related protocols; however, a longer-term goal is to
698 migrate email-related protocols from using PLAIN over TLS to SCRAM-
701 Examples (Note that long lines are folded for readability and are not
702 part of protocol exchange):
704 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
705 S: "SASL" "DIGEST-MD5 GSSAPI"
706 S: "SIEVE" "fileinto vacation"
710 C: Authenticate "DIGEST-MD5"
711 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
712 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
713 cyxjaGFyc2V0PXV0Zi04"
714 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
715 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
716 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
717 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
718 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
720 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
730Melnikov & Martin Standards Track [Page 13]
732RFC 5804 ManageSieve July 2010
735 A slightly different variant of the same authentication exchange is:
737 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
738 S: "SASL" "DIGEST-MD5 GSSAPI"
739 S: "SIEVE" "fileinto vacation"
743 C: Authenticate "DIGEST-MD5"
745 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
746 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
749 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
750 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
751 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
752 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
753 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
756 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
786Melnikov & Martin Standards Track [Page 14]
788RFC 5804 ManageSieve July 2010
791 Another example demonstrating use of SASL PLAIN mechanism under TLS
792 follows. This example also demonstrate use of SASL "initial
793 response" (the second parameter to the Authenticate command):
795 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
798 S: "SIEVE" "fileinto vacation"
803 <TLS negotiation, further commands are under TLS layer>
804 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
807 S: "SIEVE" "fileinto vacation"
809 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
811 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
813 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
814 S: BYE "Too many failed authentication attempts"
815 <Server closes connection>
842Melnikov & Martin Standards Track [Page 15]
844RFC 5804 ManageSieve July 2010
847 The following example demonstrates use of SASL "initial response".
848 It also demonstrates that an empty response can be sent as a literal
849 and that negotiating a SASL security layer results in the server
850 re-issuing server capabilities:
852 C: AUTHENTICATE "GSSAPI" {1488+}
853 C: YIIE[...1480 octets here ...]dA==
855 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
856 [...114 octets here ...]
857 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
861 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
863 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
865 <Further commands/responses are under SASL security layer>
866 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
868 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
869 S: "SIEVE" "fileinto vacation"
871 S: "MAXREDIRECTS" "3"
8742.1.1. Use of SASL PLAIN Mechanism over TLS
876 This section is normative for ManageSieve client implementations that
877 support SASL [PLAIN] over [TLS].
879 If a ManageSieve client is willing to use SASL PLAIN over TLS to
880 authenticate to the ManageSieve server, the client MUST verify the
881 server identity (see Section 2.2.1). If the server identity can't be
882 verified (e.g., the server has not provided any certificate, or if
883 the certificate verification fails), the client MUST NOT attempt to
884 authenticate using the SASL PLAIN mechanism.
888 Support for STARTTLS command in servers is optional. Its
889 availability is advertised with "STARTTLS" capability as described in
892 The STARTTLS command requests commencement of a TLS [TLS]
893 negotiation. The negotiation begins immediately after the CRLF in
894 the OK response. After a client issues a STARTTLS command, it MUST
898Melnikov & Martin Standards Track [Page 16]
900RFC 5804 ManageSieve July 2010
903 NOT issue further commands until a server response is seen and the
904 TLS negotiation is complete.
906 The STARTTLS command is only valid in non-authenticated state. The
907 server remains in non-authenticated state, even if client credentials
908 are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL
909 mechanism MAY be used to authenticate once TLS client credentials are
910 successfully exchanged, but servers supporting the STARTTLS command
911 are not required to support the EXTERNAL mechanism.
913 After the TLS layer is established, the server MUST re-issue the
914 capability results, followed by an OK response. This is necessary to
915 protect against man-in-the-middle attacks that alter the capabilities
916 list prior to STARTTLS. This capability result MUST NOT include the
919 The client MUST discard cached capability information and replace it
920 with the new information. The server MAY advertise different
921 capabilities after STARTTLS.
927 <TLS negotiation, further commands are under TLS layer>
928 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
929 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
930 S: "SIEVE" "fileinto vacation"
9352.2.1. Server Identity Check
937 During the TLS negotiation, the ManageSieve client MUST check its
938 understanding of the server hostname/IP address against the server's
939 identity as presented in the server Certificate message, in order to
940 prevent man-in-the-middle attacks. In this section, the client's
941 understanding of the server's identity is called the "reference
944 Checking is performed according to the following rules:
946 o If the reference identity is a hostname:
948 1. If a subjectAltName extension of the SRVName [X509-SRV],
949 dNSName [X509] (in that order of preference) type is present
950 in the server's certificate, then it SHOULD be used as the
954Melnikov & Martin Standards Track [Page 17]
956RFC 5804 ManageSieve July 2010
959 source of the server's identity. Matching is performed as
960 described in Section 2.2.1.1, with the exception that no
961 wildcard matching is allowed for SRVName type. If the
962 certificate contains multiple names (e.g., more than one
963 dNSName field), then a match with any one of the fields is
964 considered acceptable.
966 2. The client MAY use other types of subjectAltName for
967 performing comparison.
969 3. The server's identity MAY also be verified by comparing the
970 reference identity to the Common Name (CN) [RFC4519] value in
971 the leaf Relative Distinguished Name (RDN) of the subjectName
972 field of the server's certificate. This comparison is
973 performed using the rules for comparison of DNS names in
974 Section 2.2.1.1, below. Although the use of the Common Name
975 value is existing practice, it is deprecated, and
976 Certification Authorities are encouraged to provide
977 subjectAltName values instead. Note that the TLS
978 implementation may represent DNs in certificates according to
979 X.500 or other conventions. For example, some X.500
980 implementations order the RDNs in a DN using a left-to-right
981 (most significant to least significant) convention instead of
982 LDAP's right-to-left convention.
984 o When the reference identity is an IP address, the iPAddress
985 subjectAltName SHOULD be used by the client for comparison. The
986 comparison is performed as described in Section 2.2.1.2.
988 If the server identity check fails, user-oriented clients SHOULD
989 either notify the user (clients MAY give the user the opportunity to
990 continue with the ManageSieve session in this case) or close the
991 transport connection and indicate that the server's identity is
992 suspect. Automated clients SHOULD return or log an error indicating
993 that the server's identity is suspect and/or SHOULD close the
994 transport connection. Automated clients MAY provide a configuration
995 setting that disables this check, but MUST provide a setting that
998 Beyond the server identity check described in this section, clients
999 should be prepared to do further checking to ensure that the server
1000 is authorized to provide the service it is requested to provide. The
1001 client may need to make use of local policy information in making
1010Melnikov & Martin Standards Track [Page 18]
1012RFC 5804 ManageSieve July 2010
10152.2.1.1. Comparison of DNS Names
1017 If the reference identity is an internationalized domain name,
1018 conforming implementations MUST convert it to the ASCII Compatible
1019 Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
1020 before comparison with subjectAltName values of type dNSName.
1021 Specifically, conforming implementations MUST perform the conversion
1022 operation specified in Section 4 of [RFC3490] as follows:
1024 o in step 1, the domain name SHALL be considered a "stored string";
1026 o in step 3, set the flag called "UseSTD3ASCIIRules";
1028 o in step 4, process each label with the "ToASCII" operation; and
1030 o in step 5, change all label separators to U+002E (full stop).
1032 After performing the "to-ASCII" conversion, the DNS labels and names
1033 MUST be compared for equality according to the rules specified in
1034 Section 3 of [RFC3490]; i.e., once all label separators are replaced
1035 with U+002E (dot) they are compared in the case-insensitive manner.
1037 The '*' (ASCII 42) wildcard character is allowed in subjectAltName
1038 values of type dNSName, and then only as the left-most (least
1039 significant) DNS label in that value. This wildcard matches any
1040 left-most DNS label in the server name. That is, the subject
1041 *.example.com matches the server names a.example.com and
1042 b.example.com, but does not match example.com or a.b.example.com.
10442.2.1.2. Comparison of IP Addresses
1046 When the reference identity is an IP address, the identity MUST be
1047 converted to the "network byte order" octet string representation
1048 [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
1049 octet string will contain exactly four octets. For IP Version 6, as
1050 specified in RFC 2460, the octet string will contain exactly sixteen
1051 octets. This octet string is then compared against subjectAltName
1052 values of type iPAddress. A match occurs if the reference identity
1053 octet string and value octet strings are identical.
10552.2.1.3. Comparison of Other subjectName Types
1057 Client implementations MAY support matching against subjectAltName
1058 values of other types as described in other documents.
1066Melnikov & Martin Standards Track [Page 19]
1068RFC 5804 ManageSieve July 2010
1073 The client sends the LOGOUT command when it is finished with a
1074 connection and wishes to terminate it. The server MUST reply with an
1075 OK response. The server MUST ignore commands issued by the client
1076 after the LOGOUT command.
1078 The client SHOULD wait for the OK response before closing the
1079 connection. This avoids the TCP connection going into the TIME_WAIT
1080 state on the server. In order to avoid going into the TIME_WAIT TCP
1081 state, the server MAY wait for a short while for the client to close
1082 the TCP connection first. Whether or not the server waits for the
1083 client to close the connection, it MUST then close the connection
1090 <connection is terminated>
10922.4. CAPABILITY Command
1094 The CAPABILITY command requests the server capabilities as described
1095 earlier in this document. It has no parameters.
1100 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
1102 S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
1103 S: "SIEVE" "fileinto vacation"
11072.5. HAVESPACE Command
1109 Arguments: String - name
1110 Number - script size
1112 The HAVESPACE command is used to query the server for available
1113 space. Clients specify the name they wish to save the script as and
1114 its size in octets. Both parameters can be used by the server to see
1115 if the script with the specified name and size is within a user's
1116 quota(s). For example, the server MAY use the script name to check
1117 if a script would be replaced or a new one would be created. Servers
1118 respond with a NO if storing a script with that name and size would
1122Melnikov & Martin Standards Track [Page 20]
1124RFC 5804 ManageSieve July 2010
1127 fail or OK otherwise. Clients SHOULD issue this command before
1128 attempting to place a script on the server.
1130 Note that the OK response from the HAVESPACE command does not
1131 constitute a guarantee of success as server disk space conditions
1132 could change between the client issuing the HAVESPACE and the client
1133 issuing the PUTSCRIPT commands. A QUOTA response code (see
1134 Section 1.3) remains a possible (albeit unlikely) response to a
1135 subsequent PUTSCRIPT with the same name and size.
1139 C: HAVESPACE "myscript" 999999
1140 S: NO (QUOTA/MAXSIZE) "Quota exceeded"
1142 C: HAVESPACE "foobar" 435
11452.6. PUTSCRIPT Command
1147 Arguments: String - Script name
1148 String - Script content
1150 The PUTSCRIPT command is used by the client to submit a Sieve script
1153 If the script already exists, upon success the old script will be
1154 overwritten. The old script MUST NOT be overwritten if PUTSCRIPT
1155 fails in any way. A script of zero length SHOULD be disallowed.
1157 This command places the script on the server. It does not affect
1158 whether the script is processed on incoming mail, unless it replaces
1159 the script that is already active. The SETACTIVE command is used to
1160 mark a script as active.
1162 When submitting large scripts, clients SHOULD use the HAVESPACE
1163 command beforehand to query if the server is willing to accept a
1164 script of that size.
1166 The server MUST check the submitted script for validity, which
1167 includes checking that the script complies with the Sieve grammar
1168 [SIEVE] and that all Sieve extensions mentioned in the script's
1169 "require" statement(s) are supported by the Sieve interpreter. (Note
1170 that if the Sieve interpreter supports the Sieve "ihave" extension
1171 [I-HAVE], any unrecognized/unsupported extension mentioned in the
1172 "ihave" test MUST NOT cause the validation failure.) Other checks
1173 such as validating the supplied command arguments for each command
1174 MAY be performed. Essentially, the performed validation SHOULD be
1178Melnikov & Martin Standards Track [Page 21]
1180RFC 5804 ManageSieve July 2010
1183 the same as performed when compiling the script for execution.
1184 Implementations that use a binary representation to store compiled
1185 scripts can extend the validation to a full compilation, in order to
1186 avoid validating uploaded scripts multiple times.
1188 If the script fails the validation, the server MUST reply with a NO
1189 response. Any script that fails the validity test MUST NOT be stored
1190 on the server. The message given with a NO response MUST be human
1191 readable and SHOULD contain a specific error message giving the line
1192 number of the first error. Implementors should strive to produce
1193 helpful error messages similar to those given by programming language
1194 compilers. Client implementations should note that this may be a
1195 multiline literal string with more than one error message separated
1196 by CRLFs. The human-readable message is in the language returned in
1197 the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
1198 encoded in UTF-8 [UTF-8].
1200 An OK response MAY contain the WARNINGS response code. In such a
1201 case the human-readable message that follows the OK response SHOULD
1202 contain a specific warning message (or messages) giving the line
1203 number(s) in the script that might contain errors not intended by the
1204 script writer. The human-readable message is in the language
1205 returned in the latest LANGUAGE capability (or in "i-default"; see
1206 Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a
1207 response code SHOULD present the message to the user.
1234Melnikov & Martin Standards Track [Page 22]
1236RFC 5804 ManageSieve July 2010
1241 C: Putscript "foo" {31+}
1243 C: InvalidSieveCommand
1245 S: NO "line 2: Syntax error"
1247 C: Putscript "mysievescript" {110+}
1248 C: require ["fileinto"];
1250 C: if envelope :contains "to" "tmartin+sent" {
1251 C: fileinto "INBOX.sent";
1255 C: Putscript "myforwards" {190+}
1256 C: redirect "111@example.net";
1258 C: if size :under 10k {
1259 C: redirect "mobile@cell.example.com";
1262 C: if envelope :contains "to" "tmartin+lists" {
1263 C: redirect "lists@groups.example.com";
1265 S: OK (WARNINGS) "line 8: server redirect action
1266 limit is 2, this redirect might be ignored"
12682.7. LISTSCRIPTS Command
1270 This command lists the scripts the user has on the server. Upon
1271 success, a list of CRLF-separated script names (each represented as a
1272 quoted or literal string) is returned followed by an OK response. If
1273 there exists an active script, the atom ACTIVE is appended to the
1274 corresponding script name. The atom ACTIVE MUST NOT appear on more
1275 than one response line.
1290Melnikov & Martin Standards Track [Page 23]
1292RFC 5804 ManageSieve July 2010
1299 S: "vacation_script"
1302 S: "main_script" ACTIVE
1307 S: "main_script" active
13102.8. SETACTIVE Command
1312 Arguments: String - script name
1314 This command sets a script active. If the script name is the empty
1315 string (i.e., ""), then any active script is disabled. Disabling an
1316 active script when there is no script active is not an error and MUST
1317 result in an OK reply.
1319 If the script does not exist on the server, then the server MUST
1320 reply with a NO response. Such a reply SHOULD contain the
1321 NONEXISTENT response code.
1325 C: Setactive "vacationscript"
1332 S: No (NONEXISTENT) "There is no script by that name"
1335 S: No (NONEXISTENT) {31}
1336 S: There is no script by that name
1346Melnikov & Martin Standards Track [Page 24]
1348RFC 5804 ManageSieve July 2010
13512.9. GETSCRIPT Command
1353 Arguments: String - script name
1355 This command gets the contents of the specified script. If the
1356 script does not exist, the server MUST reply with a NO response.
1357 Such a reply SHOULD contain the NONEXISTENT response code.
1359 Upon success, a string with the contents of the script is returned
1360 followed by an OK response.
1364 C: Getscript "myscript"
1366 S: #this is my wonderful script
1367 S: reject "I reject all";
13712.10. DELETESCRIPT Command
1373 Arguments: String - script name
1375 This command is used to delete a user's Sieve script. Servers MUST
1376 reply with a NO response if the script does not exist. Such
1377 responses SHOULD include the NONEXISTENT response code.
1379 The server MUST NOT allow the client to delete an active script, so
1380 the server MUST reply with a NO response if attempted. Such a
1381 response SHOULD contain the ACTIVE response code. If a client wishes
1382 to delete an active script, it should use the SETACTIVE command to
1383 disable the script first.
1387 C: Deletescript "foo"
1390 C: Deletescript "baz"
1391 S: No (ACTIVE) "You may not delete an active script"
1402Melnikov & Martin Standards Track [Page 25]
1404RFC 5804 ManageSieve July 2010
14072.11. RENAMESCRIPT Command
1409 Arguments: String - Old Script name
1410 String - New Script name
1412 This command is used to rename a user's Sieve script. Servers MUST
1413 reply with a NO response if the old script does not exist (in which
1414 case the NONEXISTENT response code SHOULD be included), or a script
1415 with the new name already exists (in which case the ALREADYEXISTS
1416 response code SHOULD be included). Renaming the active script is
1417 allowed; the renamed script remains active.
1421 C: Renamescript "foo" "bar"
1424 C: Renamescript "baz" "bar"
1425 S: No "bar already exists"
1427 If the server doesn't support the RENAMESCRIPT command, the client
1428 can emulate it by performing the following steps:
1430 1. List available scripts with LISTSCRIPTS. If the script with the
1431 new script name exists, then the client should ask the user
1432 whether to abort the operation, to replace the script (by issuing
1433 the DELETESCRIPT <newname> after that), or to choose a different
1436 2. Download the old script with GETSCRIPT <oldname>.
1438 3. Upload the old script with the new name: PUTSCRIPT <newname>.
1440 4. If the old script was active (as reported by LISTSCRIPTS in step
1441 1), then make the new script active: SETACTIVE <newname>.
1443 5. Delete the old script: DELETESCRIPT <oldname>.
1445 Note that these steps don't describe how to handle various other
1446 error conditions (for example, NO response containing QUOTA response
1447 code in step 3). Error handling is left as an exercise for the
1458Melnikov & Martin Standards Track [Page 26]
1460RFC 5804 ManageSieve July 2010
14632.12. CHECKSCRIPT Command
1465 Arguments: String - Script content
1467 The CHECKSCRIPT command is used by the client to verify Sieve script
1468 validity without storing the script on the server.
1470 The server MUST check the submitted script for syntactic validity,
1471 which includes checking that all Sieve extensions mentioned in Sieve
1472 script "require" statement(s) are supported by the Sieve interpreter.
1473 (Note that if the Sieve interpreter supports the Sieve "ihave"
1474 extension [I-HAVE], any unrecognized/unsupported extension mentioned
1475 in the "ihave" test MUST NOT cause the syntactic validation failure.)
1476 If the script fails this test, the server MUST reply with a NO
1477 response. The message given with a NO response MUST be human
1478 readable and SHOULD contain a specific error message giving the line
1479 number of the first error. Implementors should strive to produce
1480 helpful error messages similar to those given by programming language
1481 compilers. Client implementations should note that this may be a
1482 multiline literal string with more than one error message separated
1483 by CRLFs. The human-readable message is in the language returned in
1484 the latest LANGUAGE capability (or in "i-default"; see Section 1.7),
1485 encoded in UTF-8 [UTF-8].
1489 C: CheckScript {31+}
1491 C: InvalidSieveCommand
1493 S: NO "line 2: Syntax error"
1495 A ManageSieve server supporting this command MUST NOT check if the
1496 script will put the current user over its quota limit.
1498 An OK response MAY contain the WARNINGS response code. In such a
1499 case, the human-readable message that follows the OK response SHOULD
1500 contain a specific warning message (or messages) giving the line
1501 number(s) in the script that might contain errors not intended by the
1502 script writer. The human-readable message is in the language
1503 returned in the latest LANGUAGE capability (or in "i-default"; see
1504 Section 1.7), encoded in UTF-8 [UTF-8]. A client seeing such a
1505 response code SHOULD present the message to the user.
1514Melnikov & Martin Standards Track [Page 27]
1516RFC 5804 ManageSieve July 2010
1521 Arguments: String - tag to echo back (optional)
1523 The NOOP command does nothing, beyond returning a response to the
1524 client. It may be used by clients for protocol re-synchronization or
1525 to reset any inactivity auto-logout timer on the server.
1527 The response to the NOOP command is always OK, followed by the TAG
1528 response code together with the supplied string. If no string was
1529 supplied in the NOOP command, the TAG response code MUST NOT be
1535 S: OK "NOOP completed"
1537 C: NOOP "STARTTLS-SYNC-42"
1539 S: STARTTLS-SYNC-42) "Done"
15412.14. Recommended Extensions
1543 The UNAUTHENTICATE extension (advertised as the "UNAUTHENTICATE"
1544 capability with no parameters) defines a new UNAUTHENTICATE command,
1545 which allows a client to return the server to non-authenticated
1546 state. Support for this extension is RECOMMENDED.
15482.14.1. UNAUTHENTICATE Command
1550 The UNAUTHENTICATE command returns the server to the
1551 non-authenticated state. It doesn't affect any previously
1552 established TLS [TLS] or SASL (Section 2.1) security layer.
1554 The UNAUTHENTICATE command is only valid in authenticated state. If
1555 issued in a wrong state, the server MUST reject it with a NO
1558 The UNAUTHENTICATE command has no parameters.
1560 When issued in the authenticated state, the UNAUTHENTICATE command
1561 MUST NOT fail (i.e., it must never return anything other than OK or
1570Melnikov & Martin Standards Track [Page 28]
1572RFC 5804 ManageSieve July 2010
1577 URI scheme name: sieve
1581 URI scheme syntax: Described using ABNF [ABNF]. Some ABNF
1582 productions not defined below are from [URI-GEN].
1584 sieveurl = sieveurl-server / sieveurl-list-scripts /
1587 sieveurl-server = "sieve://" authority
1589 sieveurl-list-scripts = "sieve://" authority ["/"]
1591 sieveurl-script = "sieve://" authority "/"
1592 [owner "/"] scriptname
1594 authority = <defined in [URI-GEN]>
1597 ;; %-encoded version of [SASL] authorization
1598 ;; identity (script owner) or "userid".
1600 ;; Empty owner is used to reference
1603 ;; Note that ASCII characters such as " ", ";",
1604 ;; "&", "=", "/" and "?" must be %-encoded
1605 ;; as per rule specified in [URI-GEN].
1607 scriptname = 1*ochar
1608 ;; %-encoded version of UTF-8 representation
1609 ;; of the script name.
1610 ;; Note that ASCII characters such as " ", ";",
1611 ;; "&", "=", "/" and "?" must be %-encoded
1612 ;; as per rule specified in [URI-GEN].
1614 ochar = unreserved / pct-encoded / sub-delims-sh /
1616 ;; Same as [URI-GEN] 'pchar',
1617 ;; but without ";", "&" and "=".
1619 unreserved = <defined in [URI-GEN]>
1621 pct-encoded = <defined in [URI-GEN]>
1626Melnikov & Martin Standards Track [Page 29]
1628RFC 5804 ManageSieve July 2010
1631 sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
1633 ;; Same as [URI-GEN] sub-delims,
1634 ;; but without ";", "&" and "=".
1636 URI scheme semantics:
1638 A Sieve URL identifies a Sieve server or a Sieve script on a Sieve
1639 server. The latter form is associated with the application/sieve
1640 MIME type defined in [SIEVE]. There is no MIME type associated
1641 with the former form of Sieve URI.
1643 The server form is used in the REFERRAL response code (see Section
1644 1.3) in order to designate another server where the client should
1645 perform its operations.
1647 The script form allows to retrieve (GETSCRIPT), update
1648 (PUTSCRIPT), delete (DELETESCRIPT), or activate (SETACTIVE) the
1649 named script; however, the most typical action would be to
1650 retrieve the script. If the script name is empty (omitted), the
1651 URI requests that the client lists available scripts using the
1652 LISTSCRIPTS command.
1654 Encoding considerations:
1656 The script name and/or the owner, if present, is in UTF-8. Non--
1657 US-ASCII UTF-8 octets MUST be percent-encoded as described in
1658 [URI-GEN]. US-ASCII characters such as " " (space), ";", "&",
1659 "=", "/" and "?" MUST be %-encoded as described in [URI-GEN].
1660 Note that "&" and "?" are in this list in order to allow for
1663 Note that the empty owner (e.g., sieve://example.com//script) is
1664 different from the missing owner (e.g.,
1665 sieve://example.com/script) and is reserved for referencing global
1668 The user name (in the "authority" part), if present, is in UTF-8.
1669 Non-US-ASCII UTF-8 octets MUST be percent-encoded as described in
1672 Applications/protocols that use this URI scheme name:
1673 ManageSieve [RFC5804] clients and servers. Clients that can store
1674 user preferences in protocols such as [LDAP] or [ACAP].
1676 Interoperability considerations: None.
1682Melnikov & Martin Standards Track [Page 30]
1684RFC 5804 ManageSieve July 2010
1687 Security considerations:
1688 The <scriptname> part of a ManageSieve URL might potentially disclose
1689 some confidential information about the author of the script or,
1690 depending on a ManageSieve implementation, about configuration of the
1691 mail system. The latter might be used to prepare for a more complex
1692 attack on the mail system.
1694 Clients resolving ManageSieve URLs that wish to achieve data
1695 confidentiality and/or integrity SHOULD use the STARTTLS command (if
1696 supported by the server) before starting authentication, or use a
1697 SASL mechanism, such as GSSAPI, that provides a confidentiality
1700 Contact: Alexey Melnikov <alexey.melnikov@isode.com>
1702 Author/Change controller: IESG.
1704 References: This document and RFC 5228 [SIEVE].
1708 The following syntax specification uses the Augmented Backus-Naur
1709 Form (BNF) notation as specified in [ABNF]. This uses the ABNF core
1710 rules as specified in Appendix A of the ABNF specification [ABNF].
1711 "UTF8-2", "UTF8-3", and "UTF8-4" non-terminal are defined in [UTF-8].
1713 Except as noted otherwise, all alphabetic characters are case-
1714 insensitive. The use of upper- or lowercase characters to define
1715 token strings is for editorial clarity only. Implementations MUST
1716 accept these strings in a case-insensitive fashion.
1718 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
1720 ;; any TEXT-CHAR except QUOTED-SPECIALS
1722 QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
1724 QUOTED-SPECIALS = DQUOTE / "\"
1726 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
1727 ;; <UTF8-2>, <UTF8-3>, and <UTF8-4>
1728 ;; are defined in [UTF-8].
1730 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
1731 ;; Any CHAR except ATOM-SPECIALS
1733 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
1738Melnikov & Martin Standards Track [Page 31]
1740RFC 5804 ManageSieve July 2010
1746 atom = 1*1024ATOM-CHAR
1749 ;; MUST be registered with IANA
1751 auth-type = DQUOTE auth-type-name DQUOTE
1753 auth-type-name = iana-token
1754 ;; as defined in SASL [SASL]
1756 command = (command-any / command-auth /
1757 command-nonauth) CRLF
1758 ;; Modal based on state
1760 command-any = command-capability / command-logout /
1762 ;; Valid in all states
1764 command-auth = command-getscript / command-setactive /
1765 command-listscripts / command-deletescript /
1766 command-putscript / command-checkscript /
1768 command-renamescript /
1769 command-unauthenticate
1770 ;; Valid only in Authenticated state
1772 command-nonauth = command-authenticate / command-starttls
1773 ;; Valid only when in Non-Authenticated
1776 command-authenticate = "AUTHENTICATE" SP auth-type [SP string]
1779 command-capability = "CAPABILITY"
1781 command-deletescript = "DELETESCRIPT" SP sieve-name
1783 command-getscript = "GETSCRIPT" SP sieve-name
1785 command-havespace = "HAVESPACE" SP sieve-name SP number
1787 command-listscripts = "LISTSCRIPTS"
1789 command-noop = "NOOP" [SP string]
1794Melnikov & Martin Standards Track [Page 32]
1796RFC 5804 ManageSieve July 2010
1799 command-logout = "LOGOUT"
1801 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
1803 command-checkscript = "CHECKSCRIPT" SP sieve-script
1805 sieve-script = string
1807 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
1810 old-sieve-name = sieve-name
1812 new-sieve-name = sieve-name
1814 command-setactive = "SETACTIVE" SP active-sieve-name
1816 command-starttls = "STARTTLS"
1818 command-unauthenticate= "UNAUTHENTICATE"
1821 ;; MUST be defined by a Standards Track or
1822 ;; IESG-approved experimental protocol
1825 extension-data = extension-item *(SP extension-item)
1827 extension-item = extend-token / string / number /
1828 "(" [extension-data] ")"
1830 literal-c2s = "{" number "+}" CRLF *OCTET
1831 ;; The number represents the number of
1833 ;; This type of literal can only be sent
1834 ;; from the client to the server.
1836 literal-s2c = "{" number "}" CRLF *OCTET
1837 ;; Almost identical to literal-c2s,
1838 ;; but with no '+' character.
1839 ;; The number represents the number of
1841 ;; This type of literal can only be sent
1842 ;; from the server to the client.
1850Melnikov & Martin Standards Track [Page 33]
1852RFC 5804 ManageSieve July 2010
1855 number = (NZDIGIT *DIGIT) / "0"
1856 ;; A 32-bit unsigned number
1857 ;; with no extra leading zeros.
1858 ;; (0 <= n < 4,294,967,296)
1861 ;; <number> encoded as a <string>.
1863 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
1864 ;; limited to 1024 octets between the <">s
1866 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
1867 ["/" ("MAXSCRIPTS" / "MAXSIZE")] /
1869 resp-code-referral /
1870 "TRANSITION-NEEDED" / "TRYLATER" /
1871 "ACTIVE" / "NONEXISTENT" /
1872 "ALREADYEXISTS" / "WARNINGS" /
1876 resp-code-referral = "REFERRAL" SP sieveurl
1878 resp-code-sasl = "SASL" SP string
1880 resp-code-name = iana-token
1881 ;; The response code name is hierarchical,
1882 ;; separated by '/'.
1883 ;; The response code name MUST NOT start
1886 resp-code-ext = resp-code-name [SP extension-data]
1887 ;; unknown response codes MUST be tolerated
1890 response = response-authenticate /
1892 response-getscript /
1893 response-setactive /
1894 response-listscripts /
1895 response-deletescript /
1896 response-putscript /
1897 response-checkscript /
1898 response-capability /
1899 response-havespace /
1901 response-renamescript /
1906Melnikov & Martin Standards Track [Page 34]
1908RFC 5804 ManageSieve July 2010
1911 response-unauthenticate
1913 response-authenticate = *(string CRLF)
1914 ((response-ok [response-capability]) /
1916 ;; <response-capability> is REQUIRED if a
1917 ;; SASL security layer was negotiated and
1918 ;; MUST be omitted otherwise.
1920 response-capability = *(single-capability) response-oknobye
1922 single-capability = capability-name [SP string] CRLF
1924 capability-name = string
1926 ;; Note that literal-s2c is allowed.
1928 initial-capabilities = DQUOTE "IMPLEMENTATION" DQUOTE SP string /
1929 DQUOTE "SASL" DQUOTE SP sasl-mechs /
1930 DQUOTE "SIEVE" DQUOTE SP sieve-extensions /
1931 DQUOTE "MAXREDIRECTS" DQUOTE SP number-str /
1932 DQUOTE "NOTIFY" DQUOTE SP notify-mechs /
1933 DQUOTE "STARTTLS" DQUOTE /
1934 DQUOTE "LANGUAGE" DQUOTE SP language /
1935 DQUOTE "VERSION" DQUOTE SP version /
1936 DQUOTE "OWNER" DQUOTE SP string
1937 ;; Each capability conforms to
1938 ;; the syntax for single-capability.
1939 ;; Also, note that the capability name
1940 ;; can be returned as either literal-s2c
1941 ;; or quoted, even though only "quoted"
1942 ;; string is shown above.
1944 version = ( DQUOTE "1.0" DQUOTE ) / version-ext
1946 version-ext = DQUOTE ver-major "." ver-minor DQUOTE
1947 ; Future versions specified in updates
1948 ; to this document. An increment to
1949 ; the ver-major means a backward-incompatible
1950 ; change to the protocol, e.g., "3.5" (ver-major "3")
1951 ; is not backward-compatible with any "2.X" version.
1952 ; Any version "Z.W" MUST be backward compatible
1953 ; with any version "Z.Q", where Q < W.
1954 ; For example, version "2.4" is backward compatible
1955 ; with version "2.0", "2.1", "2.2", and "2.3".
1962Melnikov & Martin Standards Track [Page 35]
1964RFC 5804 ManageSieve July 2010
1970 ; Space-separated list of SASL mechanisms,
1971 ; each SASL mechanism name complies with rules
1972 ; specified in [SASL].
1975 sieve-extensions = string
1976 ; Space-separated list of supported SIEVE extensions.
1980 ; Contains <Language-Tag> from [RFC5646].
1983 notify-mechs = string
1984 ; Space-separated list of URI schema parts
1985 ; for supported notification [NOTIFY] methods.
1986 ; MUST NOT be empty.
1988 response-deletescript = response-oknobye
1990 response-getscript = (sieve-script CRLF response-ok) /
1993 response-havespace = response-oknobye
1995 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
1997 ;; ACTIVE may only occur with one sieve-name
1999 response-logout = response-oknobye
2001 response-unauthenticate= response-oknobye
2002 ;; "NO" response can only be returned when
2003 ;; the command is issued in a wrong state
2004 ;; or has a wrong number of parameters
2006 response-ok = "OK" [SP "(" resp-code ")"]
2008 ;; The string contains human-readable text
2009 ;; encoded as UTF-8.
2011 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
2013 ;; The string contains human-readable text
2014 ;; encoded as UTF-8.
2018Melnikov & Martin Standards Track [Page 36]
2020RFC 5804 ManageSieve July 2010
2023 response-oknobye = response-ok / response-nobye
2025 response-noop = response-ok
2027 response-putscript = response-oknobye
2029 response-checkscript = response-oknobye
2031 response-renamescript = response-oknobye
2033 response-setactive = response-oknobye
2035 response-starttls = (response-ok response-capability) /
2039 ;; See Section 1.6 for the full list of
2040 ;; prohibited characters.
2041 ;; Empty string is not allowed.
2043 active-sieve-name = string
2044 ;; See Section 1.6 for the full list of
2045 ;; prohibited characters.
2046 ;; This is similar to <sieve-name>, but
2047 ;; empty string is allowed and has a special
2050 string = quoted / literal-c2s / literal-s2c
2051 ;; literal-c2s is only allowed when sent
2052 ;; from the client to the server.
2053 ;; literal-s2c is only allowed when sent
2054 ;; from the server to the client.
2055 ;; quoted is allowed in either direction.
20575. Security Considerations
2059 The AUTHENTICATE command uses SASL [SASL] to provide authentication
2060 and authorization services. Integrity and privacy services can be
2061 provided by [SASL] and/or [TLS]. When a SASL mechanism is used, the
2062 security considerations for that mechanism apply.
2064 This protocol's transactions are susceptible to passive observers or
2065 man-in-the-middle attacks that alter the data, unless the optional
2066 encryption and integrity services of the SASL (via the AUTHENTICATE
2067 command) and/or [TLS] (via the STARTTLS command) are enabled, or an
2068 external security mechanism is used for protection. It may be useful
2069 to allow configuration of both clients and servers to refuse to
2070 transfer sensitive information in the absence of strong encryption.
2074Melnikov & Martin Standards Track [Page 37]
2076RFC 5804 ManageSieve July 2010
2079 If an implementation supports SASL mechanisms that are vulnerable to
2080 passive eavesdropping attacks (such as [PLAIN]), then the
2081 implementation MUST support at least one configuration where these
2082 SASL mechanisms are not advertised or used without the presence of an
2083 external security layer such as [TLS].
2085 Some response codes returned on failed AUTHENTICATE command may
2086 disclose whether or not the username is valid (e.g., TRANSITION-
2087 NEEDED), so server implementations SHOULD provide the ability to
2088 disable these features (or make them not conditional on a per-user
2089 basis) for sites concerned about such disclosure. In the case of
2090 ENCRYPT-NEEDED, if it is applied to all identities then no extra
2091 information is disclosed, but if it is applied on a per-user basis it
2092 can disclose information.
2094 A compromised or malicious server can use the TRANSITION-NEEDED
2095 response code to force the client that is configured to use a
2096 mechanism that does not disclose the user's password to the server
2097 (e.g., Kerberos), to send the bare password to the server. Clients
2098 SHOULD have the ability to disable the password transition feature,
2099 or disclose that risk to the user and offer the user an option of how
21026. IANA Considerations
2104 IANA has reserved TCP port number 4190 for use with the ManageSieve
2105 protocol described in this document.
2107 IANA has registered the "sieve" URI scheme defined in Section 3 of
2110 IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service
2113 IANA has created a new registry for ManageSieve capabilities. The
2114 registration template for ManageSieve capabilities is specified in
2115 Section 6.1. ManageSieve protocol capabilities MUST be specified in
2116 a Standards-Track or IESG-approved Experimental RFC.
2118 IANA has created a new registry for ManageSieve response codes. The
2119 registration template for ManageSieve response codes is specified in
2120 Section 6.3. ManageSieve protocol response codes MUST be specified
2121 in a Standards-Track or IESG-approved Experimental RFC.
2130Melnikov & Martin Standards Track [Page 38]
2132RFC 5804 ManageSieve July 2010
21356.1. ManageSieve Capability Registration Template
2138 Subject: ManageSieve Capability Registration
2140 Please register the following ManageSieve capability:
2144 Relevant publications:
2145 Person & email address to contact for further information:
2146 Author/Change controller:
21486.2. Registration of Initial ManageSieve Capabilities
2151 Subject: ManageSieve Capability Registration
2153 Please register the following ManageSieve capabilities:
2155 Capability name: IMPLEMENTATION
2156 Description: Its value contains the name of the server
2157 implementation and its version.
2158 Relevant publications: this RFC, Section 1.7.
2159 Person & email address to contact for further information:
2160 Alexey Melnikov <alexey.melnikov@isode.com>
2161 Author/Change controller: IESG.
2163 Capability name: SASL
2164 Description: Its value contains a space-separated list of SASL
2165 mechanisms supported by the server.
2166 Relevant publications: this RFC, Sections 1.7 and 2.1.
2167 Person & email address to contact for further information:
2168 Alexey Melnikov <alexey.melnikov@isode.com>
2169 Author/Change controller: IESG.
2171 Capability name: SIEVE
2172 Description: Its value contains a space-separated list of supported
2174 Relevant publications: this RFC, Section 1.7. Also [SIEVE].
2175 Person & email address to contact for further information:
2176 Alexey Melnikov <alexey.melnikov@isode.com>
2177 Author/Change controller: IESG.
2186Melnikov & Martin Standards Track [Page 39]
2188RFC 5804 ManageSieve July 2010
2191 Capability name: STARTTLS
2192 Description: This capability is returned if the server supports TLS
2194 Relevant publications: this RFC, Sections 1.7 and 2.2.
2195 Person & email address to contact for further information:
2196 Alexey Melnikov <alexey.melnikov@isode.com>
2197 Author/Change controller: IESG.
2199 Capability name: NOTIFY
2200 Description: This capability is returned if the server supports the
2201 'enotify' [NOTIFY] Sieve extension.
2202 Relevant publications: this RFC, Section 1.7.
2203 Person & email address to contact for further information:
2204 Alexey Melnikov <alexey.melnikov@isode.com>
2205 Author/Change controller: IESG.
2207 Capability name: MAXREDIRECTS
2208 Description: This capability returns the limit on the number of
2209 Sieve "redirect" actions a script can perform during a
2210 single evaluation. The value is a non-negative number
2211 represented as a ManageSieve string.
2212 Relevant publications: this RFC, Section 1.7.
2213 Person & email address to contact for further information:
2214 Alexey Melnikov <alexey.melnikov@isode.com>
2215 Author/Change controller: IESG.
2217 Capability name: LANGUAGE
2218 Description: The language (<Language-Tag> from [RFC5646]) currently
2219 used for human-readable error messages.
2220 Relevant publications: this RFC, Section 1.7.
2221 Person & email address to contact for further information:
2222 Alexey Melnikov <alexey.melnikov@isode.com>
2223 Author/Change controller: IESG.
2225 Capability name: OWNER
2226 Description: Its value contains the UTF-8-encoded name of the
2227 currently logged-in user ("authorization identity"
2228 according to RFC 4422).
2229 Relevant publications: this RFC, Section 1.7.
2230 Person & email address to contact for further information:
2231 Alexey Melnikov <alexey.melnikov@isode.com>
2232 Author/Change controller: IESG.
2242Melnikov & Martin Standards Track [Page 40]
2244RFC 5804 ManageSieve July 2010
2247 Capability name: VERSION
2248 Description: This capability is returned if the server is compliant
2249 with RFC 5804; i.e., that it supports RENAMESCRIPT,
2250 CHECKSCRIPT, and NOOP commands.
2251 Relevant publications: this RFC, Sections 2.11, 2.12, and 2.13.
2252 Person & email address to contact for further information:
2253 Alexey Melnikov <alexey.melnikov@isode.com>
2254 Author/Change controller: IESG.
22566.3. ManageSieve Response Code Registration Template
2259 Subject: ManageSieve Response Code Registration
2261 Please register the following ManageSieve response code:
2264 Arguments (use ABNF to specify syntax, or the word NONE if none
2267 Published Specification(s):
2268 Person & email address to contact for further information:
2269 Author/Change controller:
22716.4. Registration of Initial ManageSieve Response Codes
2274 Subject: ManageSieve Response Code Registration
2276 Please register the following ManageSieve response codes:
2278 Response Code: AUTH-TOO-WEAK
2279 Arguments (use ABNF to specify syntax, or the word NONE if none can
2281 Purpose: This response code is returned in the NO response from
2282 an AUTHENTICATE command. It indicates that site
2283 security policy forbids the use of the requested
2284 mechanism for the specified authentication identity.
2285 Published Specification(s): [RFC5804]
2286 Person & email address to contact for further information:
2287 Alexey Melnikov <alexey.melnikov@isode.com>
2288 Author/Change controller: IESG.
2298Melnikov & Martin Standards Track [Page 41]
2300RFC 5804 ManageSieve July 2010
2303 Response Code: ENCRYPT-NEEDED
2304 Arguments (use ABNF to specify syntax, or the word NONE if none can
2306 Purpose: This response code is returned in the NO response from
2307 an AUTHENTICATE command. It indicates that site
2308 security policy requires the use of a strong
2309 encryption mechanism for the specified authentication
2310 identity and mechanism.
2311 Published Specification(s): [RFC5804]
2312 Person & email address to contact for further information:
2313 Alexey Melnikov <alexey.melnikov@isode.com>
2314 Author/Change controller: IESG.
2316 Response Code: QUOTA
2317 Arguments (use ABNF to specify syntax, or the word NONE if none can
2319 Purpose: If this response code is returned in the NO/BYE
2320 response, it means that the command would have placed
2321 the user above the site-defined quota constraints. If
2322 this response code is returned in the OK response, it
2323 can mean that the user is near its quota or that the
2324 user exceeded its quota, but the server supports soft
2326 Published Specification(s): [RFC5804]
2327 Person & email address to contact for further information:
2328 Alexey Melnikov <alexey.melnikov@isode.com>
2329 Author/Change controller: IESG.
2331 Response Code: QUOTA/MAXSCRIPTS
2332 Arguments (use ABNF to specify syntax, or the word NONE if none can
2334 Purpose: If this response code is returned in the NO/BYE
2335 response, it means that the command would have placed
2336 the user above the site-defined limit on the number of
2337 Sieve scripts. If this response code is returned in
2338 the OK response, it can mean that the user is near its
2339 quota or that the user exceeded its quota, but the
2340 server supports soft quotas. This response code is a
2341 more specific version of the QUOTA response code.
2342 Published Specification(s): [RFC5804]
2343 Person & email address to contact for further information:
2344 Alexey Melnikov <alexey.melnikov@isode.com>
2345 Author/Change controller: IESG.
2354Melnikov & Martin Standards Track [Page 42]
2356RFC 5804 ManageSieve July 2010
2359 Response Code: QUOTA/MAXSIZE
2360 Arguments (use ABNF to specify syntax, or the word NONE if none can
2362 Purpose: If this response code is returned in the NO/BYE
2363 response, it means that the command would have placed
2364 the user above the site-defined maximum script size.
2365 If this response code is returned in the OK response,
2366 it can mean that the user is near its quota or that
2367 the user exceeded its quota, but the server supports
2368 soft quotas. This response code is a more specific
2369 version of the QUOTA response code.
2370 Published Specification(s): [RFC5804]
2371 Person & email address to contact for further information:
2372 Alexey Melnikov <alexey.melnikov@isode.com>
2373 Author/Change controller: IESG.
2375 Response Code: REFERRAL
2376 Arguments (use ABNF to specify syntax, or the word NONE if none can
2377 be specified): <sieveurl>
2378 Purpose: This response code may be returned with a BYE result
2379 from any command, and includes a mandatory parameter
2380 that indicates what server to access to manage this
2381 user's Sieve scripts. The server will be specified by
2382 a Sieve URL (see Section 3). The scriptname portion
2383 of the URL MUST NOT be specified. The client should
2384 authenticate to the specified server and use it for
2385 all further commands in the current session.
2386 Published Specification(s): [RFC5804]
2387 Person & email address to contact for further information:
2388 Alexey Melnikov <alexey.melnikov@isode.com>
2389 Author/Change controller: IESG.
2392 Arguments (use ABNF to specify syntax, or the word NONE if none can
2393 be specified): <string>
2394 Purpose: This response code can occur in the OK response to a
2395 successful AUTHENTICATE command and includes the
2396 optional final server response data from the server as
2397 specified by [SASL].
2398 Published Specification(s): [RFC5804]
2399 Person & email address to contact for further information:
2400 Alexey Melnikov <alexey.melnikov@isode.com>
2401 Author/Change controller: IESG.
2410Melnikov & Martin Standards Track [Page 43]
2412RFC 5804 ManageSieve July 2010
2415 Response Code: TRANSITION-NEEDED
2416 Arguments (use ABNF to specify syntax, or the word NONE if none can
2418 Purpose: This response code occurs in a NO response of an
2419 AUTHENTICATE command. It indicates that the user name
2420 is valid, but the entry in the authentication database
2421 needs to be updated in order to permit authentication
2422 with the specified mechanism. This is typically done
2423 by establishing a secure channel using TLS, followed
2424 by authenticating once using the [PLAIN]
2425 authentication mechanism. The selected mechanism
2426 SHOULD then work for authentications in subsequent
2428 Published Specification(s): [RFC5804]
2429 Person & email address to contact for further information:
2430 Alexey Melnikov <alexey.melnikov@isode.com>
2431 Author/Change controller: IESG.
2433 Response Code: TRYLATER
2434 Arguments (use ABNF to specify syntax, or the word NONE if none can
2436 Purpose: A command failed due to a temporary server failure.
2437 The client MAY continue using local information and
2438 try the command later. This response code only make
2439 sense when returned in a NO/BYE response.
2440 Published Specification(s): [RFC5804]
2441 Person & email address to contact for further information:
2442 Alexey Melnikov <alexey.melnikov@isode.com>
2443 Author/Change controller: IESG.
2445 Response Code: ACTIVE
2446 Arguments (use ABNF to specify syntax, or the word NONE if none can
2448 Purpose: A command failed because it is not allowed on the
2449 active script, for example, DELETESCRIPT on the active
2450 script. This response code only makes sense when
2451 returned in a NO/BYE response.
2452 Published Specification(s): [RFC5804]
2453 Person & email address to contact for further information:
2454 Alexey Melnikov <alexey.melnikov@isode.com>
2455 Author/Change controller: IESG.
2466Melnikov & Martin Standards Track [Page 44]
2468RFC 5804 ManageSieve July 2010
2471 Response Code: NONEXISTENT
2472 Arguments (use ABNF to specify syntax, or the word NONE if none can
2474 Purpose: A command failed because the referenced script name
2475 doesn't exist. This response code only makes sense
2476 when returned in a NO/BYE response.
2477 Published Specification(s): [RFC5804]
2478 Person & email address to contact for further information:
2479 Alexey Melnikov <alexey.melnikov@isode.com>
2480 Author/Change controller: IESG.
2482 Response Code: ALREADYEXISTS
2483 Arguments (use ABNF to specify syntax, or the word NONE if none can
2485 Purpose: A command failed because the referenced script name
2486 already exists. This response code only makes sense
2487 when returned in a NO/BYE response.
2488 Published Specification(s): [RFC5804]
2489 Person & email address to contact for further information:
2490 Alexey Melnikov <alexey.melnikov@isode.com>
2491 Author/Change controller: IESG.
2493 Response Code: WARNINGS
2494 Arguments (use ABNF to specify syntax, or the word NONE if none can
2496 Purpose: This response code MAY be returned by the server in
2497 the OK response (but it might be returned with the NO/
2498 BYE response as well) and signals the client that even
2499 though the script is syntactically valid, it might
2500 contain errors not intended by the script writer.
2501 Published Specification(s): [RFC5804]
2502 Person & email address to contact for further information:
2503 Alexey Melnikov <alexey.melnikov@isode.com>
2504 Author/Change controller: IESG.
2507 Arguments (use ABNF to specify syntax, or the word NONE if none can
2508 be specified): string
2509 Purpose: This response code name is followed by a string
2510 specified in the command that caused this response.
2511 It is typically used for client state synchronization.
2512 Published Specification(s): [RFC5804]
2513 Person & email address to contact for further information:
2514 Alexey Melnikov <alexey.melnikov@isode.com>
2515 Author/Change controller: IESG.
2522Melnikov & Martin Standards Track [Page 45]
2524RFC 5804 ManageSieve July 2010
25277. Internationalization Considerations
2529 The LANGUAGE capability (see Section 1.7) allows a client to discover
2530 the current language used in all human-readable responses that might
2531 be returned at the end of any OK/NO/BYE response. Human-readable
2532 text in OK responses typically doesn't need to be shown to the user,
2533 unless it is returned in response to a PUTSCRIPT or CHECKSCRIPT
2534 command that also contains the WARNINGS response code (Section 1.3).
2535 Human-readable text from NO/BYE responses is intended be shown to the
2536 user, unless the client can automatically handle failure of the
2537 command that caused such a response. Clients SHOULD use response
2538 codes (Section 1.3) for automatic error handling. Response codes MAY
2539 also be used by the client to present error messages in a language
2540 understood by the user, for example, if the LANGUAGE capability
2541 doesn't return a language understood by the user.
2543 Note that the human-readable text from OK (WARNINGS) or NO/BYE
2544 responses for PUTSCRIPT/CHECKSCRIPT commands is intended for advanced
2545 users that understand Sieve language. Such advanced users are often
2546 sophisticated enough to be able to handle whatever language the
2547 server is using, even if it is not their preferred language, and will
2548 want to see error/warning text no matter what language the server
2551 A client that generates Sieve script automatically, for example, if
2552 the script is generated without user intervention or from a UI that
2553 presents an abstract list of conditions and corresponding actions,
2554 SHOULD NOT present warning/error messages to the user, because the
2555 user might not even be aware that the client is using Sieve
2556 underneath. However, if the client has a debugging mode, such
2557 warnings/errors SHOULD be available in the debugging mode.
2559 Note that this document doesn't provide a way to modify the currently
2560 used language. It is expected that a future extension will address
2565 Thanks to Simon Josefsson, Larry Greenfield, Allen Johnson, Chris
2566 Newman, Lyndon Nerenberg, Tim Showalter, Sarah Robeson, Walter Wong,
2567 Barry Leiba, Arnt Gulbrandsen, Stephan Bosch, Ken Murchison, Phil
2568 Pennock, Ned Freed, Jeffrey Hutzelman, Mark E. Mallett, Dilyan
2569 Palauzov, Dave Cridland, Aaron Stone, Robert Burrell Donkin, Patrick
2570 Ben Koetter, Bjoern Hoehrmann, Martin Duerst, Pasi Eronen, Magnus
2571 Westerlund, Tim Polk, and Julien Coloos for help with this document.
2572 Special thank you to Phil Pennock for providing text for the NOOP
2573 command, as well as finding various bugs in the document.
2578Melnikov & Martin Standards Track [Page 46]
2580RFC 5804 ManageSieve July 2010
25859.1. Normative References
2587 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2588 Specifications: ABNF", STD 68, RFC 5234, January 2008.
2590 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
2591 Configuration Access Protocol", RFC 2244, November
2594 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
2595 Encodings", RFC 4648, October 2006.
2597 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
2598 for specifying the location of services (DNS SRV)",
2599 RFC 2782, February 2000.
2601 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
2602 Requirement Levels", BCP 14, RFC 2119, March 1997.
2604 [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for
2605 Network Interchange", RFC 5198, March 2008.
2607 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
2608 "Sieve Email Filtering: Extension for Notifications",
2609 RFC 5435, January 2009.
2611 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
2612 Languages", BCP 18, RFC 2277, January 1998.
2614 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
2615 6 (IPv6) Specification", RFC 2460, December 1998.
2617 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
2618 "Internationalizing Domain Names in Applications
2619 (IDNA)", RFC 3490, March 2003.
2621 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
2622 (LDAP): Schema for User Applications", RFC 4519, June
2625 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
2626 Languages", BCP 47, RFC 5646, September 2009.
2628 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
2634Melnikov & Martin Standards Track [Page 47]
2636RFC 5804 ManageSieve July 2010
2639 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
2640 and Security Layer (SASL)", RFC 4422, June 2006.
2642 [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
2643 Names and Passwords", RFC 4013, February 2005.
2645 [SCRAM] Menon-Sen, A., Melnikov, A., Newman, C., and N.
2646 Williams, "Salted Challenge Response Authentication
2647 Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC
2650 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email
2651 Filtering Language", RFC 5228, January 2008.
2653 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
2654 Internationalized Strings ("stringprep")", RFC 3454,
2657 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
2658 Security (TLS) Protocol Version 1.2", RFC 5246, August
2661 [URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter,
2662 "Uniform Resource Identifier (URI): Generic Syntax",
2663 STD 66, RFC 3986, January 2005.
2665 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
2666 10646", STD 63, RFC 3629, November 2003.
2668 [X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2669 Housley, R., and W. Polk, "Internet X.509 Public Key
2670 Infrastructure Certificate and Certificate Revocation
2671 List (CRL) Profile", RFC 5280, May 2008.
2673 [X509-SRV] Santesson, S., "Internet X.509 Public Key
2674 Infrastructure Subject Alternative Name for Expression
2675 of Service Name", RFC 4985, August 2007.
26779.2. Informative References
2679 [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication
2680 as a SASL Mechanism", RFC 2831, May 2000.
2682 [GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
2683 Authentication and Security Layer (SASL) Mechanism",
2684 RFC 4752, November 2006.
2690Melnikov & Martin Standards Track [Page 48]
2692RFC 5804 ManageSieve July 2010
2695 [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
2696 RFC 5463, March 2009.
2698 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
2699 VERSION 4rev1", RFC 3501, March 2003.
2701 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
2702 (LDAP): Technical Specification Road Map", RFC 4510,
2705 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
2706 Security Layer (SASL) Mechanism", RFC 4616, August
2711 Alexey Melnikov (editor)
2713 5 Castle Business Village
2715 Hampton, Middlesex TW12 2BX
2718 EMail: Alexey.Melnikov@isode.com
2722 BeThereBeSquare, Inc.
2724 San Francisco, CA 94117
2727 Phone: +1 510 260-4175
2728 EMail: timmartin@alumni.cmu.edu
2746Melnikov & Martin Standards Track [Page 49]