rfc5804.txt - rohrpost - A commandline mail client to change the world as we see it.
(HTM) git clone git://r-36.net/rohrpost
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
rfc5804.txt (103194B)
---
1
2
3
4
5
6
7 Internet Engineering Task Force (IETF) A. Melnikov, Ed.
8 Request for Comments: 5804 Isode Limited
9 Category: Standards Track T. Martin
10 ISSN: 2070-1721 BeThereBeSquare, Inc.
11 July 2010
12
13
14 A Protocol for Remotely Managing Sieve Scripts
15
16 Abstract
17
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
24 scripts.
25
26 Status of This Memo
27
28 This is an Internet Standards Track document.
29
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.
35
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.
39
40 Copyright Notice
41
42 Copyright (c) 2010 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
44
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.
54
55
56
57
58 Melnikov & Martin Standards Track [Page 1]
59
60 RFC 5804 ManageSieve July 2010
61
62
63 Table of Contents
64
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
106
107
108
109
110
111
112
113
114 Melnikov & Martin Standards Track [Page 2]
115
116 RFC 5804 ManageSieve July 2010
117
118
119 1. Introduction
120
121 1.1. Commands and Responses
122
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
127 response.
128
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.
133
134 1.2. Syntax
135
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.
140
141 Each command consists of an atom (the command name) followed by zero
142 or more strings and numbers terminated by CRLF.
143
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.
151
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.
160
161 1.3. Response Codes
162
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.
167
168
169
170 Melnikov & Martin Standards Track [Page 3]
171
172 RFC 5804 ManageSieve July 2010
173
174
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".
185
186 Client implementations MUST tolerate (ignore) response codes that
187 they do not recognize.
188
189 The currently defined response codes are the following:
190
191 AUTH-TOO-WEAK
192
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
196 identity.
197
198 ENCRYPT-NEEDED
199
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.
204
205 QUOTA
206
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).
216
217 REFERRAL
218
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
223
224
225
226 Melnikov & Martin Standards Track [Page 4]
227
228 RFC 5804 ManageSieve July 2010
229
230
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.
234
235 SASL
236
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].
240
241 TRANSITION-NEEDED
242
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.
251
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.
255
256 TRYLATER
257
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.
261
262 ACTIVE
263
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.
267
268 NONEXISTENT
269
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
272 response.
273
274 ALREADYEXISTS
275
276 A command failed because the referenced script name already exists.
277 This response code only makes sense when returned in a NO/BYE
278 response.
279
280
281
282 Melnikov & Martin Standards Track [Page 5]
283
284 RFC 5804 ManageSieve July 2010
285
286
287 TAG
288
289 This response code name is followed by a string specified in the
290 command. See Section 2.13 for a possible use case.
291
292 WARNINGS
293
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.
301
302 1.4. Active Script
303
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.
312
313 1.5. Quotas
314
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
320 restrictions.
321
322 1.6. Script Names
323
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:
328
329 o 0000-001F; [CONTROL CHARACTERS]
330
331 o 007F; DELETE
332
333 o 0080-009F; [CONTROL CHARACTERS]
334
335
336
337
338 Melnikov & Martin Standards Track [Page 6]
339
340 RFC 5804 ManageSieve July 2010
341
342
343 o 2028; LINE SEPARATOR
344
345 o 2029; PARAGRAPH SEPARATOR
346
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.
355
356 1.7. Capabilities
357
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.
366
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
373 most once.
374
375 The following capabilities are defined in this document:
376
377 IMPLEMENTATION - Name of implementation and version. This capability
378 MUST always be returned by the server.
379
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.
385
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.
389
390
391
392
393
394 Melnikov & Martin Standards Track [Page 7]
395
396 RFC 5804 ManageSieve July 2010
397
398
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.
407
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.
413
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].
417
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).
423
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
427 command succeeds.
428
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,
434 and NOOP.
435
436 Section 2.14 defines some additional ManageSieve extensions and their
437 respective capabilities.
438
439 A server implementation MUST return SIEVE, IMPLEMENTATION, and
440 VERSION capabilities.
441
442 A client implementation MUST ignore any listed capabilities that it
443 does not understand.
444
445
446
447
448
449
450 Melnikov & Martin Standards Track [Page 8]
451
452 RFC 5804 ManageSieve July 2010
453
454
455 Example:
456
457 S: "IMPlemENTATION" "Example1 ManageSieved v001"
458 S: "SASl" "DIGEST-MD5 GSSAPI"
459 S: "SIeVE" "fileinto vacation"
460 S: "StaRTTLS"
461 S: "NOTIFY" "xmpp mailto"
462 S: "MAXREdIRECTS" "5"
463 S: "VERSION" "1.0"
464 S: OK
465
466 After successful authentication, this might look like this:
467
468 Example:
469
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"
476 S: "VERSION" "1.0"
477 S: OK
478
479 1.8. Transport
480
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.
484
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:
489
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
501
502
503
504
505
506 Melnikov & Martin Standards Track [Page 9]
507
508 RFC 5804 ManageSieve July 2010
509
510
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.
514
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.
518
519 1.9. Conventions Used in This Document
520
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].
524
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.
528
529 Examples of authentication in this document are using DIGEST-MD5
530 [DIGEST-MD5] and GSSAPI [GSSAPI] SASL mechanisms.
531
532 2. Commands
533
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.
545
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
551 EXTERNAL [SASL].
552
553
554
555
556
557
558
559
560
561
562 Melnikov & Martin Standards Track [Page 10]
563
564 RFC 5804 ManageSieve July 2010
565
566
567 2.1. AUTHENTICATE Command
568
569 Arguments: String - mechanism
570 String - initial data (optional)
571
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.
579
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.
590
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.
595
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.
606
607 The service name specified by this protocol's profile of SASL is
608 "sieve".
609
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.
615
616
617
618 Melnikov & Martin Standards Track [Page 11]
619
620 RFC 5804 ManageSieve July 2010
621
622
623 However, note that a server may implement the UNAUTHENTICATE
624 extension described in Section 2.14.1.
625
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.
630
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.)
641
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.
657
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.
660
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.
665
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
671
672
673
674 Melnikov & Martin Standards Track [Page 12]
675
676 RFC 5804 ManageSieve July 2010
677
678
679 empty string (unless it was transmitted as the empty string), the
680 server MUST fail the authentication.
681
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.
686
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.
691
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].
695
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-
699 SHA-1 mechanism.
700
701 Examples (Note that long lines are folded for readability and are not
702 part of protocol exchange):
703
704 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
705 S: "SASL" "DIGEST-MD5 GSSAPI"
706 S: "SIEVE" "fileinto vacation"
707 S: "STARTTLS"
708 S: "VERSION" "1.0"
709 S: OK
710 C: Authenticate "DIGEST-MD5"
711 S: "cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
712 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
713 cyxjaGFyc2V0PXV0Zi04"
714 C: "Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
715 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
716 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
717 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
718 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
719 A9YXV0aA=="
720 S: OK (SASL "cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZ
721 mZmZA==")
722
723
724
725
726
727
728
729
730 Melnikov & Martin Standards Track [Page 13]
731
732 RFC 5804 ManageSieve July 2010
733
734
735 A slightly different variant of the same authentication exchange is:
736
737 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
738 S: "SASL" "DIGEST-MD5 GSSAPI"
739 S: "SIEVE" "fileinto vacation"
740 S: "VERSION" "1.0"
741 S: "STARTTLS"
742 S: OK
743 C: Authenticate "DIGEST-MD5"
744 S: {136}
745 S: cmVhbG09ImVsd29vZC5pbm5vc29mdC5leGFtcGxlLmNvbSIsbm9uY2U9Ik
746 9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGFsZ29yaXRobT1tZDUtc2Vz
747 cyxjaGFyc2V0PXV0Zi04
748 C: {300+}
749 C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
750 QuaW5ub3NvZnQuZXhhbXBsZS5jb20iLG5vbmNlPSJPQTZNRzl0RVFHbTJo
751 aCIsbmM9MDAwMDAwMDEsY25vbmNlPSJPQTZNSFhoNlZxVHJSayIsZGlnZX
752 N0LXVyaT0ic2lldmUvZWx3b29kLmlubm9zb2Z0LmV4YW1wbGUuY29tIixy
753 ZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0M2FmNyxxb3
754 A9YXV0aA==
755 S: {56}
756 S: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA==
757 C: ""
758 S: OK
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786 Melnikov & Martin Standards Track [Page 14]
787
788 RFC 5804 ManageSieve July 2010
789
790
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):
794
795 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
796 S: "VERSION" "1.0"
797 S: "SASL" ""
798 S: "SIEVE" "fileinto vacation"
799 S: "STARTTLS"
800 S: OK
801 C: STARTTLS
802 S: OK
803 <TLS negotiation, further commands are under TLS layer>
804 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
805 S: "VERSION" "1.0"
806 S: "SASL" "PLAIN"
807 S: "SIEVE" "fileinto vacation"
808 S: OK
809 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xu"
810 S: NO
811 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xz"
812 S: NO
813 C: Authenticate "PLAIN" "QJIrweAPyo6Q1T9xy"
814 S: BYE "Too many failed authentication attempts"
815 <Server closes connection>
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842 Melnikov & Martin Standards Track [Page 15]
843
844 RFC 5804 ManageSieve July 2010
845
846
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:
851
852 C: AUTHENTICATE "GSSAPI" {1488+}
853 C: YIIE[...1480 octets here ...]dA==
854 S: {208}
855 S: YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKic
856 [...114 octets here ...]
857 /yzpAy9p+Y0LanLskOTvMc0MnjgAa4YEr3eJ6
858 C: {0+}
859 C:
860 S: {44}
861 S: BQQF/wAMAAwAAAAAYRGFAo6W0vIHti8i1UXODgEAEAA=
862 C: {44+}
863 C: BQQE/wAMAAwAAAAAIsT1iv9UkZApw471iXt6cwEAAAE=
864 S: OK
865 <Further commands/responses are under SASL security layer>
866 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
867 S: "VERSION" "1.0"
868 S: "SASL" "PLAIN DIGEST-MD5 GSSAPI"
869 S: "SIEVE" "fileinto vacation"
870 S: "LANGUAGE" "ru"
871 S: "MAXREDIRECTS" "3"
872 S: ok
873
874 2.1.1. Use of SASL PLAIN Mechanism over TLS
875
876 This section is normative for ManageSieve client implementations that
877 support SASL [PLAIN] over [TLS].
878
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.
885
886 2.2. STARTTLS Command
887
888 Support for STARTTLS command in servers is optional. Its
889 availability is advertised with "STARTTLS" capability as described in
890 Section 1.7.
891
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
895
896
897
898 Melnikov & Martin Standards Track [Page 16]
899
900 RFC 5804 ManageSieve July 2010
901
902
903 NOT issue further commands until a server response is seen and the
904 TLS negotiation is complete.
905
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.
912
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
917 STARTTLS capability.
918
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.
922
923 Example:
924
925 C: StartTls
926 S: oK
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"
931 S: "VERSION" "1.0"
932 S: "LANGUAGE" "fr"
933 S: ok
934
935 2.2.1. Server Identity Check
936
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
942 identity".
943
944 Checking is performed according to the following rules:
945
946 o If the reference identity is a hostname:
947
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
951
952
953
954 Melnikov & Martin Standards Track [Page 17]
955
956 RFC 5804 ManageSieve July 2010
957
958
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.
965
966 2. The client MAY use other types of subjectAltName for
967 performing comparison.
968
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.
983
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.
987
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
996 enables it.
997
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
1002 this determination.
1003
1004
1005
1006
1007
1008
1009
1010 Melnikov & Martin Standards Track [Page 18]
1011
1012 RFC 5804 ManageSieve July 2010
1013
1014
1015 2.2.1.1. Comparison of DNS Names
1016
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:
1023
1024 o in step 1, the domain name SHALL be considered a "stored string";
1025
1026 o in step 3, set the flag called "UseSTD3ASCIIRules";
1027
1028 o in step 4, process each label with the "ToASCII" operation; and
1029
1030 o in step 5, change all label separators to U+002E (full stop).
1031
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.
1036
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.
1043
1044 2.2.1.2. Comparison of IP Addresses
1045
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.
1054
1055 2.2.1.3. Comparison of Other subjectName Types
1056
1057 Client implementations MAY support matching against subjectAltName
1058 values of other types as described in other documents.
1059
1060
1061
1062
1063
1064
1065
1066 Melnikov & Martin Standards Track [Page 19]
1067
1068 RFC 5804 ManageSieve July 2010
1069
1070
1071 2.3. LOGOUT Command
1072
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.
1077
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
1084 itself.
1085
1086 Example:
1087
1088 C: Logout
1089 S: Ok
1090 <connection is terminated>
1091
1092 2.4. CAPABILITY Command
1093
1094 The CAPABILITY command requests the server capabilities as described
1095 earlier in this document. It has no parameters.
1096
1097 Example:
1098
1099 C: CAPABILITY
1100 S: "IMPLEMENTATION" "Example1 ManageSieved v001"
1101 S: "VERSION" "1.0"
1102 S: "SASL" "PLAIN SCRAM-SHA-1 GSSAPI"
1103 S: "SIEVE" "fileinto vacation"
1104 S: "STARTTLS"
1105 S: OK
1106
1107 2.5. HAVESPACE Command
1108
1109 Arguments: String - name
1110 Number - script size
1111
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
1119
1120
1121
1122 Melnikov & Martin Standards Track [Page 20]
1123
1124 RFC 5804 ManageSieve July 2010
1125
1126
1127 fail or OK otherwise. Clients SHOULD issue this command before
1128 attempting to place a script on the server.
1129
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.
1136
1137 Example:
1138
1139 C: HAVESPACE "myscript" 999999
1140 S: NO (QUOTA/MAXSIZE) "Quota exceeded"
1141
1142 C: HAVESPACE "foobar" 435
1143 S: OK
1144
1145 2.6. PUTSCRIPT Command
1146
1147 Arguments: String - Script name
1148 String - Script content
1149
1150 The PUTSCRIPT command is used by the client to submit a Sieve script
1151 to the server.
1152
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.
1156
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.
1161
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.
1165
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
1175
1176
1177
1178 Melnikov & Martin Standards Track [Page 21]
1179
1180 RFC 5804 ManageSieve July 2010
1181
1182
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.
1187
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].
1199
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.
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234 Melnikov & Martin Standards Track [Page 22]
1235
1236 RFC 5804 ManageSieve July 2010
1237
1238
1239 Examples:
1240
1241 C: Putscript "foo" {31+}
1242 C: #comment
1243 C: InvalidSieveCommand
1244 C:
1245 S: NO "line 2: Syntax error"
1246
1247 C: Putscript "mysievescript" {110+}
1248 C: require ["fileinto"];
1249 C:
1250 C: if envelope :contains "to" "tmartin+sent" {
1251 C: fileinto "INBOX.sent";
1252 C: }
1253 S: OK
1254
1255 C: Putscript "myforwards" {190+}
1256 C: redirect "111@example.net";
1257 C:
1258 C: if size :under 10k {
1259 C: redirect "mobile@cell.example.com";
1260 C: }
1261 C:
1262 C: if envelope :contains "to" "tmartin+lists" {
1263 C: redirect "lists@groups.example.com";
1264 C: }
1265 S: OK (WARNINGS) "line 8: server redirect action
1266 limit is 2, this redirect might be ignored"
1267
1268 2.7. LISTSCRIPTS Command
1269
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.
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290 Melnikov & Martin Standards Track [Page 23]
1291
1292 RFC 5804 ManageSieve July 2010
1293
1294
1295 Example:
1296
1297 C: Listscripts
1298 S: "summer_script"
1299 S: "vacation_script"
1300 S: {13}
1301 S: clever"script
1302 S: "main_script" ACTIVE
1303 S: OK
1304
1305 C: listscripts
1306 S: "summer_script"
1307 S: "main_script" active
1308 S: OK
1309
1310 2.8. SETACTIVE Command
1311
1312 Arguments: String - script name
1313
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.
1318
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.
1322
1323 Examples:
1324
1325 C: Setactive "vacationscript"
1326 S: Ok
1327
1328 C: Setactive ""
1329 S: Ok
1330
1331 C: Setactive "baz"
1332 S: No (NONEXISTENT) "There is no script by that name"
1333
1334 C: Setactive "baz"
1335 S: No (NONEXISTENT) {31}
1336 S: There is no script by that name
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346 Melnikov & Martin Standards Track [Page 24]
1347
1348 RFC 5804 ManageSieve July 2010
1349
1350
1351 2.9. GETSCRIPT Command
1352
1353 Arguments: String - script name
1354
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.
1358
1359 Upon success, a string with the contents of the script is returned
1360 followed by an OK response.
1361
1362 Example:
1363
1364 C: Getscript "myscript"
1365 S: {54}
1366 S: #this is my wonderful script
1367 S: reject "I reject all";
1368 S:
1369 S: OK
1370
1371 2.10. DELETESCRIPT Command
1372
1373 Arguments: String - script name
1374
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.
1378
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.
1384
1385 Example:
1386
1387 C: Deletescript "foo"
1388 S: Ok
1389
1390 C: Deletescript "baz"
1391 S: No (ACTIVE) "You may not delete an active script"
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402 Melnikov & Martin Standards Track [Page 25]
1403
1404 RFC 5804 ManageSieve July 2010
1405
1406
1407 2.11. RENAMESCRIPT Command
1408
1409 Arguments: String - Old Script name
1410 String - New Script name
1411
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.
1418
1419 Example:
1420
1421 C: Renamescript "foo" "bar"
1422 S: Ok
1423
1424 C: Renamescript "baz" "bar"
1425 S: No "bar already exists"
1426
1427 If the server doesn't support the RENAMESCRIPT command, the client
1428 can emulate it by performing the following steps:
1429
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
1434 name.
1435
1436 2. Download the old script with GETSCRIPT <oldname>.
1437
1438 3. Upload the old script with the new name: PUTSCRIPT <newname>.
1439
1440 4. If the old script was active (as reported by LISTSCRIPTS in step
1441 1), then make the new script active: SETACTIVE <newname>.
1442
1443 5. Delete the old script: DELETESCRIPT <oldname>.
1444
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
1448 reader.
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458 Melnikov & Martin Standards Track [Page 26]
1459
1460 RFC 5804 ManageSieve July 2010
1461
1462
1463 2.12. CHECKSCRIPT Command
1464
1465 Arguments: String - Script content
1466
1467 The CHECKSCRIPT command is used by the client to verify Sieve script
1468 validity without storing the script on the server.
1469
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].
1486
1487 Examples:
1488
1489 C: CheckScript {31+}
1490 C: #comment
1491 C: InvalidSieveCommand
1492 C:
1493 S: NO "line 2: Syntax error"
1494
1495 A ManageSieve server supporting this command MUST NOT check if the
1496 script will put the current user over its quota limit.
1497
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.
1506
1507
1508
1509
1510
1511
1512
1513
1514 Melnikov & Martin Standards Track [Page 27]
1515
1516 RFC 5804 ManageSieve July 2010
1517
1518
1519 2.13. NOOP Command
1520
1521 Arguments: String - tag to echo back (optional)
1522
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.
1526
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
1530 included.
1531
1532 Examples:
1533
1534 C: NOOP
1535 S: OK "NOOP completed"
1536
1537 C: NOOP "STARTTLS-SYNC-42"
1538 S: OK (TAG {16}
1539 S: STARTTLS-SYNC-42) "Done"
1540
1541 2.14. Recommended Extensions
1542
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.
1547
1548 2.14.1. UNAUTHENTICATE Command
1549
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.
1553
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
1556 response.
1557
1558 The UNAUTHENTICATE command has no parameters.
1559
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
1562 BYE).
1563
1564
1565
1566
1567
1568
1569
1570 Melnikov & Martin Standards Track [Page 28]
1571
1572 RFC 5804 ManageSieve July 2010
1573
1574
1575 3. Sieve URL Scheme
1576
1577 URI scheme name: sieve
1578
1579 Status: permanent
1580
1581 URI scheme syntax: Described using ABNF [ABNF]. Some ABNF
1582 productions not defined below are from [URI-GEN].
1583
1584 sieveurl = sieveurl-server / sieveurl-list-scripts /
1585 sieveurl-script
1586
1587 sieveurl-server = "sieve://" authority
1588
1589 sieveurl-list-scripts = "sieve://" authority ["/"]
1590
1591 sieveurl-script = "sieve://" authority "/"
1592 [owner "/"] scriptname
1593
1594 authority = <defined in [URI-GEN]>
1595
1596 owner = *ochar
1597 ;; %-encoded version of [SASL] authorization
1598 ;; identity (script owner) or "userid".
1599 ;;
1600 ;; Empty owner is used to reference
1601 ;; global scripts.
1602 ;;
1603 ;; Note that ASCII characters such as " ", ";",
1604 ;; "&", "=", "/" and "?" must be %-encoded
1605 ;; as per rule specified in [URI-GEN].
1606
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].
1613
1614 ochar = unreserved / pct-encoded / sub-delims-sh /
1615 ":" / "@"
1616 ;; Same as [URI-GEN] 'pchar',
1617 ;; but without ";", "&" and "=".
1618
1619 unreserved = <defined in [URI-GEN]>
1620
1621 pct-encoded = <defined in [URI-GEN]>
1622
1623
1624
1625
1626 Melnikov & Martin Standards Track [Page 29]
1627
1628 RFC 5804 ManageSieve July 2010
1629
1630
1631 sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
1632 "*" / "+" / ","
1633 ;; Same as [URI-GEN] sub-delims,
1634 ;; but without ";", "&" and "=".
1635
1636 URI scheme semantics:
1637
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.
1642
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.
1646
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.
1653
1654 Encoding considerations:
1655
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
1661 future extensions.
1662
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
1666 scripts.
1667
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
1670 [URI-GEN].
1671
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].
1675
1676 Interoperability considerations: None.
1677
1678
1679
1680
1681
1682 Melnikov & Martin Standards Track [Page 30]
1683
1684 RFC 5804 ManageSieve July 2010
1685
1686
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.
1693
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
1698 security layer.
1699
1700 Contact: Alexey Melnikov <alexey.melnikov@isode.com>
1701
1702 Author/Change controller: IESG.
1703
1704 References: This document and RFC 5228 [SIEVE].
1705
1706 4. Formal Syntax
1707
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].
1712
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.
1717
1718 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-21 / %x23-5B /
1719 %x5D-7F
1720 ;; any TEXT-CHAR except QUOTED-SPECIALS
1721
1722 QUOTED-CHAR = SAFE-UTF8-CHAR / "\" QUOTED-SPECIALS
1723
1724 QUOTED-SPECIALS = DQUOTE / "\"
1725
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].
1729
1730 ATOM-CHAR = "!" / %x23-27 / %x2A-5B / %x5D-7A / %x7C-7E
1731 ;; Any CHAR except ATOM-SPECIALS
1732
1733 ATOM-SPECIALS = "(" / ")" / "{" / SP / CTL / QUOTED-SPECIALS
1734
1735
1736
1737
1738 Melnikov & Martin Standards Track [Page 31]
1739
1740 RFC 5804 ManageSieve July 2010
1741
1742
1743 NZDIGIT = %x31-39
1744 ;; 1-9
1745
1746 atom = 1*1024ATOM-CHAR
1747
1748 iana-token = atom
1749 ;; MUST be registered with IANA
1750
1751 auth-type = DQUOTE auth-type-name DQUOTE
1752
1753 auth-type-name = iana-token
1754 ;; as defined in SASL [SASL]
1755
1756 command = (command-any / command-auth /
1757 command-nonauth) CRLF
1758 ;; Modal based on state
1759
1760 command-any = command-capability / command-logout /
1761 command-noop
1762 ;; Valid in all states
1763
1764 command-auth = command-getscript / command-setactive /
1765 command-listscripts / command-deletescript /
1766 command-putscript / command-checkscript /
1767 command-havespace /
1768 command-renamescript /
1769 command-unauthenticate
1770 ;; Valid only in Authenticated state
1771
1772 command-nonauth = command-authenticate / command-starttls
1773 ;; Valid only when in Non-Authenticated
1774 ;; state
1775
1776 command-authenticate = "AUTHENTICATE" SP auth-type [SP string]
1777 *(CRLF string)
1778
1779 command-capability = "CAPABILITY"
1780
1781 command-deletescript = "DELETESCRIPT" SP sieve-name
1782
1783 command-getscript = "GETSCRIPT" SP sieve-name
1784
1785 command-havespace = "HAVESPACE" SP sieve-name SP number
1786
1787 command-listscripts = "LISTSCRIPTS"
1788
1789 command-noop = "NOOP" [SP string]
1790
1791
1792
1793
1794 Melnikov & Martin Standards Track [Page 32]
1795
1796 RFC 5804 ManageSieve July 2010
1797
1798
1799 command-logout = "LOGOUT"
1800
1801 command-putscript = "PUTSCRIPT" SP sieve-name SP sieve-script
1802
1803 command-checkscript = "CHECKSCRIPT" SP sieve-script
1804
1805 sieve-script = string
1806
1807 command-renamescript = "RENAMESCRIPT" SP old-sieve-name SP
1808 new-sieve-name
1809
1810 old-sieve-name = sieve-name
1811
1812 new-sieve-name = sieve-name
1813
1814 command-setactive = "SETACTIVE" SP active-sieve-name
1815
1816 command-starttls = "STARTTLS"
1817
1818 command-unauthenticate= "UNAUTHENTICATE"
1819
1820 extend-token = atom
1821 ;; MUST be defined by a Standards Track or
1822 ;; IESG-approved experimental protocol
1823 ;; extension
1824
1825 extension-data = extension-item *(SP extension-item)
1826
1827 extension-item = extend-token / string / number /
1828 "(" [extension-data] ")"
1829
1830 literal-c2s = "{" number "+}" CRLF *OCTET
1831 ;; The number represents the number of
1832 ;; octets.
1833 ;; This type of literal can only be sent
1834 ;; from the client to the server.
1835
1836 literal-s2c = "{" number "}" CRLF *OCTET
1837 ;; Almost identical to literal-c2s,
1838 ;; but with no '+' character.
1839 ;; The number represents the number of
1840 ;; octets.
1841 ;; This type of literal can only be sent
1842 ;; from the server to the client.
1843
1844
1845
1846
1847
1848
1849
1850 Melnikov & Martin Standards Track [Page 33]
1851
1852 RFC 5804 ManageSieve July 2010
1853
1854
1855 number = (NZDIGIT *DIGIT) / "0"
1856 ;; A 32-bit unsigned number
1857 ;; with no extra leading zeros.
1858 ;; (0 <= n < 4,294,967,296)
1859
1860 number-str = string
1861 ;; <number> encoded as a <string>.
1862
1863 quoted = DQUOTE *1024QUOTED-CHAR DQUOTE
1864 ;; limited to 1024 octets between the <">s
1865
1866 resp-code = "AUTH-TOO-WEAK" / "ENCRYPT-NEEDED" / "QUOTA"
1867 ["/" ("MAXSCRIPTS" / "MAXSIZE")] /
1868 resp-code-sasl /
1869 resp-code-referral /
1870 "TRANSITION-NEEDED" / "TRYLATER" /
1871 "ACTIVE" / "NONEXISTENT" /
1872 "ALREADYEXISTS" / "WARNINGS" /
1873 "TAG" SP string /
1874 resp-code-ext
1875
1876 resp-code-referral = "REFERRAL" SP sieveurl
1877
1878 resp-code-sasl = "SASL" SP string
1879
1880 resp-code-name = iana-token
1881 ;; The response code name is hierarchical,
1882 ;; separated by '/'.
1883 ;; The response code name MUST NOT start
1884 ;; with '/'.
1885
1886 resp-code-ext = resp-code-name [SP extension-data]
1887 ;; unknown response codes MUST be tolerated
1888 ;; by the client.
1889
1890 response = response-authenticate /
1891 response-logout /
1892 response-getscript /
1893 response-setactive /
1894 response-listscripts /
1895 response-deletescript /
1896 response-putscript /
1897 response-checkscript /
1898 response-capability /
1899 response-havespace /
1900 response-starttls /
1901 response-renamescript /
1902 response-noop /
1903
1904
1905
1906 Melnikov & Martin Standards Track [Page 34]
1907
1908 RFC 5804 ManageSieve July 2010
1909
1910
1911 response-unauthenticate
1912
1913 response-authenticate = *(string CRLF)
1914 ((response-ok [response-capability]) /
1915 response-nobye)
1916 ;; <response-capability> is REQUIRED if a
1917 ;; SASL security layer was negotiated and
1918 ;; MUST be omitted otherwise.
1919
1920 response-capability = *(single-capability) response-oknobye
1921
1922 single-capability = capability-name [SP string] CRLF
1923
1924 capability-name = string
1925
1926 ;; Note that literal-s2c is allowed.
1927
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.
1943
1944 version = ( DQUOTE "1.0" DQUOTE ) / version-ext
1945
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".
1956
1957 ver-major = number
1958
1959
1960
1961
1962 Melnikov & Martin Standards Track [Page 35]
1963
1964 RFC 5804 ManageSieve July 2010
1965
1966
1967 ver-minor = number
1968
1969 sasl-mechs = string
1970 ; Space-separated list of SASL mechanisms,
1971 ; each SASL mechanism name complies with rules
1972 ; specified in [SASL].
1973 ; Can be empty.
1974
1975 sieve-extensions = string
1976 ; Space-separated list of supported SIEVE extensions.
1977 ; Can be empty.
1978
1979 language = string
1980 ; Contains <Language-Tag> from [RFC5646].
1981
1982
1983 notify-mechs = string
1984 ; Space-separated list of URI schema parts
1985 ; for supported notification [NOTIFY] methods.
1986 ; MUST NOT be empty.
1987
1988 response-deletescript = response-oknobye
1989
1990 response-getscript = (sieve-script CRLF response-ok) /
1991 response-nobye
1992
1993 response-havespace = response-oknobye
1994
1995 response-listscripts = *(sieve-name [SP "ACTIVE"] CRLF)
1996 response-oknobye
1997 ;; ACTIVE may only occur with one sieve-name
1998
1999 response-logout = response-oknobye
2000
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
2005
2006 response-ok = "OK" [SP "(" resp-code ")"]
2007 [SP string] CRLF
2008 ;; The string contains human-readable text
2009 ;; encoded as UTF-8.
2010
2011 response-nobye = ("NO" / "BYE") [SP "(" resp-code ")"]
2012 [SP string] CRLF
2013 ;; The string contains human-readable text
2014 ;; encoded as UTF-8.
2015
2016
2017
2018 Melnikov & Martin Standards Track [Page 36]
2019
2020 RFC 5804 ManageSieve July 2010
2021
2022
2023 response-oknobye = response-ok / response-nobye
2024
2025 response-noop = response-ok
2026
2027 response-putscript = response-oknobye
2028
2029 response-checkscript = response-oknobye
2030
2031 response-renamescript = response-oknobye
2032
2033 response-setactive = response-oknobye
2034
2035 response-starttls = (response-ok response-capability) /
2036 response-nobye
2037
2038 sieve-name = string
2039 ;; See Section 1.6 for the full list of
2040 ;; prohibited characters.
2041 ;; Empty string is not allowed.
2042
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
2048 ;; meaning.
2049
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.
2056
2057 5. Security Considerations
2058
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.
2063
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.
2071
2072
2073
2074 Melnikov & Martin Standards Track [Page 37]
2075
2076 RFC 5804 ManageSieve July 2010
2077
2078
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].
2084
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.
2093
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
2100 to proceed.
2101
2102 6. IANA Considerations
2103
2104 IANA has reserved TCP port number 4190 for use with the ManageSieve
2105 protocol described in this document.
2106
2107 IANA has registered the "sieve" URI scheme defined in Section 3 of
2108 this document.
2109
2110 IANA has registered "sieve" in the "GSSAPI/Kerberos/SASL Service
2111 Names" registry.
2112
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.
2117
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.
2122
2123
2124
2125
2126
2127
2128
2129
2130 Melnikov & Martin Standards Track [Page 38]
2131
2132 RFC 5804 ManageSieve July 2010
2133
2134
2135 6.1. ManageSieve Capability Registration Template
2136
2137 To: iana@iana.org
2138 Subject: ManageSieve Capability Registration
2139
2140 Please register the following ManageSieve capability:
2141
2142 Capability name:
2143 Description:
2144 Relevant publications:
2145 Person & email address to contact for further information:
2146 Author/Change controller:
2147
2148 6.2. Registration of Initial ManageSieve Capabilities
2149
2150 To: iana@iana.org
2151 Subject: ManageSieve Capability Registration
2152
2153 Please register the following ManageSieve capabilities:
2154
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.
2162
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.
2170
2171 Capability name: SIEVE
2172 Description: Its value contains a space-separated list of supported
2173 SIEVE extensions.
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.
2178
2179
2180
2181
2182
2183
2184
2185
2186 Melnikov & Martin Standards Track [Page 39]
2187
2188 RFC 5804 ManageSieve July 2010
2189
2190
2191 Capability name: STARTTLS
2192 Description: This capability is returned if the server supports TLS
2193 (STARTTLS command).
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.
2198
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.
2206
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.
2216
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.
2224
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.
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242 Melnikov & Martin Standards Track [Page 40]
2243
2244 RFC 5804 ManageSieve July 2010
2245
2246
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.
2255
2256 6.3. ManageSieve Response Code Registration Template
2257
2258 To: iana@iana.org
2259 Subject: ManageSieve Response Code Registration
2260
2261 Please register the following ManageSieve response code:
2262
2263 Response Code:
2264 Arguments (use ABNF to specify syntax, or the word NONE if none
2265 can be specified):
2266 Purpose:
2267 Published Specification(s):
2268 Person & email address to contact for further information:
2269 Author/Change controller:
2270
2271 6.4. Registration of Initial ManageSieve Response Codes
2272
2273 To: iana@iana.org
2274 Subject: ManageSieve Response Code Registration
2275
2276 Please register the following ManageSieve response codes:
2277
2278 Response Code: AUTH-TOO-WEAK
2279 Arguments (use ABNF to specify syntax, or the word NONE if none can
2280 be specified): NONE
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.
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298 Melnikov & Martin Standards Track [Page 41]
2299
2300 RFC 5804 ManageSieve July 2010
2301
2302
2303 Response Code: ENCRYPT-NEEDED
2304 Arguments (use ABNF to specify syntax, or the word NONE if none can
2305 be specified): NONE
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.
2315
2316 Response Code: QUOTA
2317 Arguments (use ABNF to specify syntax, or the word NONE if none can
2318 be specified): NONE
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
2325 quotas.
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.
2330
2331 Response Code: QUOTA/MAXSCRIPTS
2332 Arguments (use ABNF to specify syntax, or the word NONE if none can
2333 be specified): NONE
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.
2346
2347
2348
2349
2350
2351
2352
2353
2354 Melnikov & Martin Standards Track [Page 42]
2355
2356 RFC 5804 ManageSieve July 2010
2357
2358
2359 Response Code: QUOTA/MAXSIZE
2360 Arguments (use ABNF to specify syntax, or the word NONE if none can
2361 be specified): NONE
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.
2374
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.
2390
2391 Response Code: SASL
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.
2402
2403
2404
2405
2406
2407
2408
2409
2410 Melnikov & Martin Standards Track [Page 43]
2411
2412 RFC 5804 ManageSieve July 2010
2413
2414
2415 Response Code: TRANSITION-NEEDED
2416 Arguments (use ABNF to specify syntax, or the word NONE if none can
2417 be specified): NONE
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
2427 sessions.
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.
2432
2433 Response Code: TRYLATER
2434 Arguments (use ABNF to specify syntax, or the word NONE if none can
2435 be specified): NONE
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.
2444
2445 Response Code: ACTIVE
2446 Arguments (use ABNF to specify syntax, or the word NONE if none can
2447 be specified): NONE
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.
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466 Melnikov & Martin Standards Track [Page 44]
2467
2468 RFC 5804 ManageSieve July 2010
2469
2470
2471 Response Code: NONEXISTENT
2472 Arguments (use ABNF to specify syntax, or the word NONE if none can
2473 be specified): NONE
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.
2481
2482 Response Code: ALREADYEXISTS
2483 Arguments (use ABNF to specify syntax, or the word NONE if none can
2484 be specified): NONE
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.
2492
2493 Response Code: WARNINGS
2494 Arguments (use ABNF to specify syntax, or the word NONE if none can
2495 be specified): NONE
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.
2505
2506 Response Code: TAG
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.
2516
2517
2518
2519
2520
2521
2522 Melnikov & Martin Standards Track [Page 45]
2523
2524 RFC 5804 ManageSieve July 2010
2525
2526
2527 7. Internationalization Considerations
2528
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.
2542
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
2549 puts it in.
2550
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.
2558
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
2561 that.
2562
2563 8. Acknowledgements
2564
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.
2574
2575
2576
2577
2578 Melnikov & Martin Standards Track [Page 46]
2579
2580 RFC 5804 ManageSieve July 2010
2581
2582
2583 9. References
2584
2585 9.1. Normative References
2586
2587 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2588 Specifications: ABNF", STD 68, RFC 5234, January 2008.
2589
2590 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
2591 Configuration Access Protocol", RFC 2244, November
2592 1997.
2593
2594 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
2595 Encodings", RFC 4648, October 2006.
2596
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.
2600
2601 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
2602 Requirement Levels", BCP 14, RFC 2119, March 1997.
2603
2604 [NET-UNICODE] Klensin, J. and M. Padlipsky, "Unicode Format for
2605 Network Interchange", RFC 5198, March 2008.
2606
2607 [NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
2608 "Sieve Email Filtering: Extension for Notifications",
2609 RFC 5435, January 2009.
2610
2611 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
2612 Languages", BCP 18, RFC 2277, January 1998.
2613
2614 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
2615 6 (IPv6) Specification", RFC 2460, December 1998.
2616
2617 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
2618 "Internationalizing Domain Names in Applications
2619 (IDNA)", RFC 3490, March 2003.
2620
2621 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
2622 (LDAP): Schema for User Applications", RFC 4519, June
2623 2006.
2624
2625 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
2626 Languages", BCP 47, RFC 5646, September 2009.
2627
2628 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
2629 September 1981.
2630
2631
2632
2633
2634 Melnikov & Martin Standards Track [Page 47]
2635
2636 RFC 5804 ManageSieve July 2010
2637
2638
2639 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
2640 and Security Layer (SASL)", RFC 4422, June 2006.
2641
2642 [SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
2643 Names and Passwords", RFC 4013, February 2005.
2644
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
2648 5802, July 2010.
2649
2650 [SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email
2651 Filtering Language", RFC 5228, January 2008.
2652
2653 [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
2654 Internationalized Strings ("stringprep")", RFC 3454,
2655 December 2002.
2656
2657 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer
2658 Security (TLS) Protocol Version 1.2", RFC 5246, August
2659 2008.
2660
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.
2664
2665 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
2666 10646", STD 63, RFC 3629, November 2003.
2667
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.
2672
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.
2676
2677 9.2. Informative References
2678
2679 [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication
2680 as a SASL Mechanism", RFC 2831, May 2000.
2681
2682 [GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
2683 Authentication and Security Layer (SASL) Mechanism",
2684 RFC 4752, November 2006.
2685
2686
2687
2688
2689
2690 Melnikov & Martin Standards Track [Page 48]
2691
2692 RFC 5804 ManageSieve July 2010
2693
2694
2695 [I-HAVE] Freed, N., "Sieve Email Filtering: Ihave Extension",
2696 RFC 5463, March 2009.
2697
2698 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
2699 VERSION 4rev1", RFC 3501, March 2003.
2700
2701 [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
2702 (LDAP): Technical Specification Road Map", RFC 4510,
2703 June 2006.
2704
2705 [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
2706 Security Layer (SASL) Mechanism", RFC 4616, August
2707 2006.
2708
2709 Authors' Addresses
2710
2711 Alexey Melnikov (editor)
2712 Isode Limited
2713 5 Castle Business Village
2714 36 Station Road
2715 Hampton, Middlesex TW12 2BX
2716 UK
2717
2718 EMail: Alexey.Melnikov@isode.com
2719
2720
2721 Tim Martin
2722 BeThereBeSquare, Inc.
2723 672 Haight st.
2724 San Francisco, CA 94117
2725 USA
2726
2727 Phone: +1 510 260-4175
2728 EMail: timmartin@alumni.cmu.edu
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746 Melnikov & Martin Standards Track [Page 49]
2747